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):

```bash
# 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

```markdown
# 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