Misconfigured AWS S3 buckets are among the most common causes of data breaches for organizations operating in the public cloud. In many cases, the organizations affected aren’t able to identify the misconfigurations behind these risks until a malicious actor does it for them and it’s too late to protect their sensitive data.
Today we’re going to look at an example of a misconfigured AWS S3 bucket that attackers were able to access, and walk through what your organization can do to identify these kinds of misconfigurations, understand the potential impact, and establish automated governance policies to prevent these risks from going unnoticed for too long.
Here is the code for our example:
The primary issue here is an extra line to an S3 bucket policy—s3:PutObject. It’s easy to see how this could happen at any organization, as the policy may be put in place temporarily for troubleshooting and simply left unchanged when the job’s done.
The issue we face is that the public cloud just has a lot more eyes looking for any little misstep or misconfiguration to exploit. While data breaches still occurred when everything lived in the data center and the only internet-facing resources were websites in a DMZ, the number of knobs and dials that we had to configure was much smaller. Today, there are so many settings available in the cloud that making a mistake is easy, but finding where you did it is extremely difficult. That is, until someone else finds it.
How to create policies to look for misconfigured AWS S3 buckets
How many of you are now concerned that you have the same S3 bucket policy risk in your AWS environment? How you find this policy is the real challenge. There is no good way within AWS to search for policy statements and see what resources are attached to those policies. This is where CloudHealth Secure State can help.
Over the last year, CloudHealth Secure State has gone through a major upgrade to a new data model which enables our customers to query the configuration settings and metadata of objects to see how they are connected to other objects.
For the example highlighted above, this means you can query the data model to answer questions like, “Do I have any policy that has S3:PutObject?”
Here is how you would accomplish this:
- First, go to Explore and select the account you want to query
- Next, start with the Policy, for this example the object AWS.IAM.PolicyStatement
- Then, search for specific criteria, s3:PutObject, and principle to *
- Next, you are going to tie the policy to any buckets
Here is the query that you can use:
AWS.IAM.PolicyStatement HAS Action = “s3:PutObject” AND Principal = “\”*\”” -> AWS.IAM.ResourcePolicy -> AWS.S3.Bucket
And here is how the results would appear in the platform:
The next step is to convert this query into a rule and configure alerts to specific teams or users in your organization anytime this rule is violated. The key is to develop the policy to notify the people who can resolve the configuration as quickly and easily as possible, and to deliver those notifications through the communication tools that those people use most frequently.
For more recommendations on how to adapt your security processes for a cloud environment, check out our in-depth whitepaper, Building a Successful Cloud Infrastructure Security & Compliance Practice. If you’d like to learn more about what you can do to improve cloud security posture management, schedule a demo of the CloudHealth Secure State platform today.
