An incident response plan you have not rehearsed is a plan you do not have. This lesson walks through the structure of a workable cloud incident response playbook.
The four phases
- Detect. Triggered by a monitor, a researcher, an employee, or a customer. The first action is to confirm it is real.
- Contain. Stop the bleeding. Revoke credentials, isolate resources, block paths, switch traffic.
- Eradicate. Remove the attacker's footholds. This step is harder than it sounds and is the most often skipped.
- Recover and learn. Bring services back, write the postmortem, update the playbook for the next time.
What to put in the playbook
- A roster of who handles each phase, including their backups
- The exact commands or console paths to revoke, isolate, and restore key resources
- Communication templates for customers, regulators, and the board
- A list of vendors to call and the contracts that govern when to call them
- A practice schedule — at least one tabletop per quarter, one full simulation per year
Cloud-specific quirks
- Containment in the cloud is often as simple as flipping a tag on a resource — but only if your tooling supports it
- Eradication can be tricky because attacker-created resources can hide in regions you do not normally use
- Recovery is faster than on-prem, but only if your infrastructure-as-code is up to date
Anti-patterns
- A playbook that only exists in one engineer's head
- A playbook tested only with friendly tabletops, never with surprise drills
- A playbook that assumes the cloud account itself is uncompromised when the breach may have started there
- A playbook with no defined "war room" channel that everyone knows by heart
Takeaway
Write it down, rehearse it, update it after every real incident and every drill. The plan does not need to be perfect; it needs to be present.
HS Academy
All HS Academy lessons are free to read. Create a free HorizonShield account to explore the platform itself.
Sign up free →