Auto remediation & automation bots for AWS.

This solution is meant to be used in conjunction with Dome9's Continuous Compliance Engine or AWS GuardDuty to remediate issues that are uncovered.

Github Repo Link


What is this?

Cloud-Bots is an automatic remediation solution for AWS built on top of Dome9's Continuous Compliance capabilities

Why and when would I need it?

Dome9 Compliance Engine continuously scans the relevant cloud account (AWS,Azure,GCP) for policy violations, and then alert and report.
For some organizations that is enough. However, at a certain scale and cloud matureness level- organizations prefer to move towards automatic-remediation approach, in which the system takes specific automated remediation bots in regards to specific violations.
This approach could reduce the load from the security operators and drastically reduce the time to resolve security issues.

How does it work?

Single account mode:

Data Flow

Multi account mode:

Data Flow


Where can I see this in action?

Here are two videos on CloudBots:
- Initial Setup
- Remediating an exposed S3 bucket

Where does the function live?

The function can exist in any region you want in your account. Only one is needed per account though.

How many do I need?

In multi-account mode, only one function is required. In single account mode, one function is required per account.

In either mode, there's no need for one function per region or antyhing like that. The max is one function per account.

Every cloud-bot lives in the same function. There aren't multiple functions for the different bots.

Does this use the original Dome9 role?

No. The Dome9-connect role is only for Dome9 to collect data from your AWS accounts. The CloudBots function needs its own execution role to run the remediation actions, but it's completely separate from the Dome9 role.

Where does the AUTO: syntax come from?

AUTO: is used to signal to CloudBots that a remediation action needs to be triggered. The bot name correlates to a file name in the bots/ folder.

Why isn't it in the remediation field of the rule?

By putting the bot syntax in the "Compliance Section" field, multiple actions can be triggered from one rule since the Compliance Section is passed through the event as an array.

How do I add on new "bots"?

Any new bot needs to go into the bots folder in the function. From there, you call it with the AUTO: syntax.
For example, a delete user bot would be named delete_user.py and put in the bots folder.
It would be triggered with "AUTO: delete_user"

What languages are supported?

Currently only python is supported

How are the permissions segregated between Dome9 and CloudBots?

Dome9's cross account role is completely separate from the CloudBots permissions and cross account roles. Dome9 permissions are in yellow, while the CloudBots permissions are in bold. This is done so that the most sensitive permissions stay within the customer environments and are never given to a third party.

Permissions model

Setup Steps

Outside of Dome9

You can deploy this stack in us-east-1 via the link below. If you would like to deploy the stack in another region, please go to the "Deployment Links" tab.


If you want to deploy this via CLI, please see README_ADVANCED.md

Decide on deployment mode

Single vs Multi


In single account mode, the Lambda function will only remediate issues found within the account it's running in. If the event is from another account, it'll be skipped.

This is the default mode. Nothing needs to be changed.


In multi account mode, the function will run in the local account but will also try to assume a role into another account if the event was from a different account than the one the function is running in. Each account that will have remediation bots will need a cross-account role to the master account.

Setup for Multi-account mode in AWS:

In the Dome9CloudBots lambda function: - Update the ACCOUNT_MODE environment variable from 'single' to 'multi' - By default, the cross account roles will all need to be named "Dome9CloudBots". If you want a different name, add a new variable called "CROSS_ACCOUNT_ROLE_NAME" and set the value to the new name for the role.

Set up cross account roles for EACH account that will be remediated

cd cross_account_role_configs

Role creation needs to be done via something other than CloudFormation because CFTs don't output consistent role names

Update trust_policy.json with the account ID where the main function will live

There is a small bash script in this directory that you can run (create_role.sh) to create these roles.

./create_role.sh <aws profile>

Manual Setup:

Create the cross-account role

aws iam create-role \
--role-name Dome9CloudBots \
--assume-role-policy-document file://trust_policy.json \
--profile <aws_account_profile>                                        

Create the IAM policy for the role

aws iam create-policy \
--policy-name Dome9CloudBots \
--policy-document file://remediation_policy.json \
--query 'Policy.Arn' \
--profile <aws_account_profile>                      

Take the ARN from this for the next command

aws iam create-role \
--role-name Dome9CloudBots \
--assume-role-policy-document file://trust_policy.json \
--profile <aws_account_profile>     

Take ARN from create-policy for the next command

aws iam attach-role-policy \
--role-name Dome9CloudBots \
--policy-arn <ARN FROM LAST COMMAND> \
--profile <aws_account_profile>                     

In Dome9

See this section for sample screenshots of the setup

Create a bundle that you want to use for auto remediation.

It's recommended but not required to break remediation bots into their own bundles. There is a sample bundle (sample_bundle.json) that can be used as a starting point. The rule in the sample bundle will remove rules from the default security group if the SG is empty.

For all rules that you want to add remediation to, add the remediation tag to the "Compliance Section" of the rule.

All available remediation bots are in the bots folder.

Tag Syntax: AUTO: <bot_name> <optional space delimeted params>

Ex: AUTO: ec2_stop_instance

Test this compliance bundle.

Make sure you're getting the results you want and expect

Set the Dome9 compliance bundle to run via continuous compliance.

If you're in single account mode, there needs to be a 1 Continuous Compliance bundle per account. If not, select all the accounts that you set up cross-account roles in. Set the output topic as the ARN from the InputTopicARN one we set up Set the format to be JSON - Full Entity

* NOTE: **

Currently Continuous Compliance sends a 'diff' for the SNS notifications. Because of this, if you have ran the bundle before, only new issues will be sent to SNS. If you want to have the first auto-remediation run to include all pre-existing issues, you'll need to use the "send all events" button to force a re-send.

For the compliance policy you have set up, look for a button on the right hand side with an arrow pointing up.
Send all events button

In this page, select SNS as the delivery method and your notification policy as the place to send the events.
This can also be useful for rolling out new bots and/or testing since you can re-send the same event more than once.
Send all events page

From here, you should be good to go!

Setup Screenshots

Updating the stack

Updating your current CloudBots stack is very straightforward. In the UI, navigate to CloudFormation for the region that CloudBots is set up in.

us-east-1 https://s3.amazonaws.com/dome9cftemplatesuseast1/cloudbots_cftemplate.yaml

Release Notes


Updated sg_single_rule_delete to support deleting just a single port from a wider scope of rules (ex: deleting just port 22 from ports 10-30).
2 new permissions are required to support this bot:

Updated vpc_turn_on_flow_logs to support sending logs to S3 instead of CloudWatch logs


Created a new folder called optional_bots. This will not be packaged with the standard Lambda function and will need to be added in manually as required.
Bots that are extremely impactful (s3_delete_bucket, etc.) will live here as well as edge case bots that were made for specific customers (ec2_tag_instance_from_vpc).


Updated sg_single_rule_delete to handle edge case for deleting rule with all ports defined (0-65535).
If you're not using port 0 in sg_single_rule_delete currently, no changes are needed. If you want to use port 0 - please see the updated bot doc.
Added new bot: ami_set_to_private
Documentation is in the bots section
The execution role for Lambda has an updated permission it needs: ec2:ModifyImageAttribute. This has been updated in the template

Added new bot: s3_delete_acls Documentation is in the bots section


Added 4 new bots:
iam_user_attach_policy iam_role_attach_policy Documentation is in the bots section

Questions / Comments

Contact: Alex Corstorphine (alex@dome9.com)