← All cheat sheets

INCIDENT RESPONSE

Plain-text reference · 5 KB. Read it, search it (Ctrl-F) or print it.

FRAMEWORK#

NIST SP 800-61r2 lifecycle (the one most IR plans follow):
  1. Preparation
  2. Detection & Analysis
  3. Containment, Eradication & Recovery
  4. Post-Incident Activity (lessons learned)
SANS uses six steps (PICERL): Preparation, Identification, Containment,
Eradication, Recovery, Lessons Learned. Same idea, different labels.

Golden rule: DECIDE ROLES AND THRESHOLDS BEFORE THE INCIDENT. In the moment
you follow the plan; you do not write it.

1. PREPARATION (before anything happens)#

- IR plan approved, printed, and reachable if email/SSO is down.
- Contact tree: IR lead, legal, comms/PR, execs, DPO, key sysadmins,
  external DFIR retainer, cyber-insurer, law-enforcement contact.
- Out-of-band comms (a separate chat/phone bridge) in case the main
  environment is compromised.
- Logging in place and centralised (SIEM), with enough retention (>= 90 days,
  more for regulated data). You cannot investigate logs you never kept.
- Known-good baselines, asset inventory, network diagram, data-flow map.
- Ready-to-run tooling: forensic image kit, memory capture, EDR isolate,
  triage collectors (KAPE, Velociraptor, osquery), clean USBs.
- Severity matrix agreed (see below). Tabletop exercise done recently.

2. DETECTION & ANALYSIS#

Goal: confirm it is real, scope it, and classify severity.
- Validate the alert (rule out false positive) and record the FIRST evidence
  and time (UTC).
- Determine: what systems, what accounts, what data, entry vector, timeline.
- Build a timeline as you go (append-only). Note every action with who/when.
- Preserve volatile evidence FIRST, order of volatility:
    memory (RAM) -> network state/connections -> running processes ->
    disk -> logs/archives -> physical config.
- Do NOT power off a host you may need memory from; isolate instead.
- Assign severity (example scale):
    SEV-1 Critical: active data theft, ransomware spreading, safety impact.
    SEV-2 High:     confirmed compromise, contained blast radius.
    SEV-3 Medium:   single host/account, no sensitive data confirmed.
    SEV-4 Low:      policy violation, near-miss, suspicious but unconfirmed.

3. CONTAINMENT#

Short-term (stop the bleeding, keep evidence):
- Isolate host at the network (EDR "isolate", switch port, host firewall) —
  prefer isolation over shutdown so RAM/artifacts survive.
- Disable or reset compromised accounts; revoke sessions and tokens/API keys.
- Block known-bad IPs/domains/hashes at firewall, proxy, DNS, EDR.
- Snapshot/image affected systems before you change them.
Long-term:
- Patch the exploited vulnerability, rotate ALL potentially exposed secrets,
  rebuild rather than clean where trust is uncertain.

4. ERADICATION & RECOVERY#

Eradicate:
- Remove malware, backdoors, persistence (services, scheduled tasks, cron,
  run keys, new accounts, SSH keys, OAuth grants).
- Confirm the initial access vector is closed. Reset credentials domain-wide
  if identity infrastructure was touched.
Recover:
- Restore from known-good backups; verify integrity before reconnecting.
- Rebuild from trusted media where compromise depth is unknown.
- Increase monitoring on restored systems; watch for re-infection.
- Return to production in stages, with sign-off against exit criteria.

5. POST-INCIDENT (lessons learned)#

- Hold the review within ~2 weeks while memory is fresh; blameless.
- Answer: what happened, timeline, what worked, what did not, root cause,
  dwell time, MTTD/MTTR, cost/impact.
- Produce actions with owners and dates; feed them back into Preparation.
- Update detections (write a Sigma rule / SIEM alert for this attack),
  playbooks, and the asset/log gaps you found.

EVIDENCE & CHAIN OF CUSTODY#

- Record for every artifact: what, where from, who collected, when (UTC),
  hash (sha256), and every transfer/handoff.
- Work on copies; keep an untouched master image. Hash before and after.
- Timestamps in UTC everywhere; note the source clock's accuracy.
- Assume evidence may end up in court or with a regulator.
- GDPR: notify the supervisory authority within 72 hours of becoming aware
  of a personal-data breach (Art. 33); notify data subjects if high risk.
- NIS2: early warning within 24 hours, incident notification within 72 hours,
  final report within one month (essential/important entities).
- DORA (EU financial entities): classify and report major ICT incidents on
  the regulator's timeline; keep the register of incidents.
- Sector/national rules and contracts may impose shorter clocks — check the
  matrix in your plan, and involve legal/DPO early.
This is operational guidance, not legal advice; confirm obligations with
counsel and the exact regulation text.

DO / DON'T IN THE FIRST HOUR#

DO   start the timeline, assign an IR lead, capture volatile evidence,
     isolate (not wipe), use out-of-band comms, loop in legal early.
DON'T tip off the attacker with clumsy blocks before you understand scope,
     don't reboot/reimage a host you still need to analyse, don't pay or
     negotiate ransom without legal/exec/insurer sign-off, don't communicate
     externally before comms/legal approve the message.

Defensive reference on CyberRamen. Offensive / red-team sheets live on OffensiveRamen.com.