Published: 08 Feb 2005
Internal firewalls that mirror perimeter devices may not be worth the trouble.
Most security managers and architects would agree that defense-in-depth architectures are the right approach to enterprise security.
How is this done? In part, by layering firewalls. You put a primary set of firewalls on the perimeter, and then place secondary firewalls on interior network segments. This way, you keep out the Internet bad guys while controlling traffic between internal subnets.
Now comes the challenge: Should perimeter and internal firewalls have the same rule sets?
Before you answer, consider this: Your organization isn't entirely "your" organization. Enterprises are divided along political/ business lines in ways that show very little respect for seamless security. Perhaps you only have say over the perimeter firewalls, but the internal firewalls are controlled by divisional network managers with their own ideas of how things should be done.
Does it make sense to have a loose rule set on the perimeter firewall that allows more traffic into the network, but then gets more granular at the internal firewall? Perhaps. The business unit knows best what granular rules and specific hosts it requires.
Is it worth it to duplicate every host specified at the perimeter and internal firewall? And if you have this level of granularity at both boundaries, just what exactly is the value of having an internal firewall?
Having duplicate rules on both the perimeter and internal firewalls adds little value to overall security. However, if you practice the principle of "least privileges," you're probably specifying hosts rather than ranges of subnets, even at the perimeter. A granular firewall policy at the perimeter also improves the results from IDS sensors, since any traffic an IDS sees should be legitimate traffic--making it easier to flag rogue behavior.
So, you shift granular control back to the perimeter, but now what should you do with all those internal firewalls? Different branches often don't trust each other, so a firewall could be useful for managing traffic between the divisions. But if inter-branch traffic is minimal and fairly predictable, you may be able to get by with just router ACLs. Unless your internal firewalls are doing something special, such as proxying a specific set of risky services, they're either redundant or simply marking a political/business boundary. In other words, they hold little value.
There is, of course, a case to be made for inline traffic protection on internal subnets to contain the spread of malware. Conventional stateful firewalls could be replaced with specialized inline devices that filter malware and malicious traffic, such as Check Point Software Technologies' InterSpect and Trend Micro's VirusWall. This scheme's benefits are that you don't have to support all those firewalls and manage all those rule sets. The downside, of course, is that you will have to manage an enormous perimeter firewall rule set.
Solving the rule set management problem is the emergence technology of virtual firewalls, which create a sense of partitioned spaces within a single physical firewall--with each virtual firewall containing only the rules specifically needed by each given branch. A virtual firewall would be allocated for each of the respective branches that live behind the second boundary. While this architecture isn't ideal for all enterprises, it could save a lot of time and money by reducing infrastructure complexity.