security-incident-response

When this skill is activated, always start your first response with the 🧢 emoji.

Security Incident Response

A practitioner's framework for detecting, containing, and recovering from security incidents. This skill covers the full NIST incident response lifecycle - preparation through lessons learned - with emphasis on when to act, what to preserve, and how to communicate under pressure. Designed for engineers and security practitioners who need to respond with speed and precision when a breach is suspected or confirmed.

When to use this skill

Trigger this skill when the user:

• Suspects or confirms a security breach, intrusion, or unauthorized access
• Needs to classify incident severity and decide on escalation
• Is containing a threat (isolating systems, revoking credentials, blocking IPs)
• Needs to preserve forensic evidence or maintain chain of custody
• Is communicating an incident to stakeholders, executives, or regulators
• Is eradicating malware, backdoors, or persistent access from systems
• Is writing a security incident report or post-mortem

Do NOT trigger this skill for:

• Proactive security hardening or architectural review (use the backend-engineering

security reference instead)

• Vulnerability disclosure or bug bounty triage that has not yet become an active

incident

Key principles

1. Contain first, investigate second - Stopping the bleeding takes priority over

understanding the wound. Isolate affected systems before collecting forensic evidence if the attacker still has active access. Evidence is recoverable; damage from continued access may not be.

1. Preserve evidence - Everything you do to an affected system changes it. Use

read-only mounts, memory snapshots, and write blockers. Log every command you run. Courts and regulators require chain of custody.

1. Communicate early and often - A 30-second "we are investigating" message is

better than silence for three hours. Stakeholders need to plan. Delayed notification erodes trust far more than the incident itself.

1. Document everything in real-time - Keep a live incident timeline. Record every

action taken, every finding, every decision, and every person involved. Memory fades in 24 hours; your logs won't.

1. Never blame - Incidents are system failures, not individual failures. A

post-mortem that names a person instead of fixing a process produces fear, not improvement. Apply the same principle as SRE blameless post-mortems.

Core concepts

NIST IR Phases

The NIST SP 800-61 framework defines six phases that form the backbone of any structured incident response program:

| Phase | Goal | Key outputs | |---|---|---| | Preparation | Build capability before incidents happen | Runbooks, contact lists, tooling, trained responders | | Detection & Analysis | Identify that an incident is occurring and understand its scope | Severity classification, initial IOC list, affected asset inventory | | Containment | Prevent the incident from spreading or causing more damage | Isolated systems, revoked credentials, blocked IPs/domains | | Eradication | Remove the threat from all affected systems | Cleaned/reimaged hosts, patched vulnerabilities, removed persistence mechanisms | | Recovery | Restore systems to normal operations safely | Verified clean systems returned to production, monitoring confirmed | | Lessons Learned | Improve defenses and process based on what happened | Post-mortem report, process changes, new detections |

Phases are not always strictly sequential. Containment and eradication can overlap. Detection and analysis continues throughout the entire response.

Severity Classification

Assign severity at detection time. Reassess as facts emerge.

| Severity | Definition | Response SLA | Example | |---|---|---|---| | P1 - Critical | Active breach with ongoing data exfiltration or system compromise | Immediate, 24/7 response | Attacker has shell on production DB, ransomware spreading | | P2 - High | Confirmed compromise but impact is contained or unclear | Response within 1 hour | Stolen API key used, single host compromised, credential stuffing succeeding | | P3 - Medium | Suspicious activity with no confirmed compromise | Response within 4 hours | Anomalous login from new country, unusual outbound traffic spike | | P4 - Low | Potential indicator, no evidence of compromise | Next business day | Single failed login attempt, phishing email reported but not clicked |

When in doubt, escalate to a higher severity. Downgrading is always easier than explaining why you under-responded.

Chain of Custody

Chain of custody is the documented, unbroken record of who collected, handled, and transferred evidence. Required for:

• Legal proceedings or law enforcement cooperation
• Regulatory compliance (HIPAA, PCI-DSS, GDPR)
• Insurance claims
• Internal disciplinary actions

Every piece of evidence needs: what it is, when it was collected, who collected it, where it has been stored, and who has accessed it since collection.

IOC Types

Indicators of Compromise (IOCs) are artifacts that indicate a system may have been compromised. Categories:

| Type | Examples | Volatility | |---|---|---| | Atomic | IP addresses, domain names, email addresses, file hashes | Low - easy to change by attacker | | Computed | Network traffic patterns, YARA rules, behavioral signatures | Medium - harder to change | | Behavioral | TTP patterns (MITRE ATT&CK techniques), lateral movement indicators | High - most durable signal |

Prefer behavioral IOCs for detection rules. Atomic IOCs burn quickly as attackers rotate infrastructure. Map findings to MITRE ATT&CK techniques when possible - it enables cross-team communication and threat intelligence sharing.

Common tasks

Detect and classify an incident

When an alert fires or suspicious activity is reported, your first job is triage.

Initial triage checklist:

• [ ] What triggered the alert or report? (alert, user report, third-party notification)
• [ ] What systems and data are potentially affected?
• [ ] Is the attacker likely still active (ongoing) or was this historical activity?
• [ ] Is PII, PHI, PCI, or other regulated data in scope?
• [ ] What is the business impact if this is confirmed?

Severity matrix (quick reference):

Is an attacker actively operating in your systems right now?
  YES -> P1. Activate incident response team immediately.
  NO  -> Is a confirmed compromise present (evidence of unauthorized access)?
    YES -> P2. Assemble response team within 1 hour.
    NO  -> Is there suspicious activity with credible threat indicators?
      YES -> P3. Assign responder, investigate within 4 hours.
      NO  -> P4. Log and monitor, review next business day.

Open an incident channel (e.g., Slack #inc-YYYY-MM-DD-shortname) and post the initial severity assessment within 15 minutes of detection.

Contain a breach

Containment is the most time-critical action. Execute in two stages:

Short-term containment (immediate - do not wait for full investigation):

• Isolate affected hosts from the network (network segment or pull the cable) without

powering them off - RAM evidence is lost on shutdown

• Revoke or rotate all credentials that may have been exposed
• Block attacker-controlled IPs and domains at the firewall and DNS level
• Disable any compromised service accounts or API keys
• Preserve a snapshot (cloud VM snapshot or disk image) before remediation begins

Long-term containment (within hours):

• Move affected systems to an isolated network segment for forensic analysis
• Deploy additional monitoring on systems adjacent to the compromise
• Validate that backups for affected systems are clean and pre-date the intrusion
• Determine if the attacker has established persistence (scheduled tasks, cron jobs,

SSH authorized_keys, new user accounts, implants)