To The Cloud, But Securely

By now, you’ve seen some breakdown of SaaS vs. PaaS vs IaaS, with respect to security. You’ve also probably seen the most common piece of security advice, which is “patch your (stuff)”. For Software-aaS, the service provider handles patching and system maintenance. Your security concerns are going to be negotiated in all sorts of legal contracts such as the infamous SLA or MSA. For Platform-aaS, you’re responsible for patching the application code and possibly the application server software your organization runs on that platform. The databases, operating systems, and everything else is the provider’s responsibility. For Infrastructure-aaS, you’re responsible for the application code and server, as well as the database server, middleware, and maybe even the operating system.

However, patches aren’t always the panacea we’re led to believe. With the recent MongoDB attacks, it was insecure default configuration leading to essentially open database access. These attacks preyed upon something that wasn’t technically a flaw. Where do insecure defaults sit with the various cloud service models? With SaaS, the secure defaults are the responsibility of the provider. The responsibility for security configurations in PaaS and IaaS service models is in a somewhat grey area. Establishing these responsibilities should be in the security checklist  when evaluating any Infrastructure or Platform as-a-Service. Don’t be afraid to ask service providers to audit their security practices, especially if you’ve chosen to a PaaS provider with MongoDB as an option.

All of this security advice-as-a-service is getting ahead of ourselves. Even if you’ve chosen a cloud service model, it’s important to know what components your providers and services run. When the MongoDB insecure defaults were announced, did you know if any of the cloud services used MongoDB? If so, did you know what versions were in use? This information, even if the patches or configurations were the provider’s responsibility is vital to your organization’s incident response process. For any cloud service model, identity and access control is a vital component for both the front-end and back-end. Where possible, identity federation for employee access to the front-end service and administrative access to the back-end helps centralize access control and auditing.

In the case of automated data exchange with a SaaS provider, the data stream must still be inspected and monitored for any signs of compromise on either end.

One of the most pervasive SaaS solutions in use today is a Content Delivery Network (CDN). As the primary delivery method for most web traffic has become encrypted over HTTPS, CDN services have been entrusted with the certificates and keys to provide valuable front-end traffic optimization. In most cases, the CDN is considered an additional layer to any good defense-in-depth posture. At a minimum, a CDN provides some amount of DDoS attack absorption. Many CDN solutions offer additional reverse-proxy functionality such as a web application firewall (WAF). For the most part, the inner-workings of CDN reverse-proxy infrastructure is something of a black box to everyone but the CDN provider.

In the wake of the recent Cloudbleed vulnerability in the Cloudflare CDN, many organizations will certainly be re-evaluating the level of trust assigned to their CDN provider. The reverse-proxy architecture in the Cloudflare CDN had an HTML parser which was leaking memory, which included everything from cookies to credentials to private messages. Ironically, it was this HTML parser that enables some advanced security functionality for Cloudflare customers. In this scenario, it was unclear if many Cloudflare customers had an incident response scenario for a corruption of their CDN function. Many Cloudbleed-affected services revoked their passwords or forced a reset for their users, just to be safe.

The lesson here is that no cloud service should be blindly trusted. While many cloud platforms, due to the scale of their operations, build security features like regular patching into the service offering, that comprises only part of the overall picture. Even for services migrated to the cloud, it’s vital to have incident response playbooks for all sorts of scenarios, from the latest CVE to a rogue service leaking data. The good news is that most cloud platforms are able to respond and remediate quickly, just as Cloudflare’s team was able to do. The responsibility is on the customer to make sure those service levels and incident response capabilities are in place at any cloud platform in use by the organization.