Several months ago I read a brief article going over some of the primary limitations of WAF which echoed my own personal viewpoint, and far better written than I could reasonably accomplish. While that part was very insightful, the last bit quickly descended into a sales pitch. Since then, I have wanted to reference that article at work, but couldn't really do so since the sale pitch was for a product that wasn't "ours". So I'm just going to poach the content I want, leave out the sales pitch, and credit the source. :D
Three Ways Legacy 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 legacy WAF has survived not by being excellent, but by being mandated.
The Web Application Firewall: An Antiquated Technology
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 legacy 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 legacy 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 legacy WAF market from an interesting idea to the behemoth that it is today.
And the legacy 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 legacy WAF the door, here are three more reasons why legacy WAFs should be replaced.
Reason #1 - The Minimum WAF Rules Approach is Broken
A common side effect of a legacy 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.
Reason #2 - Learning Mode is Broken at Speed
One way that legacy WAFs try to cut down on false positives and avoid breaking valid traffic is through a “learning mode.” In learning mode, the legacy 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. Legacy 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 legacy 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.
Reason #3 - Monitoring Mode Is Not The Same As Compliance
The fact that legacy 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 legacy 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 legacy WAF is run in monitoring mode, where it watches traffic and logs any event as an attack. When it’s time for audit, the legacy 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.
Bonus Reason: CDN-based WAFs Were Created for Convenience—Not Effectiveness
The last not-so-fun thing about legacy WAFs is their daily care and feeding. Your legacy 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 legacy 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.
Poached from Signal Sciences: https://labs.signalsciences.com/three-ways-wafs-fail on March 20th, 2019.
