Incident Response

NIST SP 800-61 Rev. 2 defines the incident response lifecycle as four phases: Preparation, Detection And Analysis, Containment Eradication and Recovery, and Post-Incident Activity.

graph TD
    A[Preparation] --> B[Detection & Analysis]
    B --> C[Containment]
    C --> D[Eradication]
    D --> E[Recovery]
    E --> F[Post-Incident Activity]
    F --> A

    style A fill:#bfb,stroke:#333
    style B fill:#bbf,stroke:#333
    style C fill:#fbb,stroke:#333
    style D fill:#f9f,stroke:#333
    style E fill:#fdb,stroke:#333
    style F fill:#bdf,stroke:#333

The lifecycle is not strictly linear. Detection may happen during containment. Recovery may reveal The need for additional eradication. Post-incident analysis feeds back into preparation, improving Readiness for the next incident.

Preparation is the most important phase. An unprepared team will waste critical time during an Incident figuring out roles, tools, and processes — while the attacker continues to operate.

An IRP is a documented, tested plan that defines how the organization will respond to security Incidents. It should be a living document that is reviewed and updated at least annually.

Essential IRP components:

For small organizations, roles may overlap. The critical requirement is that someone is explicitly Responsible for each function.

Playbooks are predefined procedures for specific incident types. They reduce decision-making under Pressure and ensure consistent, repeatable responses.

Tabletop exercises are discussion-based simulations where the IR team walks through a hypothetical Incident scenario. They test the plan, identify gaps, and build muscle memory without the pressure Of a real incident.

Exercise structure:

1. Scenario design: Choose a realistic scenario (ransomware, data breach, insider threat)
2. Inject timeline: Progress the scenario with new information at intervals
3. Discussion: Team discusses what they would do at each step
4. Observation: Facilitator notes gaps, confusion, and delays
5. Debrief: Review findings, update playbooks and IRP

Example inject sequence for a ransomware exercise:

Not every alert is an incident. Effective triage distinguishes true positives from false positives And prioritizes by severity.

Triage decision tree:

graph TD
    Alert[Alert Received] --> Q1{Is it a true positive?}
    Q1 -->|No| FP[Close as false positive<br/>Update detection rule]
    Q1 -->|Yes| Q2{Is the threat active?}
    Q2 -->|No| HIST[Close as historical<br/>Document for trending]
    Q2 -->|Yes| Q3{What is the scope?}
    Q3 -->|Single host| S1[Severity: Low/Medium<br/>Assign to analyst]
    Q3 -->|Multiple hosts| Q4{Is data compromised?}
    Q4 -->|No| S2[Severity: High<br/>Escalate to team lead]
    Q4 -->|Yes| S3[Severity: Critical<br/>Escalate to incident commander]

Sharing IOCs within your organization and with the broader security community amplifies detection Capability. A compromise detected at one organization can be prevented at others if IOCs are shared Rapidly.

Sharing IOCs must be done carefully. Sanitize internal information before sharing externally — Remove internal hostnames, usernames, and any information that could reveal your network topology or Security posture.

Detection rules translate threat intelligence into automated alerts in your SIEM or EDR:

# Sigma rule: Detect suspicious PowerShell execution
title: Suspicious PowerShell Encoded Command
status: production
description: "NIST SP 800-61 Rev. 2 defines the incident response lifecycle as four phases: Preparation, Detection And Analysis, Containment Eradication and Recovery, and"
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: "\powershell.exe''
    CommandLine|contains:
      - "-enc'
      - '-EncodedCommand'
      - '-w hidden'
  condition: selection
level: medium
tags:
  - attack.execution
  - attack.t1059.001

# Sigma rule: Detect potential SSH brute force
title: SSH Brute Force Attempt
status: production
description: "NIST SP 800-61 Rev. 2 defines the incident response lifecycle as four phases: Preparation, Detection And Analysis, Containment Eradication and Recovery, and..."
logsource:
  category: authentication
  product: linux
detection:
  selection:
    service: sshd
    result: failure
  timeframe: 5m
  condition: selection | count() > 10
level: high
tags:
  - attack.brute_force
  - attack.t1110

MITRE ATT&CK provides a framework of adversary tactics, techniques, and procedures (TTPs). Mapping Detected activity to ATT&CK techniques helps understand the attacker”s goals and predict next steps.

graph LR
    subgraph Initial Access
        T1[T1566 Phishing]
        T2[T1190 Exploit Public-Facing App]
    end
    subgraph Execution
        T3[T1059 Command and Scripting]
        T4[T1204 User Execution]
    end
    subgraph Persistence
        T5[T1543 Create/Modify System Process]
        T6[T1053 Scheduled Task/Job]
    end
    subgraph Lateral Movement
        T7[T1021 Remote Services]
        T8[T1570 Lateral Tool Transfer]
    end
    subgraph Exfiltration
        T9[T1048 Exfiltration Over Alternative Protocol]
        T10[T1567 Exfil Over Web Service]
    end

    T1 --> T3 --> T5 --> T7 --> T9
    T2 --> T4 --> T6 --> T8 --> T10

Containment limits the damage by isolating affected systems and preventing further spread. The goal Is to stop the bleeding without destroying evidence.

Immediate actions to stop the active threat:

Actions that allow business to continue while the investigation proceeds:

• Deploy clean systems alongside compromised ones (temporary replacements)
• Implement network segmentation to contain the affected zone
• Apply emergency patches or configuration changes
• Set up monitoring on containment boundaries for escape attempts
• Implement enhanced logging on affected systems