The Firewall is Dead. Long Live the Firewall!



Category: Uncategorized
 

Recently, Roger Grimes opined that the firewall was dead.  Several folks chimed in to tell him that he was wrong, and much debate has ensued, citing reports about the nature of recent breaches, how attacks used to work, and how modern attacks work.

 

I think much of the misunderstanding has to do with the definition of the firewall.  Roger uses an implementation-specific definition for the firewall.  An implementation-specific definition describes the firewall as something that opens and closes ports in an attempt to reduce the attack surface of the network.  We all know that open and closing ports doesn’t limit the attack surface of the network – and hasn’t for years.  So, if you stick to the implementation-specific definition (a stateful inspection, port-based firewall), I agree – the firewall fails to provide much help in securing the network – and for most intents and purposes, is dead.

 

If, however, you look at an architectural definition of the firewall – an infrastructure component that:

 

  1. Defines the boundary between trust zones
  2. Sees all of the traffic
  3. Has a positive security model (i.e., default deny)
  4. And most importantly, meaningfully reduces the attack surface of the network

 

Viewed this way, the firewall is alive and well, and more necessary than ever.

 

Jody Brazil at FireMon correctly points out a couple of relevant pieces (disclosure – FireMon is a Palo Alto Networks partner):

 

  1. Next-generation firewalls are relevant
  2. Firewall management is a problem

 

On the first point, Grimes dismisses “deep packet inspection” out of hand, again proving his implementation-specific understanding of the firewall.  If a firewall allows all port 80 traffic, then scans for a bunch of attacks or undesirable applications with an after-firewall IPS-style engine, then I agree – the firewall aspect is useless.  But identifying the application PRIOR to allowing the traffic – in effect, classifying the traffic not by port, but by application, then making an access decision – is fundamentally different.  Not only does it reduce the attack surface of the network (allow traffic from/to these twenty applications into my data center, all else deny) but it also goes a long way to address the management issues that Grimes and Brazil both highlight – namely that too many arcane port-based firewall rules exist, and far too many are left alone because nobody understands what they do.  This results in poor security, and major management issues across thousands of port-based firewall rules, and countless policies across the ever-increasing other network security devices that organizations put in place to compensate for the port-based firewall’s irrelevance.

 

When a firewall rule reads “allow sales to use GoToMeeting,” or “allow IT to use BitTorrent,” there’s no confusion of the intent of the rule due to obscure port assignments.  This enables easy understanding, reduced rulesets, and the important “all else deny” statement at the end of the rulebase (which Grimes laments the loss of).  It also makes it far easier to stop the kinds of attacks that Grimes and Brazil talk about – the first rule of defense is to control the avenues of attack (which, in today’s world, are applications), not by blocking the applications the business values, but by only allowing the applications the business values, and then scanning those for threats of all sorts.  Wade Williamson does a good job of explaining this in detail.

 

Doing this well, in the firewall, enables organizations to rationalize network security infrastructure investments, but that’s a different topic.

2 Reader Comments

  1. In regards to firewall management and the difficulty to read “obscure port assignments”…. last time I checked, firewall rulebases have a comment field usually. And we usually fill it with something like “allow sales to use gotomeeting”.

    Just saying 🙂

  2. Hi Sascha – thanks for the comment. While you’re spot on, in a traditional stateful inspection firewall, that comment field would be attached to a rule that allows port 80 or port 443 from trust to untrust (or LAN to Internet). In other words, while the comment attached to the rule might be the admin’s intent, the rule itself would essentially allow everything that used port 80 or 443. Which has the unintentional consequence of allowing a ton of other traffic (of course including GoToMeeting for sales). So the comment that would match the actual stateful inspection rule should read, “allow anything and everything that uses port 80 or 443.” My point was more to the story I get from lots of enterprise customers – who usually have a rulebase that numbers in the thousands, with rules written over the course of years, by a few generations of admins – and the difficulty of understanding the intent of a 6 year old rule that calls out an obscure port and IP address combination. In a perfect world, that rule would be accurately commented, but many admins I know won’t touch old rules for fear of interrupting service to an application.

    Only an NGFW (using application and user-based traffic classification) would actually be able to create and enforce a rule like “allow sales to use GoToMeeting.” And yes, we have a description field attached to rules too. 😉

    Thanks for reading!

Got something to say?

Get updates: Unit 42

Sign up to receive the latest news, cyber threat intelligence and research from Unit42


SUBSCRIBE TO RSS