CloudBots: Event-Driven Security Remediation for AWS Compliance Violations

Hook

Most security teams spend 80% of their time fixing the same compliance violations manually. CloudBots turns CloudGuard compliance findings into automated remediation actions in milliseconds.

Context

Cloud security compliance has a persistent gap between detection and remediation. Security teams run assessments with tools like CloudGuard (formerly Dome9), Prowler, or AWS Security Hub, generate reports full of violations, then manually triage and fix each issue. A misconfigured S3 bucket might sit publicly exposed for days while tickets route through approval chains. An overly permissive security group waits in a backlog while attackers scan for entry points.

CloudBots emerged from this reality as CheckPoint's answer to closing the remediation loop. Rather than treating compliance as a reporting exercise, it transforms CloudGuard's continuous compliance engine into an active remediation system. When a compliance rule fails—say, detecting an unencrypted EBS volume or an RDS instance without backup enabled—CloudBots receives the finding via SNS and executes a Python Lambda function to fix it immediately. It's infrastructure-as-code meeting security-as-code, replacing human ticket queues with event-driven automation.

Technical Insight

CloudBots deploys as an AWS CloudFormation stack that provisions a Lambda function subscribed to an SNS topic. The architecture is elegantly simple: CloudGuard runs compliance assessments (continuously or on-demand), detects rule violations, and publishes structured messages to the SNS topic. The Lambda function receives these events, parses the violation details, and dispatches to specific remediation bots based on the rule that failed.

Each bot is a Python module following a consistent interface. The Lambda handler examines the incoming CloudGuard message, extracts the violating resource ARN and rule metadata, then imports and executes the corresponding bot. For example, if CloudGuard detects an S3 bucket with public read access violating your compliance policy, it sends a message like:

{
  "reportTime": "2024-01-15T14:32:11.000Z",
  "rule": {
    "name": "S3 bucket has public read access",
    "severity": "High",
    "complianceTag": "NIST-800-53"
  },
  "entity": {
    "id": "my-company-data-bucket",
    "type": "S3Bucket",
    "region": "us-east-1",
    "accountNumber": "123456789012"
  },
  "remediation": {
    "actions": ["s3_remove_public_access"]
  }
}

The Lambda handler routes this to the s3_remove_public_access bot, which uses boto3 to revoke public ACLs and bucket policies:

import boto3

def run(event, context):
    bucket_name = event['entity']['id']
    region = event['entity']['region']
    
    s3_client = boto3.client('s3', region_name=region)
    
    # Remove public ACL grants
    s3_client.put_bucket_acl(
        Bucket=bucket_name,
        ACL='private'
    )
    
    # Block all public access
    s3_client.put_public_access_block(
        Bucket=bucket_name,
        PublicAccessBlockConfiguration={
            'BlockPublicAcls': True,
            'IgnorePublicAcls': True,
            'BlockPublicPolicy': True,
            'RestrictPublicBuckets': True
        }
    )
    
    return f"Removed public access from bucket {bucket_name}"

The multi-account architecture is where CloudBots shows sophistication. In single-mode deployment, the Lambda assumes it has permissions in the account where it runs. But enterprises typically have dozens or hundreds of AWS accounts. Multi-mode deployment solves this with cross-account IAM roles. You deploy CloudBots in a central security account, then create IAM roles in each workload account with a trust policy allowing the CloudBots Lambda execution role to assume them. The bot code dynamically assumes the appropriate role based on the accountNumber in the event message:

def get_client(service, event):
    account_id = event['entity']['accountNumber']
    region = event['entity']['region']
    
    if account_id != os.environ['ACCOUNT_ID']:
        # Cross-account remediation
        sts = boto3.client('sts')
        role_arn = f"arn:aws:iam::{account_id}:role/CloudBotsRemediationRole"
        
        credentials = sts.assume_role(
            RoleArn=role_arn,
            RoleSessionName='CloudBotsRemediation'
        )['Credentials']
        
        return boto3.client(
            service,
            region_name=region,
            aws_access_key_id=credentials['AccessKeyId'],
            aws_secret_access_key=credentials['SecretAccessKey'],
            aws_session_token=credentials['SessionToken']
        )
    
    return boto3.client(service, region_name=region)

This pattern allows a single CloudBots deployment to remediate violations across your entire AWS organization. The Lambda function becomes a centralized remediation hub, receiving findings from CloudGuard assessments running in all accounts and executing fixes with assumed credentials.

The bot library covers common compliance violations: enabling encryption on EBS volumes and RDS instances, removing unused security groups, enabling VPC flow logs, configuring S3 versioning, rotating access keys older than 90 days, and enforcing MFA on IAM users. Each bot is idempotent—running it multiple times produces the same result—and includes error handling for edge cases like resources already in the desired state or insufficient permissions.

Gotcha

CloudBots has a significant regional limitation: you must deploy the CloudFormation stack in every AWS region where you want remediation. If you run workloads in six regions, you need six separate CloudBots deployments. This isn't just operational overhead—it's six Lambda functions to maintain, six SNS topics to configure in CloudGuard, and six sets of IAM permissions to audit. The architecture doesn't support a single global deployment because Lambda functions and SNS topics are regional resources. While some bots can perform cross-region actions (an IAM bot in us-east-1 can disable access keys globally, for instance), most resource remediation requires the Lambda to exist in the same region as the violating resource.

The tight coupling to CloudGuard's message format also presents friction for standalone use. The SNS messages expect specific JSON structure with fields like entity, rule, and remediation. If you want to use CloudBots without CloudGuard—triggered by custom CloudWatch Events, AWS Config rules, or Security Hub findings—you need to write transformation logic to convert those native AWS events into CloudGuard's expected format. The repository doesn't include adapters for this use case, so you're building custom integration code. Additionally, the README truncation in the repository makes it challenging to assess the complete bot catalog without cloning and exploring the codebase. You'll need to audit which compliance violations have pre-built bots versus which require custom development.

Verdict

Use CloudBots if you're already a CloudGuard customer and need automated remediation without building your own Lambda functions from scratch. The multi-account support and pre-built bot library handle 80% of common AWS compliance violations, and the event-driven architecture integrates cleanly with continuous compliance assessments. It's particularly valuable for enterprises managing 10+ AWS accounts where manual remediation doesn't scale. Skip it if you're not using CloudGuard and don't want to build message format adapters, need a cloud-agnostic solution (CloudBots is AWS-focused despite separate Azure/GCP repos), or prefer native AWS solutions like Config Auto Remediation for simpler use cases. Also skip if you require extensive customization—Cloud Custodian offers more flexibility and a larger community (7k+ stars) for complex policy-as-code needs.