To Firewall or not to Firewall – Trusted & Untrusted Networks

The big danger of firewall deployments within a complex dynamic network infrastructure (a typical enterprise) is you end up with placebo network security. It is a problem that creeps in with each firewall rule change over the course of time. No one ever seems to be concerned when adding a new rule to a firewall ruleset, but removing a rule is a fearful business, so often it is not risked, so not to break anything.  The general adhoc adding of rules without first understanding the entire ruleset is what seriously weakens firewall security, it makes rulesets hard to understand and can mushroom into an ineffective firewall configuration. So instead of allowing a network range through on specific set of ports as a single rule, you end up with tens of rules allowing individual IPs each on a specific port. I have seen firewall rulesets with thousands of unnecessary individual rules, caused by a combination of poor firewall management, lack of change control, lack of ruleset documentation and to be honest a lack of staff expertise.

Lets roll back to the fundamental purpose of a network firewall, which is to control network traffic between trusted and untrusted networks, only allowing specific required and trusted network communication between an untrusted and trusted network segment.  The obvious example is the Internet (untrusted) and the office LAN (trusted). However the textbook Internet facing firewall is not typically where the issues are in a complex internal network infrastructure, where often there are countless individual networks making up a WAN.
 
It is important to define what we mean by an ‘untrusted’ network in the context of the ‘trusted’ network we seek to protect. I would define it as such, an untrusted network is any network you do not have the ability to control or manage.  So (typically) an external client network is untrusted, a third party service provider network is untrusted, but as for networks within the enterprise WAN, well that all depends on whether they are controlled and managed, in other words are they secured to same degree as the trusted network you seek to protect. 

In the context of a WAN, we should not overlook internal network security is a part of a layered security approach, and that data transit through the networks are also are controlled logically at the application layer (access control) and perhaps even encryption. However this multi-layered security approach may not suit the needs and risk for internal network interconnectivity. To understand where firewalls are required it must start with assessing which networks are considered as untrusted and which ones are consider trusted.

Some network environments won't be as simple as the duplex of an untrusted and trust network, however they can still be logically defined in a levelled trust relationship model, allow zones of trust within the network infrastructure, a bit complicated to explain fully in this post but for example:

• Network A: Network B & C are trusted (untrusted zone)
• Network B: Network A is untrusted, Network C is trusted (trusted zone level 1)
• Network C: Network A & B are untrusted (trusted zone level 2)

A network firewall device may not even be necessary to segregate networks, as an adequate degree of network security to a firewall can be provided by network devices, for instance by creating Access Control List (ACL) on a Managed Switch, and a Router can be used to secure network traffic between networks.

Finally, firewall deployments and the network layer security needs to be tested and assured. I recommend regular firewall ruleset reviews, however the most effective way is test the security like a hacker or malware would, by performing regular network discovery and vulnerability scanning, which help ensure firewalls continue to secure communications between trusted and untrusted networks as designed. Internal network discovery and vulnerability scans can even be a fully automated process by using tools such as Outpost24's Hacker In A Box (HIAB)