Week of War on WAF’s: Day 1 — Top ten reasons to wait on WAF’s
Hello, and welcome to the Week of War on WAF’s, the same week that ends whereby PCI-DSS Requirement 6.6 goes into effect as a deadline for many merchants. Today is the first day. So far, Marcin has identified some of the problems with web application firewalls. We were able to identify what we would like to see in WAF’s, both commercial and open-source in the future (since they do not work properly today). In this post, I want to start off the week by listing the Top ten reasons to wait on WAF’s.
Top tens reasons to wait on WAF’s
- WAF vendors won’t tell us what they don’t block
- Requires a web application security expert with code knowledge, HTTP knowledge, and a lot of time / careful planning to configure
- Gartner leaves WAF’s off their Magic Quadrant for web application security on purpose
- No truth in advertising leads to a false sense of security
- Vendors show signs of desparation, claiming imperatives and illegality in addition to just the standard FUD
- Attacks that are claimed to be blocked are coincidentally also found in WAF solutions themselves (e.g. XSS in the security reports or web configuration panels)
- Every organization that has installed a blocking WAF has also been in the media for known, active XSS and/or SQL injection
- Second-order (i.e. non-HTTP or unprotected path) injections cannot be blocked or even detected
- Real-world web application attacks are more often strings of attacks, or at the business logic layer — WAF’s cannot detect or prevent these kinds of attacks
- PCI-DSS Requirement 6.6 can be met with compensating controls, web application security scanners, automated security review tools, and/or manual review of the pen-test or code varieties
We understand and realize that the ideas of a blocking WAF are very popular right now. There are many supporters behind the WAF and VA+WAF movements. While we’d also like to support what the rest of the community sees as the future — we also want to make sure that it is the right thing to do.
One of the best ways to move forward with any given technology is to look at its faults. We learn best in IT when things fall apart — when they break. TS/SCI Security has put a lot of thought, practice, and research into WAF technology. Marcin’s most recent post demonstrates our list of requirements (e.g. block outbound) and nice-to-have’s (e.g. good documentation). Some vendors might already have this sort of outbound blocking functionality, and we’re not even aware of it! Other vendors could have clearly defined “VA+WAF blocking” documentation, which could even be internal engineering or strategy documents that should be out in the open (or at least available to paying customers).
Also — if we do end up demonstrating that WAF, VA+WAF, APIDS, ADMP, or other solution is less viable than a new, better idea — let’s move this research into the forefront.
It’s interesting how people think that a WAF can do a great job. This is just a tool to prevent script kiddies to attack using some variation of the [Enter Whatever Letter You Want]Snake Cheat Sheet!
A WAF (in production) cannot be an intelligent tool, cause I believe this is too risky for many companies; they want to know why a possible customer has been drop off their site like that, therefore, it’s only rules based. Big limitation, it’s only made of what we actually know…
I never believed into WAF’s as a solution.
But as long as compliances like PCI makes it a valid alternative to a *real* source code auditing or penetration testing job then we can’t blame WAF vendors. They are just selling what clients want. And clients do not always want security, sometimes they only want compliance.
@ Armando Romeo:
Yes, we can’t blame the vendors for the PCI-DSS standard. However, with the dollars they are spending on advertising, combined with the pull they have in other areas of marketing — I think we should hold them accountable for building this false sense of security. It’s just like they used to say about amateur/home-grown cryptography that was sold as commercial-quality/safe — something we used to call “silicon snake-oil”.
Also — I don’t really understand your argument. You think that customers that only want compliance should be allowed to do what they want. I agree — but they should be able to make educated decisions using fair and balanced information. While compliance may be misguided; WAF vendors’ marketing towards potential customers by using WAF as the primary control to meet a compliance standard for security purposes is misleading. Wouldn’t you call that (at the very least) irresponsible?
dre, I was agreeing with you and criticising with the false sense of security they sell.
Indeed, I agree with everything you said in my response. I realize I wasn’t clear in my first comment.
First of all, I don’t hate WAF, when they are used as a further layer of security (after a real assessment/pen testing or better source code analysis). Having that said let’s go on.
Compliances for some clients are just a way to show they care about customers data, and that if anything wrong (read disaster or read TJX) happens at least they can show good intentions against the court. And a WAF is considered “good intention” as of now. As good as a source code analysis. It’s sad but it’s what we have now.
The false sense of security is to blame to WAF vendors. While the increasing number of WAF sales is due to those (compliance) papers that makes them comparable to real security.
I would call it irresponsible. Yes.
WAF vendors sell more.
Companies can show they care and that they are compliant, that now means secure, saving on money.
The only party losing from all of this is the final customer.
The big problem with the new hype “WAF” is that managers of bigger companies who decide to buy and implement WAFs have not enough technical skills and background to evaluate if they are really necessary. The vendors have a lot of colorful presentation sheets to lure these guys into buying them to feel safe and sound. Even if managers ask technically skilled employees they don’t care much about in their opinion especially if there’s already a lobby for WAFs.
Moreover, managers have a certain budget for security and spend it on invest and not on additional staff (e.g. for improving the code quality) since invest is a one time deal (not regarding the maintenance fees now), and not running expenses.
Well, this is an oberservation of a really big company (>10000 employees) and I just ewanted to share…………
OK - thoughts on your top 10:
1) Duh? Same reason most app apps won’t say what they’re vulnerable to - I thought this would be common sense.
2) Agreed - a painful point
3) Agreed - interesting though…
4) No truth in advertising? Really? Noooo? (I’m layering on the sarcasm to make a point, everyone hypes their product; it’s the way things work)
5) There are but a few “desperate” vendors out there; and those are the ones who can’t sell their product (the rest are fine)
6) This isn’t shocking… programming a web app isn’t the same as writing a defensive tool - I know it sounds idiotic…
7) Bold claim - I’d love to see you back this one up with an actual fact
8 & 9) Same point - but worth mentioning. These are just inherent limitations to automated technology - and will likely never be solved by a WAF or other tools - developers have to solve this problem
10) Agreed, and those are likely the more sound solutions - but alas… as I wrote yesterday in an article on this topic… this is the “throw in a box and you’ll meet the requirement” solution. What CIO wouldn’t love one of these?
Good points, but you’ve got to back up some of your very bold claims, otherwise you’ll be accused of spreading the FUD you are preaching against. Careful, you have to be accountable as a critic lest you become as your target.