Example of a public S3 bucket in AWS use case?

[adukes_splunk]

Does anyone have examples of how to use Splunk to check for a public S3 bucket in AWS?

[adukes_splunk · Accepted solution]

The Splunk Product Best Practices team provided this response. Read more about How Crowdsourcing is Shaping the Future of Splunk Best Practices.

Open S3 buckets are a common way for breaches to occur. People host files for quick transfer but forget to take them down or use S3 buckets for backups of sensitive data but inadvertently compromise permissions. If you have a corporate AWS environment, prioritize analyzing any open S3 buckets. Alternately, use AWS functions to automate remediation as described in the AWS Security blog post, How to Detect and Automatically Remediate Unintended Permissions in Amazon S3 Object ACLs with Cloud....

This use case is from the Splunk Security Essentials app. Check it out for more examples and demo data for this type of use case.

Load data

This use case depends on data from Amazon Web Services collected with the Splunk Add-on for Amazon Web Services. Deploy the Splunk Add-on for AWS and enable the necessary inputs. Pay special attention to the distributed deployment instructions to properly use the accompanying knowledge objects such as tags, fields, and so on required for this use case.

Get insights

Run this search to detect when new or existing S3 buckets are set to public. The PutBucketAcl events occur when bucket permissions are changed. The Splunk command spath is used to pinpoint specific portions of the JSON produced by the AWS data.

Best practice: In searches, replace the asterisk in index= with the name of the index that contains the data. By default, Splunk stores data in the main index. Therefore, index= becomes index=main. Use the OR operator to specify one or multiple indexes to search. For example, index=main OR index=security. See About managing indexes and How indexing works in Splunk docs for details.

index=* sourcetype=aws:cloudtrail AllUsers eventName=PutBucketAcl 
| spath output=userIdentityArn path=userIdentity.arn 
| spath output=bucketName path="requestParameters.bucketName" 
| spath output=aclControlList path="requestParameters.AccessControlPolicy.AccessControlList" 
| spath input=aclControlList output=grantee path=Grant{} 
| mvexpand grantee 
| spath input=grantee 
| search "Grantee.URI"=*AllUsers 
| table _time, Permission, Grantee.URI, bucketName, userIdentityArn 
| sort - _time

Known false positives: There are two types of undesired alerts that can occur from this search. One is when someone intentionally creates a public bucket. In this case, consider adding marketing employees that do this on a regular basis to whitelist or create a policy for how to create a public bucket, to exclude it. The other is when someone creates a bucket that is public momentarily, but then they switch it back to private.

How to respond: When this alert fires, ask yourself three questions. Is it still public? This is easy to detect, just search the logs for the bucket name and PutBucketACL, to see any subsequent ACL changes. Are the files public? and What is in it? These are tricky and you need to turn on server access logging on the S3 bucket. This is not the default, and can be inconvenient.

If no results appear, you may need to deploy the Splunk Add-on for Amazon Web Services to the search heads to use the knowledge objects necessary for simple searching.