Incident Response Runbooks

It is 9 a.m. and Sam calls: the shop PC shows a ransom note. Adrenaline says unplug everything, pay, delete, panic. A runbook is a short, written plan made on a calm day that tells people what to do, in what order, on a bad one.

The rule

Decide on a calm day what to do on a bad day, then follow it.

A runbook is a step-by-step checklist for one kind of situation. For security incidents, it follows six phases:

1. Preparation — before anything happens: backups, contact list, who is in charge, the runbooks themselves.
2. Identification — is this really an incident? What is affected, and since when? Write down times and what you see.
3. Containment — stop it spreading: disconnect the affected machine from the network, disable a stolen account.
4. Eradication — remove the cause: clean or rebuild the machine, close the hole it came through.
5. Recovery — restore from known-good backups, bring systems back, watch closely for a return.
6. Lessons learned — a blame-free review: what happened, what worked, what to change. Update the runbook.

A good runbook also lists who to tell: the owner, the IT or security provider, the bank, the insurer, and, where personal data may be exposed, whatever reporting the law requires. It is short enough to read in a crisis, and printed, because the computers may be the thing that is broken.

The shortcut

Under pressure, remember the order in three words: contain, then clean, then restore. And write down what you see as you go.

The trap is jumping straight to recovery: restoring files before containing and removing the cause, so the attacker simply encrypts them again.

Drills

Answer fast — trust the rule.

Remember

• Decide on a calm day what to do on a bad day, then follow the runbook.
• Preparation, identification, containment, eradication, recovery, lessons learned. Under pressure: contain, clean, restore.
• Trap: restoring before cleaning, and blaming people instead of fixing the plan.