CloudTrail Security Monitor

The problem

CloudTrail can produce a large amount of API telemetry. Reviewing raw records manually does not scale well, and a useful security signal needs more context than an API name alone.

The monitor filters and validates input, evaluates each record against registered detector functions, and emits a common finding structure so additional rules can be added without changing the parser workflow.

Architecture

cloudtrail_parser.py ↓ load + validate JSON ↓ optional CLI event filter ↓ filtered records ↓ detect_security_events() ↓ registered detector functions ├── delete_vpc() ├── terminate_instances() └── future detectors ↓ standardized findings ↓ print_findings()

Current coverage

DeleteVpc

Detects VPC deletion activity, extracts the affected VPC ID, and produces a standardized finding.

TerminateInstances

Detects EC2 termination activity and supports one or multiple affected instance IDs from a single API call.

These rules identify security-relevant actions; they do not claim the action is malicious. Authorization and intent still require context and investigation.

Example finding

Finding 1
Event Name: DeleteVpc
Event Time: 2026-09-23T16:29:41Z
Event Source: ec2.amazonaws.com
Source IP Address: 203.0.113.10
User Identity: arn:aws:sts::111122223333:assumed-role/TerraformExecutionRole/terraform
User Type: AssumedRole
AWS Region: us-west-2
Affected Resources: ["vpc-0123456789abcdef0"]
Result: Success
Rule Name: DeleteVpc

Representative sanitized output. Real CloudTrail logs are excluded from source control.

Validation methodology

The detector was tested with known ground truth from the Terraform Security Lab. I performed controlled terraform apply and terraform destroy operations through a known execution role, recorded the approximate time and expected resources, then compared the resulting CloudTrail records and parser findings to those known actions.

Validation also included benign, successful, failed, multi-resource, missing-field, and malformed-data scenarios.

Security considerations

The repository excludes real CloudTrail telemetry because logs can contain account IDs, ARNs, source IPs, access-key identifiers, session data, and other operational information. Only sanitized samples are committed, and environment files, generated cache data, credentials, session tokens, and real tfvars are excluded.

Next engineering steps

Planned extensions include additional detectors, correlation across surrounding CloudTrail activity, severity based on action and context, native .json.gz handling, and direct S3 ingestion.