by Heidi Wachs | April 8, 2013 | Comments Off on Lessons from Amazon S3: Default isn’t a bad word
Default often has a negative connotation – what we settle for when there’s no better option. In information classification terms, we reinforce the idea of a default classification for things that don’t fit nicely into other categories. But in the case of Amazon’s S3 buckets the default is a good thing. So how did so many customers screw it up?
That’s right, this time it was the customer’s fault. A researcher from security vulnerability firm Rapid 7 discovered that the contents of one in six of Amazon’s S3 buckets are publicly accessible. The objects in each bucket aren’t all publicly accessible, but the names of the first 1,000 objects in each bucket are visible. In some cases, however, the objects were also publicly accessible. These buckets contained objects ranging from benign to highly sensitive. Examples of the contents included pictures for social media sites, source code, sales data, and employee data. My colleague, Kyle Hilgendorf explains the incident on his blog in a bit more detail and agrees – Amazon is not to blame.
But Amazon’s default setting for the buckets is private. Somewhere along the way, the customers controlling these buckets adjusted the settings and switched them from private to public. While in some cases this may have been intentional, let’s hope that where the bucket contained employee data or source code, it was not.
The bottom line: when organizations move enterprise data to the public cloud, they must be vigilant about that data’s privacy. The lesson here is not that this data shouldn’t have been stored in the cloud, or that each of these customers is on the hook for a breach notification (although some of them might be.) Amazon, and other cloud providers, offer a wide range of tools and controls for customers to protect the privacy and security of data being stored on their servers. Amazon developed a catalog full of documentation and guidance on how to use all of the security features. But the cloud providers can only do so much. At the end of the day the customers bear the responsibility for their settings.
So what can organizations do, or do better to protect the privacy of their enterprise data in the cloud? Here’s a checklist to get started:
- Determine who is the point person for each and every cloud deployment. If you don’t have a person in that role, delegate one. Make sure this person is intimately familiar with the full suite of controls offered by the cloud provider.
- Map the required privacy and security settings for each type of data stored in the cloud and align the controls and settings with each cloud provider accordingly.
- Educate the entire user community on how to preserve the privacy of data in the cloud. Provide step-by-step guidance on appropriate data handling and settings.
- Check and double-check the controls on a regularly scheduled basis to ensure that there haven’t been any unintentional modifications, such as switching from private to public.
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.