It seems like everyday you see a new report about a massive data leak caused by someone accidentally exposing files stored in AWS S3 Buckets to everyone on the Internet.
Many may remember Verizon’s infamous snafu that leaked data records for 6 million of their customers due to a misconfiguration in their S3 buckets.
Since then, there have also been a host of other S3 storage breaches in the news:
Amazon has put a lot of effort into making S3 access configuration as flexible as possible, but in doing so, they also made it easy to inadvertently expose your buckets and the objects inside them.
In fact, there are so many ways you could potentially expose your buckets that in trying to manually evaluate your configuration settings can become a giant headache, a process which is itself prone to human error. It’s no wonder these S3 storage breaches are becoming commonplace.
I wanted to take a moment to dive into this a little bit to explain how these misconfigurations occur, how you can try to manually check your own AWS S3 storage to ensure you aren’t making the same mistakes, and finally how you can use the Tripwire Enterprise Cloud Management Assessor to automatically assess your S3 Storage for any files that may be inadvertently exposed.
If you’re interests for securing AWS expand beyond S3 storage, I would recommend checking out the following post by Ben Layer: “Securing AWS Management Configurations By Combating 6 Common Threats.”
AWS S3, otherwise known as the Simple Storage Service, lets you store arbitrary objects inside of buckets.
URLs can be used to retrieve those objects assuming you have the appropriate permissions do so. For example, you (Read more...)
This is a Security Bloggers Network syndicated blog post authored by Chris Pawlukowsky. Read the original post at: The State of Security