Securing the CDN Part III: Thinking Outside of the Edge

Previously we looked at increasingly popular multi-CDN strategies, and how best to secure them. This part takes a broader look at CDNs in general, and how bringing back your security from the ‘edge’ can improve the overall security of your web applications.

As we explained in the first part of this series, Content Delivery Networks (CDNs) have been around for a long time, and have developed into an effective way for delivering web content.  Content is stored on Points-of-Presence (PoPs) distributed globally at the ‘edge’ of the network, and when end-users request cached content, that content is served directly from the PoP nearest to them.

As CDNs gained popularity, CDN providers also began integrating security mechanisms into their networks, giving rise to the concept of ‘edge security’: when a new request arrives at the ‘edge’ PoP, it is also inspected against known security threats. If such threats are found, traffic is blocked; if not, it is allowed through.

This approach makes a lot of sense for CDN vendors, as it makes use of their existing infrastructure and – as the cost of CDN service constantly declines – is a cost-effective way of offering value-added services.

From a web application point-of-view, however, there are a number of critical challenges that arise from this approach.

[You might also like: Protecting the Multi-CDN Part I: The Security Challenge of Multi-CDN]

If all you have is a hammer, every problem is a nail

There’s an old adage, that if all you have is a hammer, then every problem looks like a nail. This is also true for CDN-based security. Since CDNs are all about web content delivery – to apply the metaphor – everything to them is an HTTP request. Their focus is on traffic itself, and relatively little thought is given to the underlying application. This creates a number of difficulties when it comes to web application security:

• No application context: CDNs focus mostly on HTTP/S web traffic, and have little or no awareness of the underlying web application, its structure, or vulnerabilities. As a result, CDN security policies tend to follow standardized templates that cannot adapt automatically per application-specific needs, or require heavy manual customization.
• Inbound traffic only: Since the role of CDNs is to accelerate website content, by definition they inspect inbound traffic to the website only. They do not have any capabilities to inspect (and protect) outbound network traffic, nor provide any data leakage prevention (DLP) functionality.
• Only on the cloud: CDNs are cloud-only services. As a result, by definition, they cannot provide premise-based or hybrid security solutions – or interface with existing premise-based security solutions – even when such solutions are required.

Negative by design

In addition to lacking application context, most CDNs adhere to a ‘negative’ security approach: that is, they allow everything through except what is explicitly blocked. That as opposed to a ‘positive’ security approach, which takes into context the nature of the legitimate traffic, and then blocks everything which is not legitimate. However, because of how they are designed, most CDNs are structurally unable to apply a positive security model:

• Predefined, static policies: ‘Positive’ security requires automatic self-learning, which involves looking at all traffic. However, since each CDN ‘edge’ PoP sees only a small sliver of total security, it cannot deduce what it means for traffic as a whole, and for all PoPs to communicate with each other would create far too much traffic overhead for the network to handle. Therefore, CDNs cannot apply real-time learning and must rely on predefined, static signatures-based security policies.
• Zero-day vulnerability: Since CDNs rely on a ‘negative’ security model with signature-based policies, by default they allow through all traffic except what is explicitly forbidden. Therefore, they cannot – by definition – deal with emergent, zero-day threats they had not seen before. They must wait for signatures to be manually configured by the vendor, and then be manually enabled by each individual customer.
• Long propagation time: Since CDN security filtering is done at the ‘edge’, security policies must be configured centrally and then propagated to each individual ‘edge’ PoP. As CDNs grow in size and volume of traffic, so does the amount of time that it takes information to filter down. In fact, it is not uncommon for CDNs to take up to several hours to propagate security updates across the entire network. When you are under attack, this time matters.

[You might also like: Protecting the Multi-CDN Part II: Approaches for Securing the Multi-CDN]

Built-in vulnerabilities

In addition to structural limitation in security approach, most CDNs also share a number of built-in security vulnerabilities as a result of their basic design:

• Dynamic content attacks: CDNs are built to cache static content and redirect dynamic content back to the origin server. Hackers know this, and therefore design denial-of-service (DoS) attacks that generate massive amounts of dynamic HTTP GET requests. Such attacks cannot be handled by ‘edge’ security mechanisms, and CDNs must resort to brute-force rate-limiting procedures which limit legitimate traffic to the website and result in high degrees of false positives.
• Forwarding loop attacks: Forwarding loop attacks are a mechanism in which malicious users manipulate the internal request forwarding mechanism of CDNs to cause the network to process requests repetitively, thereby effecting a denial-of-service (DoS) attack against the network. An independent study by computer scientists from the University of California, Berkley and Tsinghua University found that of 16 leading CDNs tested, every single CDN was vulnerable to some form of forwarding loop attacks. In particular, Dam Flooding attacks (which accumulate a large number of requests over time and then trigger them all at once) and Inter-CDN Loops (which create forwarding loops across multiple CDNs) proved to be particularly difficult to defend against.
• SSL-based attacks: As more internet traffic becomes encrypted, SSL floods are becoming a key attack vector because they demand large amounts of computing resources from target servers. CDNs, however, are poorly equipped to handle SSL-based attacks because they require customers share their SSL certificates (thereby reducing privacy) and decrypt each SSL packets individually on the cloud (thereby creating large amounts of latency), or else cannot protect customers from such attacks at all.

Stepping back from the edge

As we can see, CDN-based ‘edge’ security has a number of significant downsides, which leads to greater security exposure and more operational overhead. Many of these drawbacks stem from the ‘negative’ security model mandated by CDN design.

To overcome these shortcomings, customers should consider taking a step back from the proverbial edge and adopt security mechanisms based on ‘positive’ security, and which do not rely on CDN infrastructure to protect their web applications.