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