Chapter 51 — Incident response

The lifecycle (NIST SP 800-61)

   1. PREPARATION      before anything happens
      - IR plan + playbooks (ransomware, cred compromise, data exfil,
        web-app breach, insider, supply-chain, DDoS)
      - roles: Incident Commander, Comms lead, Scribe, technical leads,
        Legal, Exec sponsor. A RACI. On-call rotation.
      - contact tree (incl. out-of-band: what if Slack/email is
        compromised?), retainer with an IR/forensics firm, cyber-insurance
        contacts, law-enforcement contacts
      - tooling ready: EDR, centralised logs (Ch 50), ability to isolate a
        host/rotate all creds/pull an image, a clean-room comms channel
      - RUNBOOKS TESTED via tabletop exercises + at least one live drill/yr

   2. DETECTION & ANALYSIS
      - triage: is it real? scope? severity? (define severities in advance)
      - declare an incident; assign an IC; start the timeline doc
        (every action, UTC, who) -- this is evidence and post-mortem input
      - preserve evidence BEFORE you change things (see forensics below)

   3. CONTAINMENT
      - SHORT-TERM: stop the bleeding -- isolate hosts (network quarantine,
        not power-off if you want memory), disable compromised accounts,
        revoke tokens/keys, block C2 IPs/domains, take the app to
        maintenance mode if needed
      - decide: monitor-and-learn vs contain-now (tips toward contain-now
        if data is actively leaving)
      - LONG-TERM: temporary fixes that let you operate while eradicating
        (patched hosts rebuilt from known-good, tighter rules)

   4. ERADICATION
      - remove the foothold: rebuild (don't "clean") compromised systems
        from trusted images, patch the entry vector, reset ALL potentially
        exposed credentials, remove persistence (cron, services, keys,
        webshells, IAM backdoors, OAuth grants)
      - confirm the initial access vector is actually closed

   5. RECOVERY
      - restore from known-good backups (verify integrity, scan first),
        return systems to prod in a monitored, staged way
      - heightened monitoring for recurrence (attackers retry)
      - define exit criteria: when is the incident "closed"?

   6. POST-INCIDENT ("lessons learned")
      - BLAMELESS post-mortem within ~2 weeks: timeline, root cause (5
        whys / causal analysis), what worked, what didn't, dwell time,
        MTTD/MTTC
      - concrete action items with owners and dates; track to done
      - update playbooks, detections, and controls

Containment decisions under pressure

   Pull network, keep power    -> preserves RAM (malware, keys, live
                                  processes) for forensics. Preferred if
                                  you have the capability.
   Power off                   -> stops encryption/exfil fast, but destroys
                                  volatile evidence. Sometimes the right
                                  call (active ransomware encryption).
   Leave running, watch        -> only if exfil is NOT ongoing and you have
                                  the monitoring to learn scope safely.
   Rotate credentials WIDELY   -> almost always, early. Assume the blast
                                  radius is bigger than it looks.

Forensic basics (do no harm to the evidence)

   ORDER OF VOLATILITY (collect most-volatile first):
     CPU registers/cache -> RAM -> network state (connections, ARP, routes)
     -> running processes -> disk -> logs/archives -> physical config

   PRINCIPLES:
     - work on COPIES; hash originals (SHA-256) and record the hash
     - maintain CHAIN OF CUSTODY (who touched what, when, why)
     - capture memory before shutdown (avml, LiME, WinPMEM)
     - image disks with a write-blocker; `dd`/` dc3dd` + hash
     - note system time vs true time (clock skew)
     - if it may go legal, involve Legal EARLY and follow their guidance
   You don't need to be a forensic examiner -- you need to not TRAMPLE the
   scene before one arrives.

Comms and obligations

   INTERNAL: single source of truth (the timeline doc + a status channel),
     regular exec updates, need-to-know for details.
   EXTERNAL: legal/regulatory timelines are real and short:
     - GDPR: notify the supervisory authority within 72 HOURS of becoming
       aware of a personal-data breach (and affected individuals if high
       risk).
     - US: state breach laws, SEC 4-day material-incident disclosure for
       public companies, sector rules (HIPAA, PCI, GLBA), CIRCIA.
     - contractual: customer notification SLAs.
   Prepare holding statements in advance. Do NOT speculate publicly on
   cause/scope before you know. Coordinate with Legal + PR.

   Run a 45-minute tabletop with 2-4 people (or solo, writing it out).

   SCENARIO: "At 02:14 an alert fires: SecureShop's orders-api tier made
   200 outbound HTTPS connections to an IP in a country you don't operate
   in. A dev notices the admin panel has a new user 'svc_backup' created
   at 01:50. crt.sh shows a cert issued for admin.securesh.op by a CA you
   don't use, 3 days ago."

   Work through, writing decisions + timestamps:
   1. Is this an incident? Severity? Who is IC? What's the first action in
      the next 5 minutes?
   2. Contain: what do you isolate/disable/revoke, in what order? What do
      you preserve first?
   3. What logs/data do you pull, and from where (Ch 50)? What's the
      likely initial vector given the cert + new user + egress?
   4. Eradicate: rebuild vs clean? Which credentials get rotated? How do
      you know the door is shut?
   5. Recover: backup strategy, exit criteria, extra monitoring.
   6. Obligations: is personal data implicated? Clock started when? Who do
      you notify and by when?
   7. Post-mortem: 3 action items you'd bet money on.

   Write it to ~/sec-lab/reports/part11-ir-tabletop.md.