responding-to-incidents

Responding to Incidents

Two questions drive every incident: how far did they get, and are they still here. Everything else — the malware, the CVE, the root cause — is supporting detail. Answer those two in order and the response follows.

When to Use

• Suspected or confirmed compromise of a host, account, or cloud tenant
• Forensic analysis of a disk image, memory capture, or log set
• Reconstructing what an attacker did and when
• Scoping blast radius and deciding containment
• Writing a postmortem or a regulator/customer-facing incident narrative

When NOT to Use

• Deep analysis of a recovered sample — use analyzing-malware
• Proactive searching with no known incident — use hunting-threats
• Deciding whether an alert is even an incident yet — use triaging-security-alerts; response begins once triage confirms a true positive
• Building the detections that would have caught it — use engineering-detections
• The incident is in AWS (exposed keys, CloudTrail/GuardDuty) — use investigating-aws-incidents; in Microsoft 365 / Entra — use investigating-m365-entra
• You have a packet capture to work through — use analyzing-network-traffic
• Service outages with no security dimension — this is a security IR skill

Route to a Depth Skill

Specific evidence types have their own procedure skill. This skill sets scope and order; reach for these when a single artifact type becomes the focus.

Artifact / focus	Skill
A RAM capture to work through with Volatility (injected code, in-memory creds, dead-process connections)	analyzing-memory-images
A Microsoft 365 / Entra ID compromise: no disk or memory, only cloud logs (UAL, sign-ins, OAuth grants)	investigating-m365-entra
Finding how an attacker persisted on a Linux host — the systematic sweep across every init path	hunting-threats

The Order That Matters

Preparation → Detection & Analysis → Containment → Eradication → Recovery → Lessons Learned
                      ↑__________________|
                    (re-scope after every new finding)