Adopting a multi-CDN approach can be great for performance, but can also create some complex security challenges.
Using a Content Delivery Network (CDN) to accelerate content delivery has been common practice for many years. In fact, it is rare nowadays to find a website which does not employ a CDN to enhance webpage performance.
Increasingly, more and more organizations are adopting multi-CDN solutions, which split their traffic among several CDNs to ensure constant availability. But while adopting a multi-CDN strategy can be great for website performance, it can also create some unique security challenges for your website.
98% CDN availability = 7 days of outage a year
CDNs have been around for many years now. There’s a CDN out there for every pocket and every need. It is surprising, therefore, that even a mature technology such as CDN hasn’t yet been able to bridge the final availability gap to ensure true always-on availability.
Although some CDNs promise 100% uptime SLA, in practice most CDNs don’t get anywhere near that. CDN performance metrics tracked by web optimization provider Cedexis demonstrate how even leading CDNs only provide, on average, about 98.5% of uptime.
While this may sound pretty good, consider this: every 1% of downtime equals about 3.5 days of outage per year. A 98.5% availability benchmark, therefore, is equal to about 5.5 days of downtime annually.
An example of Cedexis’ performance data – updated daily – of leading CDNs is shown below (CDN provider identities have been obfuscated).
Enhancing performance with a multi-CDN strategy
One solution customers have come up with in order to avoid CDN downtime is to split their traffic among two or more CDNs concurrently. Application traffic is routed dynamically between CDNs based on availability, performance, cost, and proximity to the end user.
Adopting a multi-CDN approach is hardly a new concept. As early as 2014, Ernie Regalado of Bizety explained how some of the largest enterprises are splitting their traffic among two, three, or even four separate CDNs. Recently, however, multi-CDN solutions have been gaining momentum as new multi-CDN solutions are making it easier and more cost-effective to deploy.
Nonetheless, while a multi-CDN strategy might be great for performance, it can create some unique security challenges for companies, particularly those who also rely on their CDN vendor for security.
Splitting your traffic also means splitting your security
As CDNs evolved, many CDN vendors also began integrating web application security into their delivery stack. While this makes sense from the CDN vendor’s point-of-view, it also burdens the customers with the legacy shortcomings of CDNs: inconsistent availability, varying security service quality, and the drawbacks of having security at the ‘edge’ of the CDN.
Moreover – in the context of multi-CDN strategy – splitting your traffic among different CDNs also means splitting your security.
Consider, for example, the following hypothetical scenario of splitting traffic between three CDNs and their respective security portfolios:
- CDN 1: High-quality CDN service; ModSecurity-based WAF; separate DDoS scrubbing; relies heavily on professional services for configuration; very expensive
- CDN 2: Low quality CDN service; proprietary WAF; no standalone DDoS scrubbing; easy-to-use management console but no MSSP service; very cheap
- CDN 3: Medium-quality CDN; No WAF at all; DDoS scrubbing provided via 3rd party; mid-range price
A scenario such as the one above raises a number of security challenges:
- Clashing security and cost concerns: as the scenario above demonstrates, CDNs can vary significantly in terms of cost, quality, and breadth of security protection. However, adopting a multi-CDN strategy is usually driven by a desire to increase availability and/or decrease cost. As a result, a cost-driven or availability-driven decision of which CDN to use can lead to situations where traffic isn’t properly secured. Moreover, as multi-CDN load-balancing doesn’t factor security into consideration, there is also no visibility into whether traffic is protected or not.
- Inconsistent protection across vendors: there is a wide array of CDN vendors out there, and equally wide variance in the breadth and protection offered by each CDN: some bundle a web application firewall (WAF) into their offering, while others don’t; some provide native DDoS scrubbing capabilities, while others don’t; and so on. As a result, it is nearly impossible to reach parity in security features between any two CDNs.
- Varying, redundant security policies: if you have three different CDN vendors, you will need to configure your security policies three times – once for each vendor. Apart from the added overhead this creates, there is wide variance in the particulars of each security policy configuration: different vendors use different technologies and different rule sets, with some using open-source technologies from ModSecurity or OWASP, while others employ proprietary solutions. This leads to incompatible security policy configurations and gaps.
- Separate management consoles: similarly, each CDN vendor provides a different management console, with some providing feature-rich, hands-on GUI consoles, while others provide very rudimentary self-service options and mandate the usage of professional services for nearly every change. In a multi-CDN/multi-security scenario, this creates a problem of having to update separate configurations using separate configuration processes every time there is a policy change.
- No central reporting: finally, splitting traffic between different CDNs also means that there is no central reporting. Security becomes effectively siloed, and it becomes difficult – if not impossible – to aggregate attack data across the different channels, locate attack sources, analyze defenses and look across the entire security range.
Securing the multi-CDN
Clearly, a scenario as the one described above is untenable, as it would lead to inconsistent protection and high amount of overhead in managing concurrent security configurations.
Therefore, in order to be truly secure, multi-CDN deployments requires a different approach to web application security – which is not dependent on the CDN.
Part II of this series discusses different alternatives for securing the multi-CDN, and describes the considerations for on-prem, cloud, and hybrid solutions.