When breaches occur in public clouds, we almost always place the blame on users. Primarily, users are blamed for misconfigured servers and firewalls that allow outsider access into the creamy data center.
Our latest SANS survey on cloud security backs up this assertion. Of those organizations that experienced a breach in their cloud environments, 42% pointed to misconfigurations as a root cause, second to account and credential hijacking.
However, the media reports blaming users for their breaches doesn’t take into account how difficult it is for organizations to nail down their cloud security controls.
Complexity Is the Enemy of Security
Instead of making their jobs easier, moving workloads and development to the cloud has increased complexity of security management, leading to a shortage of skills. In our SANS cloud security survey, the largest group of respondents (28%) cited “Lack of skills or training within the organization for specific public cloud services” as their biggest concern around their cloud environments.
And that’s the other thing. Just over 50% of respondents reported that they use between two and six public cloud providers. Considering each provider has its own security and configuration rules for servers, apps and containers, this makes universal risk management even more difficult.
Shared Responsibility
Ultimately, cloud workload security is a shared responsibility between the infrastructure provider and its users. By sharing responsibility for configuration-related breaches, cloud providers can make improvements to help prevent organizations from making costly mistakes in their cloud environments.
For example, breaches against Amazon Web Services (AWS) users misconfiguring their S3 buckets prompted AWS to update its S3 buckets over the past few years to help prevent misconfigurations and poor access controls leading to the breaches.
In another example, a server-side request forgery (SSRF) attack on a Capital One firewall in the AWS cloud exposed data on 100 million Capital One customers in 2019. The breach prompted U.S. senators to send a letter to the Federal Trade Commission (FTC), suggesting that AWS shared some blame because it hadn’t built in protections against SSRF, unlike Microsoft and Google, which have integrated SSRF protections into their products.
Continuous Monitoring
Microsoft learned a lesson on continuous monitoring of its internal cloud apps because of a configuration error on five of its Elasticsearch servers. This misconfiguration exposed 250 million customer support records for most of December 2019. (Microsoft didn’t even find out about the breach until notified by an outsider.)
“Misconfigurations are unfortunately a common error across the industry. We have solutions to help prevent this kind of mistake, but unfortunately, they were not enabled for this database,” wrote Ann Johnson, Corporate Vice President, Cybersecurity Solutions Group, and Eric Doerr, General Manager, Microsoft Security Response Center, in a follow-up Microsoft blog. “As we’ve learned, it is good to periodically review your own configurations and ensure you are taking advantage of all protections available.”
For their part, leading cloud providers, including AWS, Microsoft and Google, provide a variety of solutions for embedded security, third-party purchases and migrated security through their online stores. AWS is also working with SANS on an educational series around how to use these tools, because, as stated earlier, deployment and security management differs from cloud to cloud.
“Security misconfiguration of cloud services has become a recurring theme,” says SANS instructor, Lee Neely. “Rapid deployment of solutions needs to include independent verification of the security settings prior to production release. When implementing services, particularly cloud-based, be sure to enable verification and monitoring of the security baseline.”
