Let's talk Web Application Firewalls (WAFs)

Over the last month the level of chatter about Web Application Firewalls (WAFs) has increased significantly. At the end of last year I’d receive 1-2 emails per week with questions, but over the last month its up to 2 per day - not to mention all the mailing list chatter. I like to stay up-to-date on the WAF market, even though I’m not in that business, because the value proposition is complementary to mine (website vulnerability assessment). Just like network security with perimeter firewalls, patch management, and vulnerability scanning each is important and fills a unique niche. At first I thought the WAF interest up tick was mainly due to the looming PCI 6.6 deadline (June 30, 2008), not so much, the reasons are more fundamental.

You see, the InfoSec people responsible for Web security were usually not on the job when their employers’ websites were developed (insecurely). They were later hired in after the fact to solve the problem, typically once identified by a VA solution or maybe an incident, when preventative software security measures required massive code rewrites. Most of them first attempt an awareness program, a noble pursuit with long-term benefits, but doesn’t solve the immediate problems. The problems are too many websites, with too many vulnerabilities, developers who don’t work for them, and probably don’t care about Web application security anyway. In that position WAFs sound like pretty darn good option since it provides them with direct control.

Another interesting thing about WAF technology is that it’s been around for roughly 10 years, still their market really hasn’t taken off (roughly 1,000 deployments by my estimates), but it hasn’t gone away either. That’s probably because the idea of website security without having to fix the code is extremely compelling. Of course there are WAF detractors who say it’s because WAFs don’t do what they promise, are difficult to manage, and people shouldn’t use them anyway because their approach just serves as a band-aid. The fact is the WAF industry has a lot of baggage they must overcome originating from the early days, much of which does not hold true today. A lot has improved over the last several years and I’ve had the benefit of demo’ing these products personally. They have some serious power and flexibility.

Here’s the deal, nothing in security is a silver bullet. Everyone knows and gets that. So when a WAF isn’t perfect at something, doesn’t block every attack all the time, and can’t be plugged in and forgotten. That’s to be expected! And that’s what its all about, properly setting expectations. We really need to know what they can and can’t do and how well. Because from where I sit, we NEED WAFs to work, if nothing else but to provide development groups at least a few days of breathing room. I mean, consider the thousands of issues posted on sla.ckers.org, or XSSed.com, or in the WhiteHat Sentinel database. Is anyone really under the impression these will get fixed one at a time or anytime soon? And we’re just talking about the XSS. What about the rest?

I like WAFs because they provide Web security experts one more option to get their job done. Dozens of open source and commercial WAFs are available, the most prominent names being Breach, Citrix, F5, and Imperva. Each has its own strong points and better at doing something depending on the current situation. Navigating that environment is the tough part and the more VA solutions deployed like WhiteHat Sentinel, the more we’ll understand that remediation is going to be a huge issue to tackle in the years to come.