Chapter 2

Preparation

IR runbook development, tabletop exercises, asset inventory as an IR dependency, contact trees, and pre-positioning forensic tools — the infrastructure that determines whether your first hour of an incident is controlled or chaotic.

Scenario

It's 1 AM and ransomware is spreading. The on-call analyst escalates but can't reach the IR lead — no phone number in the runbook, only an email. The CISO needs a status update but nobody has written a SITREP template. The forensic collection tool isn't deployed on endpoints because the request to push it via SCCM was never approved. Nobody knows who the cyber insurer's emergency hotline is. The external IR firm's contract was signed last year but the authorization language to deploy their agents was never finalized. By the time everyone is assembled, 2 hours have passed. Preparation failures don't look like security failures — they look like operational failures. But the cost is measured in how much the attacker can do while you're getting organized.

IR Runbooks

A runbook is a documented, step-by-step procedure for handling a specific type of incident. It is not a framework summary — it is the specific thing your analyst does at 2 AM when they're half-asleep and the attacker is wide awake.

Runbook componentWhat to includeCommon omission
Trigger criteriaExactly what conditions cause this runbook to activate (specific alert name, severity, data type involved)Vague ("suspicious activity detected") — analyst can't decide if it applies
Initial triage stepsThe first 5 commands to run, the first 3 questions to answer, in orderMissing — analyst has to invent the process under pressure
Severity classificationDecision tree: if X then P1, if Y then P2, etc.No objective criteria — every analyst classifies differently
Escalation contactsName, phone, backup phone, for every role up the chain — not emailEmail-only — unusable at 2 AM when phone is the only option
Evidence collection stepsWhat to collect and in what order before any containment actionMissing — containment happens before evidence is preserved
Containment actionsExact commands / console clicks to isolate a host, block a domain, disable an accountDescribed in prose, not commands — analyst looks up syntax under pressure
External contactsCyber insurer hotline, external IR firm emergency line, CISA, legal counselMissing — people spend 30 minutes finding a phone number
Why runbooks must be tested, not just written

An untested runbook has unknown failures. The escalation phone number is disconnected. The containment command doesn't work in the current EDR version. The SIEM query returns no results because the log source was changed three months ago. Run through every runbook at least quarterly in a non-production test, and update it after every incident that reveals a gap. A runbook last tested two years ago is a false sense of security.

Asset Inventory as an IR Prerequisite

You cannot scope what you cannot enumerate. Asset inventory is not a compliance requirement — it is the foundation that makes every other IR capability possible.

  What Asset Inventory Enables During IR
  ═══════════════════════════════════════════════════════════════════

  Without inventory:                 With inventory:
  ─────────────────────────────────  ─────────────────────────────
  "How many machines does the        "47 hosts in the finance VLAN,
  finance VLAN have?" Unknown        all enrolled in Intune, all have
                                     the EDR agent, backup last ran
                                     48 hours ago."

  "Is this a critical server?"       "IP 10.1.2.30 = payroll-db-01,
  Unknown                            owner: Finance, criticality: P1,
                                     PII/PCI data: yes, contact: Bob"

  "Who uses this host?"              "Hostname = LAPTOP-ALICE,
  Unknown                            primary user: alice@corp.com,
                                     asset tag: A-1045, last seen in
                                     Chicago office"

  Inventory fields that matter for IR:
    ├── Hostname, IP, MAC
    ├── OS version and patch level
    ├── Owner and primary user
    ├── Criticality tier (P1/P2/P3)
    ├── Data classification (PII/PCI/PHI/IP)
    ├── EDR agent present? Backup configured?
    ├── Network segment / VLAN
    └── Last seen / last checkin
Mental model: inventory accuracy decays over time

An asset inventory taken today is 95% accurate. In six months, without automated updates, it may be 70% accurate — VMs spun up, old machines not decommissioned, cloud instances nobody owns. For IR purposes, "mostly accurate" is meaningful: even a 70%-accurate inventory is exponentially better than no inventory. But treat every inventory as a starting point to verify, not a ground truth. During scoping, cross-reference inventory data against live EDR enrollment, DHCP logs, and network scanning results to catch the gaps.

Tabletop Exercises

A tabletop exercise is a discussion-based simulation of an incident. Unlike a live-fire exercise, no actual systems are touched — the value is in surfacing gaps in process, decision authority, and communication before a real incident does it for you.

Exercise typeFormatWhat it testsRecommended cadence
Scenario discussion30-60 min, small team, single scenarioDoes the team know the runbook? Do they know who to call? Are there obvious gaps?Monthly
Full tabletop2-4 hours, cross-functional (IR + legal + comms + leadership), with timed injectsDecision-making under pressure, inter-team coordination, escalation decisionsQuarterly
Red team / purple teamActive — red team simulates attacker TTPs, blue team detects and respondsReal detection coverage, real IR response time, real tool gapsAnnually or after major changes

