What Makes a Good Injection?
An injection is the scripted scenario event that drives the exercise. A good injection is realistic enough to create genuine cognitive pressure but controlled enough to not cause actual harm. Designing injections is a craft — too easy and the team learns nothing; too complex and the exercise collapses into confusion.
Principles for effective injections:
- Specificity: "The payment service returns HTTP 503" is better than "something is broken." Specific failures force specific diagnostic steps.
- Plausibility: The scenario should be something that could actually happen to your organization. A startup with no government contracts doesn't need a nation-state APT scenario.
- Escalation: Start simple, then add complications. The first inject is manageable; subsequent injects reveal how the team handles compounding pressure.
- Targeted gaps: Design the injection to stress-test a specific process you suspect is weak. If you think your runbook for database failover is outdated, design an injection that requires exactly that runbook.
The Role of the Master of Disaster
The Master of Disaster (MoD) is the facilitator and referee of the exercise. They are the Dungeon Master of the drill — they know the full scenario, they control the pacing, and they introduce complications. Their most important rule: they do not help.
When a junior engineer is visibly confused and asks "what should I do?", the MoD's job is to say "I don't know, what does the runbook say?" and write down that the engineer didn't know where to find the runbook. The struggle is the data.
The MoD tracks:
- Time to first correct action
- Number of wrong turns taken
- Access or permission failures encountered
- Runbook steps that were unclear or missing
- Communication breakdowns between team members
Validating the Runbook
Every GameDay or TTX should test a specific runbook — a documented procedure for responding to a known failure type. The hypothesis-driven approach works well here:
- Hypothesis: "Our Ransomware Runbook says we should immediately disconnect the affected network segment."
- Test: During the TTX, ask the Network Admin: "Do you know how to disconnect the office network segment right now? Do you have the credentials? Do you have physical access to the switch?"
- Finding: "Uh, no. Bob has the key to the network closet, and Bob is traveling." → Process Failure: Single point of access for critical infrastructure.
This is the difference between a runbook that says something will happen and a runbook that has been proven to work.