CDNs (Content Delivery Networks) were a great invention. Put pieces of content at the edge of the network to speed up distribution and take the load off of your web and application servers. Now your servers aren’t bogged down sending all the gifs, stylesheets, and other static content so you can let the app servers focus on the dynamic bits instead of serving your logo for the millionth time.
While CDNs became popular among operations engineering, they also became a new tool to try to solve some other problems as well. When all you have is a hammer, many problems start looking like nails. One particularly difficult nail in the operations world is security and compliance. Since CDNs offer a layer fronting all the web servers, why not add in a WAF (Web Application Firewall) at that layer and knock off compliance along the way. Since hardware-based WAF’s were notoriously bad for slowing down traffic and triggering false positives, this seemed like a good idea.
However, as many organizations who have tried to implement a CDN-based WAF have learned, it’s often far more painful and complex than that.
CDN-Based WAFs Fall Short in 6 ways
There are six key areas where CDNs fall short in providing web application security that you would normally expect to get from a WAF.
Problem 1: Easy to Bypass
Are you a hacker and want to avoid the WAF? If you answered yes, you know 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.
Problem 2: Built on a Legacy Signature Approach
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.
Problem 3: Limited or No Application Context
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 critical business logic flows to alert if they are ever attempted to be exploited? For sure. Gaining this sort of coverage in practice requires instrumentation at the application layer (not at the edge) so that it can safely provide a feedback loop to developers and DevOps engineers without requiring everyone in the engineering team to have direct access to the CDN console.
Problem 4: Development != Production
When it comes to CDNs, your development environment most likely won’t have the same configuration as production due to cost and architecture restrictions. That means that developers may make a code change that works in their development environment but won’t work in production. Since the development and production environments don’t match, a CDN-based WAF will often trigger false positives in production that are completely unreproducible in development.
Debugging failures at this level is very frustrating because even if you have adopted a full DevOps approach and have developers deploying to production, access to the CDN console is still typically restricted to only your operations team. This level of restriction is understandable, as the multi-application nature of CDNs can cause one wrong change to cascade and cause a large scale outage. However, the trade-off here is a drastic reduction in speed and flexibility when making CDN changes, which means in practice a CDN-based WAF is not very friendly to any shops pursuing DevOps.
Problem 5: All or Nothing Deployment Model
Due to the way most organizations deploy their CDNs across an entire domain, you lose the granularity to ramp up the WAF in certain sections of your environment. Instead of safely phasing in a gradual progression of security defense, a CDN-based WAF implementation forces an all-or-nothing decision to turn on blocking mode across your entire site at once.
The all-or-nothing model limits flexibility to adapt security per feature or service. Imagine if the physical security at the world series was the same as your kid’s little league baseball game. Due to this all-or-nothing approach, you are forced to move to the lowest common denominator with more lax detection (see Problem 2).
Problem 6: Multiple CDNs Across Applications and Business Units
At large enterprises, where teams are adopting DevOps practices at different speeds and increasingly deploying their own cloud systems independently, there is often a wide variety technology platforms. This is especially true in acquisitions and separate business units, and these teams will often make different choices for CDNs due to their preferences and needs. This disparity between what controls are actually in place is a real problem for implementing security at the CDN layer. Security controls in this enterprise environment mean you have one set of controls for one team and a wholly different set for another, and even more with each separate business unit and M and A. In practice, this compounds the challenges facing not only CISOs and security teams but also development and DevOps teams who are trying to make sure their CDN ruleset aligns with every other CDN ruleset across the enterprise.