A well-run tabletop injects surprises that test specific decision points. Examples of high-value injects:

  Tabletop Inject Examples
  ═══════════════════════════════════════════════════════════════════

  T+00:00  Alert fires: ransomware on 3 workstations in finance VLAN
           Question: do you isolate now or scope first?

  T+00:20  Your forensic collection tool isn't deployed on 40% of hosts
           Question: how do you collect evidence from those machines?

  T+00:45  The CEO's laptop is in the blast radius. Their EA calls,
           says the CEO needs their machine back in 1 hour.
           Question: who makes this decision? What do you say?

  T+01:00  [Inject] The attacker just encrypted 200 more hosts.
           Containment failed. The initial 3 hosts you isolated
           were not patient zero.
           Question: how do you adjust the strategy?

  T+01:30  Legal says you may have PII exposure. The GDPR 72-hour
           clock may be running. Who decides? When?
           Question: what's the notification decision process?

  T+02:00  The external IR firm says they can be on-site in 6 hours
           but their deployment authorization isn't signed.
           Question: can you get authorization in 20 minutes?
Common mistake: tabletops without senior stakeholder participation

Tabletops where only the IR and SOC team participate miss the hardest part of incident management: the decision points that require legal, PR, HR, and executive involvement. The most consequential IR decisions — whether to notify regulators, whether to pay a ransom, whether to disconnect a revenue-generating system — cannot be pre-delegated to technical staff. Senior stakeholders need to participate in tabletops so they understand the time pressures involved. An executive who has never been through a tabletop will be shocked at how fast notification deadlines arrive during a real incident.

Contact Trees

Every contact needed during an incident must be pre-documented with phone numbers, not email. Phone is the only reliable channel when email infrastructure may be compromised or unavailable.

CategoryContacts to document
Internal — TechnicalIR Lead (primary + backup), SOC manager, IT operations on-call, network team on-call, identity team (AD/Azure AD admin), backup/recovery team
Internal — BusinessCISO, CIO, General Counsel, Chief Privacy Officer, Head of Communications/PR, CEO (for P1 incidents), CFO (if financial impact or ransom decision)
Internal — HR/LegalLegal counsel (privacy specialist), HR (for insider threat), Data Protection Officer (GDPR)
External — IRExternal IR retainer firm emergency line, forensic firm contact, malware analysis contact
External — InsuranceCyber insurer 24/7 claim hotline, policy number, coverage limits
External — GovernmentCISA (888-282-0870), FBI Cyber Division local field office, sector-specific ISAC
External — LegalOutside breach counsel, state AG offices if consumer notification required

Pre-Positioning Forensic Tools

Tools that are not deployed before the incident cannot be deployed quickly during it — pushing a new agent via SCCM or Intune takes time, requires change approval, and may fail on compromised endpoints where the agent infrastructure is disrupted. The goal is that every endpoint in scope already has forensic collection capability deployed and working before the incident starts.

ToolWhat it enablesDeployment method
EDR agent (CrowdStrike/SentinelOne/MDE)Live telemetry, remote shell, process isolation, file collectionSCCM/Intune/GPO — should be 100% of managed endpoints before any incident
Velociraptor agentFleet-wide artifact collection, hunting queries, remediation actionsSCCM/Intune or EDR-deployed; pre-authorization to deploy collectors signed
KAPE triage packageFast forensic artifact collection without full disk imageStored on a network share or USB — pre-authorized, analyst can deploy on any host via admin share
Memory acquisition tool (WinPmem/AVML)Memory capture before reboot — volatile evidence preservationOn analyst jump drive or accessible network share — no installation needed
Log forwarding agentSends events to SIEM before they're overwritten — the only safe backup for event logsWindows Event Forwarding or Winlogbeat/NXLog via GPO

Q & A

Q: How detailed does an IR runbook need to be? Can it be too detailed?

The right level of detail is: specific enough that an analyst who has never handled this type of incident can execute the critical steps correctly under pressure, without needing to think about the process. This means exact commands, not prose descriptions. "Isolate the host in CrowdStrike" is not enough — "In CrowdStrike Falcon console, navigate to Investigate → Hosts → search hostname → click three-dot menu → Network Containment → Contain → Confirm" is right. Too detailed means it's 50 pages and nobody reads it. The right length is: triage checklist on one page (for the first 15 minutes), then detailed procedures per action type.

Q: The asset inventory isn't complete. Is it worth starting IR preparation without it?

Yes — partial preparation is better than no preparation. Start with the highest-criticality systems: crown jewels, data repositories, identity infrastructure. An inventory of 200 P1 systems that's 95% accurate is enormously more valuable during an incident than a promise to complete the full 5,000-system inventory first. Run the two tracks in parallel: deploy EDR and forensic tools to known critical systems now; build the broader inventory as a parallel initiative. In practice, organizations that wait for complete inventory before starting IR preparation often never start.

Q: Legal says all tabletop scenarios must be approved by counsel before running. This creates delays. How do you handle this?

Work with legal once to agree on a standing set of approved scenario categories rather than approving each scenario individually. Categories that are almost always approved: ransomware, credential compromise, BEC, cloud account compromise, data exfiltration. The scenarios themselves don't need to reveal security weaknesses — they're hypotheticals about external attack, not disclosures of internal vulnerabilities. If legal is concerned about attorney-client privilege, frame tabletops as "legal hold exercises" with counsel facilitating — this brings tabletop results under privilege protection while satisfying the approval requirement.