Incident Triage — Security Incident Response
Guide rapid triage and initial response to security incidents. Follow NIST SP 800-61 methodology.
Cross-references: siem-detection for the rules that produced the alert this triage is responding to, disk-forensics for deeper disk and memory analysis once a host is contained, breach-patterns for the post-incident pattern extraction that hardens against recurrence, soc-operations for the operational layer above this skill (runbooks, escalation, handoff), security-comms for the stakeholder / customer notifications the response generates, privacy-engineering / hipaa-audit / pci-audit for the regulatory-clock determination when personal data, PHI, or cardholder data is involved, ai-risk-management for AI-specific incident classes (model failure, fairness drift, jailbreak exploitation in production).
Priorities (in order)
- Preserve human safety
- Contain the incident to prevent further damage
- Preserve evidence for investigation
- Identify root cause and scope
- Document everything
Step 1: Classification
Determine incident type:
- Malware: ransomware, trojan, worm, cryptominer
- Unauthorized access: compromised credentials, exploitation
- Data exfiltration: data theft, insider threat
- Denial of service
- Web compromise: defacement, skimming, backdoor
- Phishing / social engineering
Determine severity:
- Critical: active data exfiltration, ransomware spreading, critical system compromise
- High: confirmed compromise, malware detected, unauthorized access
- Medium: suspicious activity, potential indicators, failed attacks
- Low: policy violation, reconnaissance detected, likely false positive
Step 2: Initial Containment
Based on type and severity:
- Network: block suspicious IPs/domains at firewall
- Host: isolate affected system (network disconnect, NOT power off — volatile memory is evidence)
- Account: disable compromised accounts, force password resets
- Application: disable affected service if safe to do so
Critical: Do NOT power off systems. Volatile memory contains evidence.
Step 3: Evidence Preservation
Capture in order of volatility (most volatile first):
# 1. Running processes
ps auxf # Linux
tasklist /v # Windows
# 2. Network connections
ss -tupn # Linux
netstat -anob # Windows
# 3. Logged-in users
who -a # Linux
query user # Windows
# 4. Open files
lsof -nP # Linux
# 5. System logs
journalctl --since "1 hour ago" # Linux/systemd
If memory forensics tools are available (LiME, WinPmem), capture a memory dump before anything else.
Step 4: Initial Analysis
For each suspicious indicator, document:
- What: describe the artifact
- When: timestamps in UTC
- Where: affected system(s)
- How: how it was detected
Common analysis:
- Process tree: look for unusual process names, paths, or parent-child relationships
- Network indicators: unusual outbound connections, DNS queries to suspicious domains, beaconing patterns (regular intervals)
- File indicators: recently modified files in unusual locations, hidden files, new executables
- Log analysis: authentication failures, privilege escalation, service changes, cleared logs
- Persistence: crontab, systemd units, registry Run keys, scheduled tasks, startup items
Step 5: IOC Extraction
Extract and document all indicators of compromise:
| Type |
Examples |
| IP addresses |
Source and destination IPs |
| Domains |
C2 domains, phishing domains |
| File hashes |
MD5 and SHA256 of suspicious files |
| File paths |
Malware locations, dropped files |
| Email addresses |
Phishing sender addresses |
| URLs |
Malicious URLs, C2 endpoints |
| User agents |
Unusual or known-malicious user agents |
Output Format
# Incident Triage Report
## Incident ID: [ID]
## Date/Time: [UTC]
## Severity: [Critical/High/Medium/Low]
## Classification: [incident type]
## Status: [Triage/Contained/Analyzing/Resolved]
### Summary
[2-3 sentence overview]
### Affected Systems
| Hostname | IP | Role | Status |
|----------|-----|------|--------|
### Timeline
| Time (UTC) | Event | Source | Notes |
|------------|-------|--------|-------|
### Indicators of Compromise
| Type | Value | Context | Confidence |
|------|-------|---------|------------|
### Containment Actions Taken
- [ ] [Action and result]
### Evidence Preserved
| Type | Location | Hash | Notes |
|------|----------|------|-------|
### Recommended Next Steps
1. [Immediate priority]
2. [Short-term action]
3. [Follow-up investigation]
### Escalation Checklist
- [ ] Management notified
- [ ] Legal notified (if data breach)
- [ ] Law enforcement (if applicable)
- [ ] Affected parties notified (if data breach)
Boundaries
- Focus on defense and containment, not counter-attack
- Preserve evidence — never modify logs or timestamps
- Recommend legal/management escalation for confirmed breaches
- If unsure about a containment action's impact, advise caution and ask
- Never recommend "hacking back" or retaliatory actions
- Refuse requests to cover up incidents or tamper with evidence
References
- NIST SP 800-61r2: Computer Security Incident Handling Guide
- SANS Incident Handler's Handbook
- MITRE ATT&CK Framework
1---
2name: incident-triage
3description: "Guide rapid triage and initial response to security incidents following NIST SP 800-61 methodology. Use when the user mentions 'incident response,' 'security incident,' 'triage,' 'we've been hacked,' 'breach,' 'compromised,' 'malware detected,' 'suspicious activity,' 'IOC,' 'indicators of compromise,' or needs help handling a security event."
4allowed-tools: Bash, Read, Write, Grep, Glob, WebSearch
5---
6
7# Incident Triage — Security Incident Response
8
9Guide rapid triage and initial response to security incidents. Follow NIST SP 800-61 methodology.
10
11Cross-references: `siem-detection` for the rules that produced the alert this triage is responding to, `disk-forensics` for deeper disk and memory analysis once a host is contained, `breach-patterns` for the post-incident pattern extraction that hardens against recurrence, `soc-operations` for the operational layer above this skill (runbooks, escalation, handoff), `security-comms` for the stakeholder / customer notifications the response generates, `privacy-engineering` / `hipaa-audit` / `pci-audit` for the regulatory-clock determination when personal data, PHI, or cardholder data is involved, `ai-risk-management` for AI-specific incident classes (model failure, fairness drift, jailbreak exploitation in production).
12
13## Priorities (in order)
14
151. Preserve human safety
162. Contain the incident to prevent further damage
173. Preserve evidence for investigation
184. Identify root cause and scope
195. Document everything
20
21## Step 1: Classification
22
23Determine incident type:
24- **Malware:** ransomware, trojan, worm, cryptominer
25- **Unauthorized access:** compromised credentials, exploitation
26- **Data exfiltration:** data theft, insider threat
27- **Denial of service**
28- **Web compromise:** defacement, skimming, backdoor
29- **Phishing / social engineering**
30
31Determine severity:
32- **Critical:** active data exfiltration, ransomware spreading, critical system compromise
33- **High:** confirmed compromise, malware detected, unauthorized access
34- **Medium:** suspicious activity, potential indicators, failed attacks
35- **Low:** policy violation, reconnaissance detected, likely false positive
36
37## Step 2: Initial Containment
38
39Based on type and severity:
40- **Network:** block suspicious IPs/domains at firewall
41- **Host:** isolate affected system (network disconnect, NOT power off — volatile memory is evidence)
42- **Account:** disable compromised accounts, force password resets
43- **Application:** disable affected service if safe to do so
44
45**Critical: Do NOT power off systems.** Volatile memory contains evidence.
46
47## Step 3: Evidence Preservation
48
49Capture in order of volatility (most volatile first):
50
51```bash
52# 1. Running processes
53ps auxf # Linux
54tasklist /v # Windows
55
56# 2. Network connections
57ss -tupn # Linux
58netstat -anob # Windows
59
60# 3. Logged-in users
61who -a # Linux
62query user # Windows
63
64# 4. Open files
65lsof -nP # Linux
66
67# 5. System logs
68journalctl --since "1 hour ago" # Linux/systemd
69```
70
71If memory forensics tools are available (LiME, WinPmem), capture a memory dump before anything else.
72
73## Step 4: Initial Analysis
74
75For each suspicious indicator, document:
76- **What:** describe the artifact
77- **When:** timestamps in UTC
78- **Where:** affected system(s)
79- **How:** how it was detected
80
81Common analysis:
82- **Process tree:** look for unusual process names, paths, or parent-child relationships
83- **Network indicators:** unusual outbound connections, DNS queries to suspicious domains, beaconing patterns (regular intervals)
84- **File indicators:** recently modified files in unusual locations, hidden files, new executables
85- **Log analysis:** authentication failures, privilege escalation, service changes, cleared logs
86- **Persistence:** crontab, systemd units, registry Run keys, scheduled tasks, startup items
87
88## Step 5: IOC Extraction
89
90Extract and document all indicators of compromise:
91
92| Type | Examples |
93|------|---------|
94| IP addresses | Source and destination IPs |
95| Domains | C2 domains, phishing domains |
96| File hashes | MD5 and SHA256 of suspicious files |
97| File paths | Malware locations, dropped files |
98| Email addresses | Phishing sender addresses |
99| URLs | Malicious URLs, C2 endpoints |
100| User agents | Unusual or known-malicious user agents |
101
102## Output Format
103
104```markdown
105# Incident Triage Report
106## Incident ID: [ID]
107## Date/Time: [UTC]
108## Severity: [Critical/High/Medium/Low]
109## Classification: [incident type]
110## Status: [Triage/Contained/Analyzing/Resolved]
111
112### Summary
113[2-3 sentence overview]
114
115### Affected Systems
116| Hostname | IP | Role | Status |
117|----------|-----|------|--------|
118
119### Timeline
120| Time (UTC) | Event | Source | Notes |
121|------------|-------|--------|-------|
122
123### Indicators of Compromise
124| Type | Value | Context | Confidence |
125|------|-------|---------|------------|
126
127### Containment Actions Taken
128- [ ] [Action and result]
129
130### Evidence Preserved
131| Type | Location | Hash | Notes |
132|------|----------|------|-------|
133
134### Recommended Next Steps
1351. [Immediate priority]
1362. [Short-term action]
1373. [Follow-up investigation]
138
139### Escalation Checklist
140- [ ] Management notified
141- [ ] Legal notified (if data breach)
142- [ ] Law enforcement (if applicable)
143- [ ] Affected parties notified (if data breach)
144```
145
146## Boundaries
147
148- Focus on defense and containment, not counter-attack
149- Preserve evidence — never modify logs or timestamps
150- Recommend legal/management escalation for confirmed breaches
151- If unsure about a containment action's impact, advise caution and ask
152- Never recommend "hacking back" or retaliatory actions
153- Refuse requests to cover up incidents or tamper with evidence
154
155## References
156
157- NIST SP 800-61r2: Computer Security Incident Handling Guide
158- SANS Incident Handler's Handbook
159- MITRE ATT&CK Framework
briiirussell