Automatically Remediate Publicly Exposed S3 Buckets

In this blog, we will discuss how S3 bucket exposures are automatically remediated using an open source project called Dome9 CloudBots.

What are Cloudbots?

Back in June 2018, we released an open-source project called CloudBots. You can read more about it in this product launch blog.

CloudBots consists of a set of automatic remediation solutions built on top of Dome9’s continuous compliance capabilities. It essentially is a library of AWS Lambda functions that enable you to take action on specific violations that would reduce the time to resolution for these events.

To set it up, you can navigate to the Dome9 CloudBots Github and follow the onboarding steps. FYI when you launch the CloudBots stack in your AWS environment, it creates an IAM role that has been granted permissions to take necessary remediation actions.

We will now deep dive into the technical architecture.

Remediation Architecture for Exposed S3 Buckets

Step 1: Detection with Dome9 Continuous Compliance

Using Dome9 Compliance Engine, you can easily setup a continuous compliance policy to periodically check your AWS environment and flag any exposed S3 buckets.

First, you can create your own specific S3 remediation bundle and use Dome9 GSL to create a rule to detect all exposed S3 buckets. The auto tag highlighted below is the event trigger to activate the appropriate CloudBot for remediation across all exposed buckets. In this case, we want to delete all S3 ACL and/or bucket permissions.

The Compliance Engine highlights that there are two buckets exposed (demo bucket 1 and 2)

Next, with a few clicks, you can setup this bundle as part of a continuous compliance assessment that periodically scans your AWS environment for exposed S3 buckets.

These Compliance Engine findings are then sent to an Amazon Simple Notification Service (SNS) topic, to which the Dome9 Cloudbot Lambda Function subscribes to.

Step 2: Triggering CloudBot via SNS Findings

Below is the snippet of the SNS finding for demo-bucket 2 (that highlights exposed bucket permissions)

	"status": "Failed",
	"policy": {
		"name": "Dome9CloudBots Autoremediation"
	"bundle": {
		"name": "Remediate-S3",
		"description": "REMEDIATION BUNDLE"
	"reportTime": "2018-10-12T23:26:38.361Z",
	"rule": {
		"name": "S3 should not be publicly accessible",
		"complianceTags": "AUTO:s3_delete_permissions",
		"severity": "High"
	"account": {
		"id": "12345678910",
		"name": "AWS",
		"vendor": "AWS"
	"region": "N. Virginia",
	"entity": {
		"policy": {
			"Version": "2012-10-17",
			"Id": "MyPolicy",
			"Statement": [{
				"Action": "s3:GetObject",
				"Resource": "arn:aws:s3:::demo-s3bucket2/*"
		"id": "demo-s3bucket2",
		"type": "S3Bucket",
		"name": "demo-s3bucket2",
		"accountNumber": "12345678910",
		"region": "us_east_1"

The compliance rule (that was created way above) detects both bucket exposures and logs a failed output to SNS. The demo-s3bucket2 above is detected as public because it has a bucket policy allowing anyone (Principal=”*”) to access and retrieve data. Similarly,demo-s3bucket1 is detected as public due to public ACL grants.

 Subsequently, theAUTO tag in the SNS output invokes the appropriate cloudbot for automatic remediation.

Step 3: Cloudbot for S3 Remediation

The executes to delete the bucket policy and/or ACL grants for the buckets. Below is a snippet for easier readability, for a complete code walkthrough, check out the code here.

## s3_delete_permissions: Deletes all ACLs and bucket policies from a bucket ##

import boto3
from botocore.exceptions import ClientError

def run_action (boto_session,rule,entity,params):
    # Create an S3 client
    s3_client = boto_session.client('s3')
    bucket = entity['id']

    ##### Remove Bucket policy #####
        #Call S3 to delete the bucket policy for the given bucket
        result = s3_client.delete_bucket_policy(Bucket=bucket)

    #### Remove Bucket ACLs #####
        # Unset the bucket ACLs
        result = s3_client.put_bucket_acl(Bucket=bucket,ACL='private')
    return text_output

Once the code is executed, the output log is sent via SNS downstream to any medium of choice (email, slack etc)

Step 4: Output and Resolution

Bucket 1 Remediation Output Log  – Bucket ACL Removed

Bucket 2 Remediation Output Log  – Bucket Policy Deleted

A quick scan in the Compliance Engine shows all is well now.


Event driven automation can allow customers to implement automatic remediation of critical workflows as best practice. Dome9’s CloudBots are a set of plug and play bots that can automatically take user-defined remediation actions to fix critical threats.

For more information please visit: and the Dome9 Github repository.