When Is a Firewall Like a Speed Bump?

6 May 2012 by 5 Comments

The other day the Director of Engineering at my new job asked me why we install firewalls. He admitted that he already had an answer, but that he wanted me to document it for all the network engineers who frequently asked him this question. The problem is that I’ve been asking myself the same thing for a few years now.  At first, the only response I could think of was, “Because of the checkboxes,” and almost sent him this:*

Night of the Living Auditors

But I don’t think that’s what he really had in mind.  Then I brought up the discussion with a friend at my old job, sarcastically proclaiming, “Firewalls are no better than speed bumps.”

Because of my antipathy for firewalls, the question and my offhanded remark sent me down a mental rabbit hole as I tried to work out why it continued to bother me.  Like my first love, firewalls have left me disappointed over unfulfilled promises. Vendors arrive at your enterprise, frighten you with phrases like Advanced Persistent Threat, then dazzle you with their Next Generation Technology and location in the Magic Quadrant. But once you deploy the technology, you find out what happens when you try to turn on all the nifty features that are supposed to protect you. The published line-rate becomes a fantasy or you end up breaking applications. You also discover that firewalls aren’t all that difficult to bypass anyway. “Hey Harry Potter, where’s the magic in that quadrant?”

Good network engineers spend countless hours designing infrastructures to optimize speed and minimize latency, but then the security engineer rides in on his short bus throwing in a big, expensive choke-point telling everyone, “It’s for compliance!” This infuriates the network engineers who have to make unicorns puke rainbows in order to overcome the limitations of said security appliance. The sysadmins and DBAs are equally frustrated, because of the increased complexity in building and troubleshooting applications. And everyone waxes rhapsodic for those bygone days when the end-to-end principle ruled the internet.

But then I started to think about the original meaning of the term firewall and found the following in the Oxford American Dictionary:

 A wall or partition designed to inhibit or prevent the spread of fire. Any barrier that is intended to thwart the spread of a destructive agent.

I experienced a powerful moment of cognitive dissonance, realizing that a firewall isn’t supposed to prevent fire, just keep it from spreading. It’s really about containment. Maybe the problem isn’t in the technology, but our expectations. We don’t install locks thinking they are completely burglar-proof  any more than we believe that a house built to code in Southern California will prevent all earthquake damage. So why do we think we can keep the bad guys at bay with some technology? Even the US military, with its massive resources (i.e. our tax dollars), and large security firms can’t (Yes, RSA we’re going to talk about you for a very long time and not in a good way.).

Then I thought about my offhanded comment about firewalls being speed bumps. When I looked that up, I found:

A ridge set in a road surface, typically at intervals, to control the speed of vehicles.

The moral of this blog post is that your firewall was never intended to prevent fires aka intrusions. You use firewalls to slow down an attack or keep it from spreading too far into your infrastructure.  They’re only part of an overall security strategy which might include proxy servers, DLP, IDS/IPS and a solid incident response plan. And if you haven’t included remediation of an attack in this plan, then you’re in denial of the inevitable and what you really want is an airwall. Go unplug your uplink.  So back to the original question, “When is a firewall like a speed bump?” Answer, “When it’s doing its job.”

*No PCI-DSS auditors were harmed in the creation of this meme.

Filed Under: Blogs, Data Center, Security, Work Life Tagged With: , , , , , , , ,
About Mrs. Y

Mrs. Y is a recovering Unix engineer working in network security. Also the host of Healthy Paranoia and official nerd hunter. She likes long walks in hubsites, traveling to security conferences and spending time in the Bat Cave. Sincerely believes that every problem can be solved with a "for" loop. When not blogging or podcasting, can be found using up her 15 minutes in the Twittersphere or Google+ as @MrsYisWhy.

  • http://www.jsimmons.co.uk/ Jason simmons

    I view firewalls as policy enforcement rather than just security. Think of a bouncer at a night club “Sorry, policy enforcement operative”. She can turn you away if she does not like your face, or your clothes. She has to enforce what ever policy the night club owners want enforced. If bigger and faster black-hat “Policy enforcement operatives” come along, then the night-club policy can no longer be enforced.

    Think of the thousands that Sony, RSA and nasa have spent on firewalls. So you are right it is a checkbox. However the firewall is needed to enforce policy and determine where the policy might need amending and identify the policy violators.

  • H Pilkington

    I think it’s a little simplistic to say that firewalls do not represent a preventative control because there are ways to bypass them (poor implementation or architecture, exploitation of allowed services, mobile platforms, etc.) I don’t think I can name a single control that is, by itself, perfect. Even airgapped networks can be bypassed (see Stuxnet). But, speedbump?

    I think I can sympathize with the sentiment that tacking on security after the fact is badly done in most cases, and the strain of bad security implementation is as visible as bad network engineering. And those are definitely problems we should do better at working together to overcome.

    However the historical function of a firewall is not to watch what’s going on, it’s to limit the surface that must be watched. If you have an open door, you need a camera. But that doesn’t mean you should have no closed doors. Firewalls contribute as one part of a system to protect assets, and as you said, prevent the spread of potentially catastrophic events. But, if you doubt their usefulness, why not collect information about the drops (internal and external) as part of the case examining their benefit? Also, look at those monitoring tools you use to compensate for the firewall shortcoming, and multiply the resource consumption for watching the firewall allowed services by all those blocks.

    Because, realistically, the game isn’t to prevent compromise, it’s to know when it happens, limit the impact, and be able to respond to it, and I think that is the part of your point with which I wholly agree.

  • Ryan Malayter

    DLP? You really advocate DLP “solutions”?

    Tell me, does you DLP system catch the confidential memo paas a JPG into email?
    Or the text file where only the first letter of each line is meaningful data?

    Didn’t think so. I smell snake oil anytime someone mentions DLP.

  • Jay Swan

    I like your analogy. I wish I could find my copy of “Firewalls and Internet Security” to see exactly how they defined it back in the day. One of the problems I have with firewalls as a broad category is that to salespeople and box-checkers, the only thing that counts as a firewall is a big, complex stateful box with a huge price tag. Those might be the solution for some use cases, but for quite a lot of scenarios other solutions will work better and be simpler: simple stateless ACLs in a hardware switching platform (not vulnerable to state exhaustion attacks) and/or host-based filters (iptables, mod_security, etc). When building solutions like that it becomes harder to get sucked into the magic-security-box mindset that you lament here.

  • Dyuti999wk

    Stating the obvious with fancy words. It’s like a liberal arts major discovering how the world works for the first time.