Incident response

Incident response (IR) is the orderly process to detect, contain, eradicate, and recover a system after a compromise, learning so it doesn’t recur. Improvised IR destroys evidence and prolongs damage; prepared IR minimizes impact and downtime.

flowchart LR
    A[Preparation] --> B[Identification]
    B --> C[Containment]
    C --> D[Eradication]
    D --> E[Recovery]
    E --> F[Lessons learned]
    F -.-> A

The IR cycle (NIST SP 800-61)

1. PREPARATION   plan, team (CSIRT), tools, contacts, playbooks, training
2. DETECTION & ANALYSIS  identify the incident, its scope and severity (see def-soc)
3. CONTAINMENT   stop the spread (short term) without destroying evidence
4. ERADICATION   remove the cause (malware, accounts, persistence)
5. RECOVERY      restore to normal operation (see def-backup) and watch for recurrence
6. LESSONS LEARNED  blameless postmortem -> control and detection improvements

SANS uses an equivalent 6-phase model (PICERL). The essence: a defined process BEFORE the incident.

Classification and severity

- severity by impact (data, critical services, scope) and by type (ransomware, breach, DoS)
- trigger the response level and notifications (legal/GDPR, management, authorities)
- active-encryption ransomware != an isolated phishing: the runbook and timelines change

Containment (the delicate balance)

Short term   isolate host from the network (don't power off: memory is lost, see dfir-memoria),
             disable compromised accounts, block IOCs/C2
Preserve     capture RAM and disk BEFORE cleaning (dfir-memoria/dfir-disco)
Long term    temporary patches/hardening to operate while eradicating
# isolate without alerting the attacker when you want to observe; depends on strategy

Eradication and recovery

- remove ALL persistence (mal-persist), attacker accounts, webshells, tasks, services
- reset credentials (especially privileged and krbtgt if a DC was hit, see ad-persist)
- restore from verified clean backups (def-backup); don't trust a "cleaned" host
- reinforced post-incident monitoring to detect reappearance

Communication and legal aspects

- who decides and who communicates (internal, customers, regulators)
- GDPR: breach notification to the authority within 72h if personal data (see grc-rgpd)
- preserve chain of custody in case of legal action (see dfir-cadena)

Blue Team / operation

Have playbooks per incident type (ransomware, BEC, intrusion) tested with tabletop exercises.
Preserve evidence (order of volatility) before containing; coordinate with DFIR (Disk forensics/memoria).
Measure MTTD/MTTR and run a blameless postmortem that generates concrete improvements.
Integrate with the SOC (SOC operations), backup (Backups & recovery), threat intel (CTI fundamentals), and communication/legal.

Real-world cases

NotPetya (2017): lack of containment and resilient backups made the incident catastrophic (Maersk).
SolarWinds (2020): large-scale IR; complete eradication (tokens, federation) was the key challenge.
Modern ransomware: containment speed and backup state decide the outcome.

Testing checklist

IR plan, CSIRT, and playbooks prepared and tested (tabletop)
Detection/analysis: scope and severity determined
Preserve evidence (RAM/disk) before containing
Contain without destroying evidence or alerting prematurely
Eradicate all persistence and reset credentials
Recover from verified clean backups
Legal notifications (GDPR 72h) and chain of custody
Blameless postmortem → control and detection improvements