implementing-security-chaos-engineering

Use security chaos engineering: deliberately break a control, such as opening a security group to 0.0.0.0/0 with boto3, then verify that GuardDuty or AWS Config alerts fire within your SLA. Always wrap the experiment in setup, verify, and rollback functions.

Security chaos engineering intentionally degrades security controls—disabling CloudTrail, creating IAM admin users, opening firewall rules—to confirm detection and response systems work. Experiments run in tagged, isolated accounts with abort conditions and guaranteed rollback.

Wrap every experiment in a try/finally block that guarantees the rollback function executes, enforce a tight timeout, and assert post-conditions like rule removal or restored CloudTrail logging. Run only in a scoped, isolated account with a tested abort path.

A quiet console can mean detection works or that the log pipeline you disrupted feeds the detection source. Check the detection source directly, such as GuardDuty findings or SIEM ingestion lag, to distinguish a silent control failure from a genuine detection gap.

Experiments belong in a tagged, isolated account or network segment with defined abort conditions, not production. Confirm the abort path works before any real run, and obtain appropriate authorization for all testing activities.