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.

Generated from: dev.to/rly

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.

Recommended reading: The Ultimate Guide to Web Application and API Protection (WAAP)

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.

To combat false positives from legacy WAFs, most companies run the bare minimum number of rules to get by.

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 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.

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.

When it’s time for audit, the legacy WAF gets flipped on for a short bit, then back off again.

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.

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!).

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 (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.

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 a next-gen WAF. 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 (NGWAF) to provide application-aware defensive coverage.

This is what Signal Sciences provides for some of the largest web applications in the world. 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.

Discover how Signal Sciences next-gen WAF can help protect your most critical web applications, APIs, and microservices. Request a demo today.

Signal Sciences Next-gen WAF vs Legacy WAFs