Six Reasons Why Application Defense Doesn’t Always Belong at the Edge
CDNs (content delivery networks) were a great invention. They 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 the 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, so why not add in a WAF at that layer and check 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.
6 Ways CDN-based web application firewalls (WAF) fall short
There are six key areas where CDNs fall short in providing web application security that you would normally expect to get from a WAF.
1: Easy to bypass
Are you a hacker and you 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.
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.
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 have direct access to the CDN console.
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 developer 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 due to the multi-application nature of CDNs one wrong change can 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.
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 a 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 item 2).
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 are 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&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.
Defending Applications In A New Way
As engineers and CISOs who were in the trenches and ran into these problems ourselves trying to make legacy WAFs work while embracing DevOps and Cloud, we built Signal Sciences specifically to address the problems mentioned above. Let’s take those problems in turn and share how we solve them.
No bypassing allowed
Signal Sciences can be deployed in the location that’s most convenient for the business, whether that’s in the web server, inside the application we are protecting, the application runtime, or as a reverse proxy. We inspect all traffic and attackers can’t play DNS games or use special HTTP headers to skip Signal Sciences analysis.
Out of the box rules that just work (seriously!)
At Signal Sciences we use a libinjection approach to tokenize and parse inputs for attacks. This approach was built from the ground up as a replacement for legacy signature-based approaches, and means customers are able to deploy us in ways they never could with a legacy WAF. Specifically, over 95% of our customers have us in full blocking mode for their production traffic without any sort of tuning or false positives.
Add application context to defend against what matters most
Let’s face it, XSS and SQLi are important to defend against but they’re only a piece of the overall picture. We not only defend against the classic OWASP Top Ten, but also look deeper. With Signal Sciences, you can also defend against the security issues that often matter the most to the business: account takeovers, sensitive business functionality being abused, fraudulent account activity, and application-level DDoS attacks.
Development and production have parity
Our customers run us on production traffic in full blocking mode without fear of breaking their application. One of the reasons for this is that they are also able to run us on their staging or pre-production site as well. Since we take a software-based agent approach to our architecture you can deploy us on dev, stage, and prod. We scale with modern web application, microservices, containers, and API models in the cloud, without having to install physical box after box after box.
Work natively with the DevOps toolchain
No one needs yet another security system to have to monitor, or another dashboard to be constantly refreshing. Signal Sciences was built from the ground up to natively integrate into the toolchain your engineering teams already use, whether that’s PagerDuty, OpsGenie, Slack, HipChat, JIRA, Datadog, or (many) others. Additionally, the Signal Sciences platform was built API-first so it’s seamless to integrate with any SIEM systems like Splunk, ELK, QRadar, and others.
Consistent approach across your applications
Since Signal Sciences can be deployed in numerous ways on a wide variety of platforms, customers can easily scale their application defense coverage across the entire organization regardless of the technologies used by different teams. At Signal Sciences, we come from a production web operations background. We know the key to getting security controls deployed is providing operational flexibility for teams in terms of how they want to deploy. To that point, we produce support for a wide number of deployment options, whether that’s plugging in to the web server, an application runtime, or the application itself.
Learn more
Signal Sciences is the industry’s first Web Protection Platform (WPP) providing both Next Generation WAF as well as RASP technologies. Signal Sciences WPP was built in response to our own frustrations of trying to use legacy application security approaches while enabling business initiatives like DevOps, cloud adoption, and CI/CD. The Signal Sciences Web Protection Platform (WPP) works seamlessly across cloud, physical, and containerized infrastructure, providing security without breaking production traffic.
