Practice — run a tabletop incident response simulation

This exercise brings Module 5 together as a tabletop simulation: a discussion-based walkthrough of a realistic incident, run without touching any real system, that exercises the full NIST lifecycle, forensic thinking, and lessons-learned process in a low-stakes setting. Tabletop exercises are themselves a best practice, letting a team rehearse decision-making and expose gaps in playbooks and communication before a real incident forces those same decisions under genuine pressure.

Analogy🏏Cricket

✈️ Think of it like travel: a tabletop exercise is the dry run you walk through the day before a big international trip — tracing the whole journey aloud at the kitchen table without actually leaving the house. You rehearse each connection, check the visa is ready, and discover the layover is impossibly tight while it still costs nothing to fix. Exercising the full incident lifecycle this way exposes gaps in playbooks and communication in a low-stakes setting, long before a real emergency forces those same decisions at the airport under genuine pressure. This reveals why rehearsing decisions in discussion beats improvising them live.

Step 1 — Set the scenario. A SIEM alert, based on the Sigma rule from Module 4's exercise, fires for a successful login following repeated failures from an external IP against a cloud-hosted admin account. Fifteen minutes later, cloud API logs show that account launching several unfamiliar EC2 instances in a region the organisation does not normally use. Present this scenario to the team and pause at each decision point below rather than resolving it all at once.

Analogy🏏Cricket

🎬 Think of it like movies: setting the scenario is a director revealing a thriller's plot one scene at a time rather than dumping the ending in the opening shot. First the audience sees the suspicious late-night login after a string of failures; fifteen minutes of screen time later, the same account is quietly commissioning strange machines in a foreign city nobody expected. The tension works precisely because the reveal is paced, pausing at each beat so the room must decide what it would do next. This reveals why presenting the incident incrementally, stopping at every decision point, makes the rehearsal genuinely exercise judgement.

text

# Tabletop scenario timeline (present incrementally, pause for discussion)
T+0m   SIEM alert: brute-force-then-success on admin account (Sigma, M4 L24)
T+15m  Cloud API logs: same account launches instances in unused region
T+20m  (reveal only if asked) new instances are mining cryptocurrency
T+40m  (reveal only if asked) original admin credentials still active

Step 2 — Walk detection and analysis, then containment. Ask the group: how would you confirm this is a real incident and not a false positive, drawing on Lesson 27's hunting instincts? What is the blast radius — just this account, or has it been used to pivot elsewhere? Then move to containment per Lesson 28: would you isolate the new instances, disable the compromised account, or both, and in what order, given that disabling the account first might stop the attacker before they can react to being noticed?

Analogy🏏Cricket

♟️ Think of it like chess: walking detection then containment is a player pausing to read the whole board before touching a single piece — is this genuinely an attack or a harmless-looking bluff, and how far does the threat already reach across the position? Only after scoping it does the player choose the move and, critically, its order: disabling the compromised account first is like removing the attacker's active piece before it can respond to your threat, denying it the tempo to react. This reveals why confirming and scoping precede containment, and why the sequence of containment moves is itself a deliberate decision.

Step 3 — Walk eradication, recovery, and forensics. Ask what evidence should be preserved before any cleanup, applying Lesson 26's order of volatility to the new instances before they are terminated. Discuss eradication: rotating every credential the compromised account could have touched, not just the one directly used. Then discuss recovery: how would the team confirm, through monitoring, that no other unauthorised instances or persistence mechanisms remain before declaring the incident closed?

Analogy🏏Cricket

🏏 Think of it like cricket: before the groundstaff roll and re-cover a damaged pitch, the umpires photograph and mark the exact area of disturbance — capturing the fragile evidence before any cleanup, just as memory is imaged from the rogue instances before they are terminated. Eradication is then thorough, not partial: you do not merely replace the one worn patch but re-check the whole strip the same bowler could have scuffed. Recovery means watching the next several overs closely to confirm no hidden damage resurfaces before play is declared safe. This reveals why evidence, complete eradication, and monitored recovery must all come in order.

Step 4 — Run the post-incident review. Apply Lesson 29's blameless format to this simulated incident: what went well, such as the Sigma rule firing as designed; what could improve, such as whether the SOAR playbook's approval step introduced unnecessary delay; and what concrete, owned action items would come out of it, such as adding a rule that specifically flags new-region instance launches from admin accounts, closing the exact gap this scenario was built to expose.

Analogy🏏Cricket

💪 Think of it like fitness: the post-incident review is the honest cool-down debrief after a tough training session. You note what worked — the warm-up routine fired exactly as planned — and what dragged, like a mobility drill that added needless delay before the real work began. Then you commit to specific, owned changes to next week's programme: add a movement that targets the exact weakness this session exposed, assigned and scheduled rather than vaguely intended. This reveals why a blameless review producing concrete, owned action items is what turns one hard session into lasting, measurable progress.

Tabletop exercises rehearse incident decisions in a discussion-based, low-stakes setting.
Present the scenario incrementally, pausing at each decision point for group discussion.
Walk the full NIST lifecycle: detection/analysis, containment, eradication, recovery.
Apply order-of-volatility thinking before any simulated cleanup or termination step.
Close with a blameless post-incident review producing concrete, owned action items.