/incident-triage

name: incident-triage
description: "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."
allowed-tools: Bash, Read, Write, Grep, Glob, WebSearch

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)

1. Preserve human safety 2. Contain the incident to prevent further damage 3. Preserve evidence for investigation 4. Identify root cause and scope 5. 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