An organization that has transitioned to a cloud provider such as Amazon Web Services, Microsoft Azure, Google Cloud Platform, or any combination thereof should immediately be thinking about the configuration of cloud services as a key element to security.
Many IT leaders and professionals make the mistake of approaching security in the cloud the same way they approached security in a traditional data center. However, in the software-defined world of public cloud, there is an added wrinkle. Without a holistic approach to security which includes a view of configuration, you can easily open yourself up to undue risk. Configuration is an additional challenge when dealing with software-defined infrastructure in the public cloud. This is especially of concern when empowering developers and engineers with self-service for provisioning and configuration, who may not be familiar with security and having to deal with the rate of change in the cloud. Because cloud technology is always changing, it’s vitally important that we understand the configuration choices being made. Validating those configuration choices against security standards becomes far more important for most companies now than in the past because failing to do so, for example, in storage containers, can lead to the company data breaches that we continuously hear about in the news.
Storing remotely versus locally offers huge advantages to both consumers and businesses, however, storage container breaches are a constant in the news these days. Too many companies (Fed Ex, Alteryx, National Credit Federation, Verizon, Australian Broadcasting Corporation, Dow Jones, Deep Root Analytics, Robocent, Macy’s, Adidas, GoDaddy, SpyFone, etc.) in the last year alone, have exposed sensitive, personal information for hundreds of millions of people from around the world. This epidemic has seen the theft or loss of more than 9 billion data records in the last five years.
How are these attackers able to breach company storage containers?
Often times the storage container configuration is incorrect. The created container permissions may have been too broad which allows anyone to access the data. Again, these containers may have been serviced by people who aren’t familiar with security, thus the developer who created the container was unaware of how to properly secure it, or it was something as simple as an oversight. For example, let’s say a developer was troubleshooting an issue that was causing an application to fail and suspected the storage container access was to blame. The developer may have tweaked the storage container configuration leaving it open to the public, and as the application began working again, moved on to another project. Now that company has an exposed storage container. It may not have even been the developer’s fault as someone else may have altered the container’s configurations at a later date for any number of reasons. So many organizations are made vulnerable because a lot of them don’t have processes that prevent insecure software deployments.
How do organizations avoid exposing their storage containers?
For starters, you could do nothing. Amazon S3 buckets, for example, are private by default and can only be accessed by users that have been explicitly given access. Again, by default, the account owner and the resource creator are the only ones who have access to an S3 bucket and key, so someone has to actively misconfigure an S3 to expose the data.
Amazon has been actively working to help companies avoid breaches caused by misconfiguration. In November 2017 AWS added number of new Amazon S3 features to augment data protection and simplify compliance. For example, they made it easier to ensure encryption of all new objects and monitor and report on their encryption status. They have also provided guidance on approaches to combat this issue, like the use of AWS Config to monitor for and respond to S3 buckets allowing public access.
As a most basic first step to avoiding S3 bucket leaks, take advantage of the native AWS capabilities. Ensure that you are always purposefully using AWS S3 access policies to define who can access the objects stored within. Ensure your team is well trained to never open access to the public, unless absolutely necessary, as doing so can result in the exposure of PII and other sensitive data. And help prevent unauthorized access to your data by taking advantage of capabilities like AWS Config.
The challenge is that many organizations struggle to adopt and enforce best practices consistently, and only 100% consistency can ensure protection against a breach. This is why an investment in cloud operations is a vital additional step.
How does DivvyCloud help customers fix the problem?
DivvyCloud’s customers leverage bot automation to remove the public permissions from the access control list where necessary. Customers can also leverage bucket policies in place of access control lists for the finer-grained access control. DivvyCloud’s bot automation prevents data breaches by finding, alerting, and remediating misconfigured storage containers way before vulnerabilities are exposed.
It’s important to highlight one of the things DivvyCloud does well, is not only to flag the problem in real-time but to give customers an exact pointer to where the problem is. If somebody were to tell you “there is an open S3 bucket” but didn’t narrow down to a granular level, where would you start? This is why DivvyCloud doesn’t simply alert that there is an open S3 Bucket, we take action and inform the customer to exactly which bucket in which account.
In the end, the way to avoid exposing data in cloud storage containers is really common sense: Don’t ever configure the storage containers to be exposed to the public. Organizations need to learn about security configurations while evaluating their public cloud options or pay someone else like DivvyCloud, to do it for them. Otherwise, it’s only a matter of time before they join the 12 aforementioned organizations in the growing list of those who have to explain to their customers that their information has been compromised.
Install DivvyCloud today with a free 30-day trial and make these storage container misconfigurations a thing of the past (now and forever).
DivvyCloud mitigates security and compliance risk by providing virtual guardrails for security, compliance, and governance to customers embracing the dynamic, self-service nature of public cloud, and container infrastructure. Customers like General Electric, Discovery Communications, and Fannie Mae run DivvyCloud’s software to achieve continuous security governance in cloud and container environments (AWS, Azure, GCP, Alibaba, and Kubernetes). First, our software performs real-time, continuous discovery of infrastructure resources allowing customers to identify risks and threats. Second, customers can implement out-of-the-box or custom cloud-native policy guardrails that identify and alert on violations. Third, we automate the enforcement and remediation of these policies.