Detection as code & response

EventBridge to SIEM/SOAR and auto-containment.

Detection is only as good as what happens after a finding fires. A mature AWS setup treats detections as code and wires findings into an automated pipeline that correlates, prioritizes, and responds in seconds — the difference between spotting an incident and containing one.

Route findings, do not watch consoles

EventBridge is the backbone: GuardDuty, Security Hub, Config, and CloudTrail all emit events you match with rules and fan out to targets — a SIEM for correlation, a Lambda or Step Functions for automated remediation, and ticketing for the human trail. A high-severity GuardDuty finding can trigger containment (isolate the instance, revoke the session) before an analyst has even opened the console.

# EventBridge rule: only high-severity GuardDuty findings.
aws events put-rule --name gd-highsev \
  --event-pattern '{"source":["aws.guardduty"],"detail":{"severity":[{"numeric":[">=",7]}]}}'
 
# Target a Step Functions state machine that, in order:
#   1) tags + quarantines the affected instance (restrictive SG)
#   2) snapshots its volume for forensics
#   3) opens a ticket and pages on-call
aws events put-targets --rule gd-highsev \
  --targets 'Id=ir,Arn=arn:aws:states:eu-west-1:333333333333:stateMachine:ir-runbook'

Detection as code

Codify your custom detections — CloudWatch metric filters and alarms on sensitive API calls (kms:DisableKey, cloudtrail:StopLogging, mass GetObject), EventBridge patterns, and remediation logic — in version control, tested and reviewed like any software. That makes rules auditable, repeatable across accounts, and hard to silently weaken. Metric-based alerts on abnormal use of permitted actions catch what per-permission checks never will: a legitimate action at an illegitimate volume or pattern.