A couple months ago I decided to finally dig in and see whether WAFs (Web Application Firewalls) are really useful, or merely another crappy shiny object we spend a lot of money on to get the auditors off our backs.
Sure, the WAF vendors keep telling me how well their products work and how many big clients they have, but that’s not the best way to figure out whether something really does the job. I also talk with a bunch of end users who provide darn good info, but even that isn’t always the best way to determine the security value of a tool. Not all users have good visibility and internal controls to measure the effectiveness of the tool, and many can’t deploy it in an optimal manner due to all sorts of political and technical issues.
In this case I started with users, then checked with a bunch of my penetration testing friends. While a pen tester doesn’t necessarily understand the overall value of a tool (since they don’t have to pay the same kind of attention to compliance/management issues), a good tester most definitely knows how much harder a security tool makes their life.
The end result was that WAFs do have value when used properly, and may provide value beyond pure security, but aren’t a panacea. Since you could say that about the value of a gerbil for defending against APT too, here’s a little more detail…
- WAFs are best at protecting against known framework vulnerabilities (e.g., you run WordPress and haven’t patched), known automated (script kiddie) attacks, or when configured with (defensive) application-specific rules (whitelisting, although almost no one really deploys them this way).
- WAFs are moderately effective against general XSS/SQL injection. All the researchers said it was a roadbump for custom attacks that added to the time it took them to generate a successful exploit… with varying effectiveness depending on many factors – particularly the target app behind the WAF. The better the configuration, based on deep application knowledge, the more difficult the attack. But they stated that the increasing time to exploit increases the attacker’s costs, and thus might reduce the chances the attacker would devote time to the app and increase your probability of detecting them. Still, if someone really wants to get you and is knowledgeable, no WAF alone will stop them.
- The products often provide great analytics value because they are sometimes better than normal tracking/stats packages for understanding what’s going on with your site.
- They don’t do anything for logic flaws (unless you hand-code/configure them) or much beyond XSS/SQL injection.
- They aren’t as easy to use as is usually promised in the sales cycle. Gee, what a shock. Again, I could say this about gerbils.
In some ways, now that I’ve written this, I feel like I could have substituted “duh” for the entire post. Yet again we have a tool that promises a lot, is often misused, but (used properly) can provide a spectrum of value from “keeping the auditors off our backs” to “protects against some 1337 haxor in a leather bodysuit”.
But don’t let anyone tell you they are a waste of money… just make sure you know what you’re getting and use it right.
Reader interactions
3 Replies to “Web Application Firewalls Really Work”
Such an awesome post Rich. I have a small conclusion about WAF: Conclusion is Organizations cannot ignore the importance of application code review Whenever possible, the root cause of any security problem should be addressed before compensating controls Not all organizations have the capability to address security flaws at the code level Even well-coded applications may eventually be vulnerable to OS level attacks WAFs provide the compensating controls that many organizations need to protect their web applications.
While working on this part and exploring reviews i came to know that https://waf.comodo.com has good reviews. What is your pick?
I’ve always felt WAFs have value, but much like DLP, they’re not a slamdunk panacea. And it’s a panacea that so many people think they’re buying.
The biggest problems, building on some and avoiding other points you’ve already made:
– The WAF is only as good as the talented staff and time they’re given to tune, monitor, tune, monitor, and tune the damn thing. It’s not a network firewall that you can even just turn on and call good with a few default rules. You have to put time into them. If you protect 10 sites, you likely have to put 10x the time into it. This is difficult to drive into management heads who don’t like hearing this stuff.
– Vendors actively mislead potential customers in how easy they are to install and meet compliance (this is the trend in security). To be literal, they aren’t lying, but they’re setting everyone up to be violently disappointed.
– Many shops put in a WAF because compliance asks them to, and they’ve decided that proper code reviews, security testing, and other code development cycles things to make more secure code is too costly/tiem consuming. This automatically sets up a WAF to fail because it is already positioned as a fire-and-forget tool. Or fire-and-point-to-log-collector-and-forget tool. Or shuttled off into the sysadmin/ops teams since they do the logging and developers can’t be bothered with this timewaste…
– Which leads into…it’s a sort of in-between technology that isn’t necessarily a slam-dunk task for a development team, or QA, or security, or ops. It pretty much requires cross-expertise and assistance. This works for smaller codelines, sites, or teams. But those are just the teams that don’t necessarily have the broad experience and security chops in house. Get too big, and you run into silos that just don’t end up working together.
On the other hand, having a WAF that isn’t as effective as it could be, by a long shot, may be better than having no WAF at all as long as the expectations are aligned properly. Every little hurdle can have value.
You’re right. After making this overly long comment, I think I should be offering a “duh” as well! 🙂 But I’ll also say, properly handled (rare?) a WAF can be excellent.
I like this article on WAFs Rich. We, like most organizations, are unfortunately not running our WAF with a positive security model and that’s mainly due to development/engineering resource constraints which are impacted by their heavy workload. I think our WAF would be much more effective if we were running it ‘positive’.
It catches some XSS and SQL attacks and like you said, it’s not a simple tool to configure, nor is it a set it and forget it kind of technology; requiring frequent tuning and adjustment as well as rule adds to perform virtual patching for app logic and coding flaws that our developers don’t have time to fix.
The underlying application technology and the way the app code is written is the best place to start with security and a WAF added on top of secure code is just another, yet important, layer of defense.
– hspCD