Three Ways WAFs Fail
Ah, the WAF. You might know it by its street name: the web application firewall. It’s a long standing technology that has been handed down from generation to generation from datacenter to cloud to serverless. Rarely effective, largely disliked.
In the land of web application security, there are a few not-so-well-kept secrets, arguably none bigger than this:
The WAF survived not by being excellent, but by being mandated.
The WAF is an antiquated technology that was created to help stem the rise of application security vulnerabilities, which had been overwhelming organizations with their frequency of discovery. Static and dynamic analysis tools dumped huge quantities of bugs onto development teams that had no possible way to fix so many code issues.
Meant as a stop gap measure to address this problem, the WAF made it possible to filter out rampant SQLi, command execution and XSS attacks that were threatening to consume all of the development and security team’s available resources. The idea behind the WAF was that the application bugs and security flaws would be triaged for now, and then eventually fixed in the code at the root of the problem.
At the time, a drop-in web application security filter seemed like a good idea. Sure, it sometimes led to blocking legitimate traffic, but such is life. It provided at least some level of protection at the application layer — a place where compliance regimes were desperate for solutions. Then PCI (Payment Card Industry) regulations got involved, and the whole landscape changed.
PCI requirement 6.6 states that you have to either have a WAF in place or do a thorough code review on every change to the application. Given the unappealing nature of the second option, most organizations read this as a mandate to get a WAF. In other words, people weren’t installing WAFs due to their security value — they just wanted to pass their mandatory PCI certification. It’s fair to say that PCI singlehandedly grew the WAF market from an interesting idea to the behemoth that it is today.
And the WAF continues to hang around, an outdated technology propped up by legalese rather than actual utility, providing a false sense of security without doing much to ensure it. If that isn’t enough for you to show your WAF the door, here are three more reasons why WAFs should be replaced.
The Minimum WAF Rules Approach is Broken
A common side effect of a WAF implementation is the blocking of legitimate traffic. In the application security business, we call these false positives. Don’t be fooled by this innocuous phrasing — what it means is that customers aren’t able to buy things they want, or upload their latest vacation photos or generally use the functionality of your applications. It’s the kind of experience that can quickly turn current customers into former customers.
To combat WAF false positives, most companies run the bare minimum number of rules to get by. This means that only the most obvious and most egregious attacks are caught, while everything else just sails right past the filter. Simple rules mean easy-to-bypass rules, leaving you with an ineffective WAF.
Learning Mode is Broken at Speed
One way that WAFs try to cut down on false positives and avoid breaking valid traffic is through a “learning mode.” In learning mode, the WAF learns what normal traffic looks like versus what malicious traffic looks like and protects accordingly. A lot can be said about how tough it is to get learning mode right, even under perfect conditions, but let’s skip to the real problem we see in production environments.
Learning mode takes time. WAFs that need to learn to recognize “normal behavior” require a certain amount of traffic review before they can actively block everything else. It may take a few hours to learn safe application traffic patterns.
When you move from waterfall to agile and DevOps, deployment speed gets faster and faster. The application code changes weekly, daily or even hourly. If you deploy using anything close to a modern cadence, putting the WAF in learning mode on every code change means you are always in learning mode. Essentially, any kind of learning mode, when applied to modern application development techniques, just can’t keep up with the pace of production.
Monitoring Mode Really Isn’t Compliance
The fact that WAFs have survived due to legal mandates rather than effectiveness isn’t the only open secret in the business. You also won’t be shocked to hear that most companies never put their WAF into active blocking mode. After all, blocking mode has high false positive rates and breaks your legitimate traffic, so it’s the way to go only if you’re hoping to break your application.
Instead, the WAF is run in monitoring mode, where it watches traffic and logs any event as an attack. When it’s time for audit, the WAF gets flipped on for a short bit, then back off again. In reality, of course, some auditors don’t even care if you have it in active blocking mode. Just having a WAF in place is good enough for them.
Running your WAF in monitoring mode is not an effective control. All it does is add a false sense of security and additional overhead to the security team to evaluate logged events. In this scenario, you’re spending money where it doesn’t need to be spent while adding close to zero defensive measures.
I know I said three, but here is a bonus reason: CDN-based WAFs were for convenience, not effectiveness
The last not-so-fun thing about WAFs is their daily care and feeding. Your WAF adds complexity to your network, and having to dynamically scale it in the cloud is not exactly easy. Enter the content delivery network (CDN). Since most shops are already using a CDN to offload web application woes, why not add a WAF at the CDN layer? This meets compliance (yay!) and we don’t have to manage it (double yay!).
For many enterprises, this idea is the win-win that has allowed the WAF to persist even as its usefulness has been questioned. The problem with the CDN-based WAF, though, is that you end up running the WAF with a minimum set of rules again (see above or here), leaving the door open to all kinds of attacks. In fact, in my work at Signal Sciences, many customers use our web protection platform behind their CDN-based WAF and discover tons of real attacks that happily made it through the CDN.
If compliance is your main goal, go ahead and use a CDN-based WAF. If you want real defense, look elsewhere.
Achieve Compliance and Real Security at Speed
If this article sounds a little too familiar — if all you’re getting from your WAF is compliance — then it’s time to replace it. There are new options for adding defense at the web application layer and achieving compliance at the same time — for example, using runtime application self-protection (RASP) or next-gen WAF to provide application-aware defensive coverage. Shameless plug alert! This is what Signal Sciences provides for some of the largest web applications in the world. This means that, instead of just checking a box for PCI, you can be actively defending against the OWASP Top 10, account takeovers, instrument business logic and fight off bots, all without interfering with legitimate customer activity.
Don’t settle for compliance alone. You can achieve both compliance and real protection — and that’s what your business and your customers deserve.
