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

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:

Output Format

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