It’s annoying when we use acronyms as verbs, isn’t it? I can change, maybe. JIRA me and I will get on that. It is bad grammar, yes, but who wants the more boring title: Oops, I put a Web Application Firewall on my Caching Tier. It just misses the appropriate zinger-effect. Also, using this acronym as a literary approach accomplishes the very thing security engineers did by trying this ill-conceived technique: lessening cognitive burden by abstracting complexity.
Well, no matter, here you are, stuck with this somewhat zany title and hoping it all gets better from here. Let’s take a step back and elucidate what we are talking about. What is all this WAFing my cache business?
Enter the CDN
Now my application performance issues are solved, I can get on with more important business. Or can I? The plot thickens.
Enter Compliance Stage Right
Amidst caching all things, we were also beset by the onslaught of the cyber villains and the resulting compliance regimes. Businesses everywhere realized (or were forced to realize) that they needed some level of defense for application security, however the hardware-based, legacy WAFs often slowed things down and broke traffic. I have written about this previously in my post Three Ways WAFs Fail. What could be done?
Somewhere along the way, we crafted the idea that putting a WAF on the CDN would somehow be a better approach to WAFs. The cache is already fronting web traffic and even though it is completely untethered to the application, it seemed to make the compliance people happy. Since caches don’t refresh frequently, the rules for WAFs had to be really flexible, which resulted in less broken traffic. All in all, on the surface it looks like a win-win. Unfortunately, that just isn’t true.
4 Reasons WAFing your Cache is a Bad Idea
1: CDN WAFs are Easy to Bypass
As an attacker, the easiest thing you can do is bypass the CDN and route directly to the origin. Why attack through the CDN if you can go straight to the unprotected web servers? This is pretty well known and there are lots of approaches to bypass CDN-based WAFs. The solution to this issue often ends up causing so much management overhead and operational complexity that the vast majority of companies find the “fix” worse than the problem.
2: Forced to Compromise Security Effectiveness
Legacy, signature-based detection is the foundation for CDN-based WAFs, as most of the products that exist in this space use a very stripped down version of the ModSecurity core rule set. Back in the early 2000’s when ModSecurity was built, this approach was fine because application architectures were so simple. The problem is that over the last decade, applications have dramatically changed in complexity, and continuing to apply the same legacy signature-based approach today causes false positive headaches which consistently break application traffic.
To reduce false positives, it becomes necessary to either shrink your signatures to a minimal number—dramatically reducing defensive coverage in order to reduce false positives — or increase spending on professional services for additional tuning — which not only costs extra, but also becomes yet another blocker to deployment timelines.
3: No Application Context in the Cache
At the CDN layer, you can customize to your application context a little, but on the whole, a more generic approach has to be taken. For example, are OWASP Top Ten attacks more interesting among your authenticated user base than random unauthenticated scanners? I bet so. Wouldn’t it be nice to instrument for application abuse and misuse? For sure.
Gaining this sort of coverage in practice requires instrumentation at the application layer, rather than at the edge. This application aware context is exactly the type of information developers crave, but by moving instrumentation so far away, we reduce our ability to provide it.
4: Fosters Silo Mentality
By it’s very nature, CDN access isn’t spread around to developers and security. It is meant to be part of the tech stack that isn’t interacted with in terms of configuration. Sure, developers hit the API to refresh the cache or invalidate on a new build. But if you put a WAF there, will you now give direct access to everyone in the engineering team for the CDN console? Probably not. Instead of creating a feedback loop, it fosters a silo mentality that is divergent of the best practices of DevSecOps.
If this article hits a nerve with you, it might be time to consider 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. This means that, instead of just checking a box for compliance, 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 — it’s what your business and your customers deserve.