incident-triage

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