Incident Response & Digital Forensics

Every other pillar is an argument about reducing the probability of an incident. This one starts from the assumption that the argument lost. Prevention fails, detection fires late or not at all, and someone has to answer a question that admits no hedging: what happened, how far did it go, and is it over.

That last part is where most response goes wrong. Scoping a compromise is a claim about the boundary of an intrusion, and it is far easier to assume a boundary than to prove one. Reconstruction — timelines, forensic artefacts, malware capability — is what turns the assumption into evidence.

Why it matters

Incidents are where every control assertion gets audited by reality at once. They are also where the cost of earlier shortcuts becomes legible: the log source nobody instrumented, the flat network, the shared credential, the backup nobody restore-tested.

The second reason is institutional. An incident is the one moment an organization will fund the fix. A response that reconstructs root cause produces durable change; one that restores service and moves on guarantees a rerun.

How this connects

• → Detection Engineering: the closest sibling — §7 builds and tests the rules, this pillar responds and investigates. Every incident produces detection gaps, which is the highest-quality input the detection backlog gets.
• → Threat Intelligence: investigation output is intelligence, and confidence language matters most under time pressure. Malware analysis feeds indicators and behaviours back upstream.
• → IAM: identity-centric containment is usually the fastest lever available — revoke, rotate, and cut the session before chasing hosts.
• → Cloud & Infrastructure Security: cloud IR is a different discipline. Snapshotting, credential revocation and blast-radius scoping all depend on how the substrate was architected.
• → Data Security & Privacy Engineering: what was accessed determines notification obligations, and forensics routinely recovers data an organization believed was deleted.
• → GRC: breach notification clocks are regulatory, and evidence handling has to survive counsel.
• → Penetration Testing & Red Teaming: a red team engagement is a rehearsal for this pillar, and the honest measure of both is what the responders actually caught.
• → Application Security: root cause frequently lands in code, and the postmortem is where that becomes a requirement instead of a ticket.
• → AI & Automation: triage and enrichment are the obvious automation targets, with human approval gates on anything destructive.

What’s here

Subsection	Focus
Incident Response Operations	NIST SP 800-61 lifecycle and playbooks, triage and severity declaration, incident command, identity-centric containment, cloud IR, incident communications, blameless postmortems
Digital Forensics	Order of volatility and sound acquisition, disk forensics and execution artefacts, memory forensics, cloud and SaaS forensics without a disk, endpoint and browser artefacts, anti-forensics
Timeline & Investigation Method	Super-timelines and cross-artefact pivoting, root cause vs. proximate cause, proving scope rather than assuming it, confidence language under pressure, reproducible documentation
Malware Analysis & Reverse Engineering	Static triage and similarity, dynamic analysis and detonation safety, unpacking and RE workflow, extracting IOCs and behavioural signatures, capability assessment
Evidence Handling & Legal	Chain of custody and defensible process, legal hold and privilege, regulatory notification clocks, working with counsel, law enforcement and external IR

The thread worth following

Alert to answer. Detection fires, §9.1 contains, §9.3 reconstructs, §9.4 establishes what the malware could actually do — and the lesson goes back into the detection backlog as a tested rule. The full circuit, in the opposite direction to the purple team loop.