iblai-security-incident-triage

# /iblai-security-incident-triage

Drive rapid triage and initial response to a security incident. Follow
NIST SP 800-61 methodology.

Do NOT power off affected hosts — volatile memory is evidence. Do NOT
recommend retaliation or "hacking back."

## Priorities

In this order, no exceptions:

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

Pin the 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**

Pin the 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

Match the action to type and severity:

- **Network:** block suspicious IPs/domains at the firewall
- **Host:** isolate the affected system (network-disconnect — NOT power off; volatile memory is evidence)
- **Account:** disable compromised accounts, force password resets
- **Application:** disable the 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 paths:

- **Process tree:** unusual names, paths, or parent-child relationships
- **Network indicators:** unusual outbound connections, DNS to suspicious domains, beaconing patterns (regular intervals)
- **File indicators:** recently modified files in unusual locations, hidden files, new executables
- **Log analysis:** auth failures, privilege escalation, service changes, cleared logs
- **Persistence:** crontab, systemd units, registry Run keys, scheduled tasks, startup items

## Step 5: IOC Extraction

Document every indicator 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

- Defense and containment, not counter-attack.
- Preserve evidence — never modify logs or timestamps.
- Recommend legal/management escalation for confirmed breaches.
- If a containment action's blast radius is unclear, ask before running it.
- 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