Wield App Firewalls with Caution

Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  
When I'm discussing software security with my clients, questionsinvariably turn to application firewalls.

When I first heard of these products a few years ago, I was immediatelypredisposed to not liking them. They seemed to me to be yet anothersecurity product IT managers would try to plug into their networks tosomehow retrofit security to the applications they're charged withrunning. It's long been my view that this sort of perimeter mentalitydoesn't work well and does little more than provide a false sense ofsecurity.

However, I was recently at a regional meeting of the Open Web ApplicationSecurity Project (OWASP) in Belgium where the topic of applicationfirewalls was heavily debated. Now, I have to admit my opinion shifted atleast slightly during the discussions, and I wanted to take theopportunity to talk about that here. I'll warn you, though, I'm still nota believer, but I do recognize there can be circumstances when appfirewalls can add value.

Let's start with a real quick description of the technology, and thenI'll describe where it might be useful under certain circumstances.

Application firewalls, like their traditional counterparts, are meant toprovide a layer of security in front of web applications. Normally, theycan operate in either of two modes.

One mode of operation passively watches the network for indicators ofknown attack profiles, such as attempts to overflow software buffers, SQLinjection, cross-site scripting, etc. When these are detected, they blockthe traffic from passing and/or provide detailed logging of the traffic.

A second mode of operation involves the app firewall interposing itselfentirely between the web app and the outside world, and thoroughlyscreening all input/output to ensure it complies with the traffic theapplication is expecting. For example, when the application is expectinguser input in the form of a name, address, phone number, etc., the appfirewall ensures the incoming data contains what appears to be just that.

As you might reasonably expect, the second mode of operation provides agreater degree of protection to the web app, but also requires a fargreater degree of integration to be effective. Blocking legitimatetraffic from getting to the application is the quickest way of gettingthrown out of the data center, after all.

Impede business at your peril!

So, all of this sounds pretty good, right? Then why do you suppose I'mnot a supporter of the technology?

My biggest fear with app firewalls is that they lead software developersto not pay adequate attention to the security of their applicationsbecause ''someone else is taking care of that''. That sort of crutch canonly result in bad application security, in my view, and will inevitablycause you grief. Mark my words on that.

I heard an argument at that OWASP meeting, however, that made me pause inmy opposition. In an environment that includes a large number of legacyapps or one that includes a large number of third-party apps, there couldwell be some value to app firewalls. For one thing, they can represent ameans of enhancing the security of these deployed apps that is more costeffective than trying to retrofit software security into them from theground up.

Let's face it, no enterprise that has all of a sudden seen the softwaresecurity light is going to go back and redesign/rewrite all of their appssecurely in one fell swoop. If their deployed apps are vulnerable to SQLinjection and other web app ailments, plugging some web app firewalltechnologies in front of them can be a cost effective means of getting tothe goal without breaking the bank.

That is, if app firewalls are used wisely, they can effectively augment asoftware security initiative. I maintain app firewalls are not a suitablealternative to software security, but they can provide some immediaterelief to real world legacy software problems.

There's another benefit to web app firewalls I would be remiss if Ididn't mention here. They can and do add a level of event logging at anapplication layer all too many applications are sorely lacking. Assomeone who has spent years running incident response operations, I cansay that, in and of itself, would be a major benefit in productionenvironments.

Again, though, I still feel they're not a cure for the problem of writingbad code.

So, this certainly falls short of being a blanket endorsement for web appfirewalls, but I feel they're a pragmatic compromise to practicalcircumstances. They can add value, but should be wielded with duecaution. To deploy web app firewalls at the expense of an otherwiseeffective software security initiative is the real danger I feel shouldbe avoided at all cost. But they can help us get to where we need to be abit sooner.

Those of you who are interested in learning more about applicationfirewall technologies can find some additional reading on the Departmentof Homeland Security sponsored website, Build Security In. They have apaper (that I co-wrote) that can be found