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 handed down from generation to generation, from data center 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 more significant 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 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 vast quantities of bugs onto development teams that had no possible way to fix so many code issues.
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 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 a good idea. Sure, it sometimes leads to blocking legitimate traffic, but such is life. It provided some protection at the application layer — 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 exciting 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 blocking 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 can’t buy things they want, upload their latest vacation photos, or generally use the functionality of your applications. It’s the experience that can quickly turn current customers into former customers.
To combat false positives from legacy WAFs, most companies run the bare minimum number of rules to get by. This means that only the most prominent and egregious attacks are caught, while everything else goes past the filter. Simple rules mean easy-to-bypass rules, leaving you with an ineffective WAF.
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 regular 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 learning mode, when applied to modern application development techniques, 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 favorable 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 an audit, the legacy WAF gets flipped on briefly, 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 that doesn’t need to be spent while adding close to zero defensive measures.
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 dynamically scaling it in the cloud is challenging; enter the content delivery network (CDN). Since most shops already use 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!).
The problem with the CDN-based WAF is that you end up running the WAF with a minimum set of rules, leaving the door open to all kinds of attacks.
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, leaving the door open to all kinds of attacks. Many customers use our Web Protection Platform behind their CDN-based WAF and discover many actual attacks that happily made it through the CDN.
If compliance is your primary goal, use a CDN-based WAF. If you want real defense, look elsewhere.
Our next-gen WAF is designed to protect the modern web.
If this article sounds a little too familiar — if all you’re getting from your legacy WAF is compliance — then it’s time to move to the Next-Gen WAF. This is what Fastly provides for some of the largest web applications in the world. Instead of just checking a box for PCI, you can defend against the OWASP Top 10, account takeovers, instrument business logic, and fight off bots without interfering with legitimate customer activity.
Don’t settle for compliance alone. You can achieve the compliance and real protection your business and customers deserve. Discover how Fastly’s Next-Gen WAF can help protect your most critical web applications, APIs, and microservices. Request a demo today.
