Six Reasons Why Application Defense Doesn’t Always Belong at the Edge

Zane Lackey
Mar 14, 2017 · 7 min read
Security at the edge isn’t always the best choice.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

Signal Sciences Labs

The research and tech behind Signal Sciences next-gen web…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store