Runbook Template¶
Copy this template when creating a new investigation runbook. Replace all [PLACEHOLDER] text with actual content.
Runbook Metadata¶
| Field | Value |
|---|---|
| Runbook ID | RB-[XXX] |
| Title | [Alert or scenario name] |
| Version | 1.0 |
| Status | ☐ Draft ☐ Review ☐ Approved ☐ Retired |
| Owner | [Team or role] |
| Last Reviewed | [Date] |
| Next Review | [Date + 12 months] |
| MITRE ATT&CK | [Tactic: TA00XX — Technique: TXXXX] |
| Alert Source | [SIEM rule name / EDR alert name] |
| Nexus SecOps Control | [Nexus SecOps-XXX] |
| SLA | [Critical: 15min acknowledgment / High: 30min] |
Overview¶
What triggers this runbook: [Describe the detection rule or alert that invokes this runbook. Include the rule name, SIEM platform, and what behavior it detects.]
Why this matters: [Explain the security significance of this alert type. What threat actor behavior does it indicate? What is the worst-case scenario if this is a true positive?]
Common causes (FP and TP):
| Cause | TP or FP | Frequency |
|---|---|---|
| [e.g., Attacker using pass-the-hash] | TP | Low |
| [e.g., Admin running authorized script] | FP | High |
| [e.g., Software update process] | FP | Medium |
Pre-Requisites¶
Before starting this runbook, ensure you have access to: - [ ] SIEM query access - [ ] [List any specific tools: EDR console, AD admin, cloud console, etc.] - [ ] [List any data sources needed]
Triage Steps (Tier 1)¶
Complete all steps in order. Document findings in the incident ticket.
Step 1: Initial Context Gathering¶
Time budget: 5 minutes
- [ ] 1.1 Open the alert in [SIEM/Case Management tool]
- [ ] 1.2 Record: Alert timestamp, affected user, affected host, severity
- [ ] 1.3 Look up the affected host in asset inventory:
- Asset type: _ (workstation / server / cloud instance)
- Business owner: _
- Criticality: _ (critical / high / standard)
- Location: _ (on-prem / cloud / remote)
- [ ] 1.4 Look up the affected user in directory:
- Department: _
- Role/title: _
- Manager: _
- Account status: _ (active / recently modified / on leave)
- Admin rights: ☐ Yes ☐ No
- MFA enabled: ☐ Yes ☐ No
Step 2: Alert Enrichment¶
Time budget: 10 minutes
Run the following queries in the SIEM for the affected host and user, looking back 24 hours:
// Authentication events
[Replace with actual SIEM query for auth events for this user]
// Process execution events
[Replace with actual SIEM query for process execution on this host]
// Network connections
[Replace with actual SIEM query for network connections from this host]
- [ ] 2.1 Are there other alerts for this user in the past 7 days? ☐ Yes ☐ No
- [ ] 2.2 Are there other alerts for this host in the past 7 days? ☐ Yes ☐ No
- [ ] 2.3 Is this activity consistent with the user's normal behavior pattern?
- Normal work hours: _
- Event timestamp vs. normal hours: _
- Geographic location (if available): _
Step 3: Key Questions¶
Answer these questions using the evidence gathered:
| Question | Answer |
|---|---|
| Is this consistent with known FP patterns? | ☐ Yes → likely FP ☐ No → investigate further |
| Is the timing anomalous (outside work hours, weekend)? | ☐ Yes ☐ No |
| Is the host/user high-value / high-risk? | ☐ Yes → escalate sooner ☐ No |
| Are there correlated alerts in other systems? | ☐ Yes → possible campaign ☐ No |
| Can the user explain this activity? | ☐ Yes → document explanation ☐ No → escalate |
Step 4: Triage Decision¶
Based on steps 1–3, make a triage decision:
If: Strong FP indicators (known admin activity, authorized process, documented exception)
Then: Close as False Positive — document reason in ticket
If: Inconclusive (cannot confirm benign; cannot confirm malicious)
Then: Escalate to Tier 2 with full context
If: Clear TP indicators (anomalous behavior, no benign explanation, corroborating evidence)
Then: Declare Incident → Follow Tier 2 investigation steps
Triage Decision: ☐ False Positive ☐ Escalate to T2 ☐ Declare Incident
Decision Rationale: [Document your reasoning here in the ticket]
Investigation Steps (Tier 2)¶
Only proceed if escalated from Tier 1 triage.
Step 5: Deep Investigation¶
Time budget: 30–60 minutes
- [ ] 5.1 Pull full 72-hour activity timeline for the affected user and host
- [ ] 5.2 Identify the first malicious event (patient zero event)
- [ ] 5.3 Map the attack chain: Initial → Execution → [Next tactic]
- [ ] 5.4 Identify blast radius:
- Other hosts accessed by this account: _
- Other accounts used from this host: _
- Data accessed: _
- [ ] 5.5 Check threat intelligence for any indicators:
- IP addresses involved: [check TIP]
- Hashes (if malware): [check TIP]
- Domain names: [check TIP]
Step 6: Scope Assessment¶
| Question | Findings |
|---|---|
| Is this a single host or multi-host incident? | |
| Is attacker still active (active session)? | |
| Has data been accessed or exfiltrated? | |
| Estimated time attacker has been present (dwell time): | |
| Any regulatory reportable data involved? |
Severity Assessment: - ☐ Critical — Active threat actor, spreading, critical assets involved - ☐ High — Confirmed threat, contained, sensitive data at risk - ☐ Medium — Confirmed threat, limited scope, no sensitive data - ☐ Low — Confirmed threat, fully isolated, minimal impact
Containment Actions¶
Containment actions are IRREVERSIBLE or DISRUPTIVE. Get approval before proceeding.
Required approval for containment: - Account disable: ☐ Tier 2 analyst approval - Host isolation: ☐ Tier 2 + Manager approval - Network block: ☐ Tier 2 + Security Engineering approval
Containment Options¶
| Action | Impact | When to Use |
|---|---|---|
| Disable user account | User cannot log in to any service | Active credential abuse; attacker using account |
| Reset user password + revoke sessions | Forces re-auth everywhere | Possible credential compromise |
| Isolate host from network | Host loses all connectivity | Active malware; ransomware behavior |
| Block IOC at firewall | Stops communication to specific IP/domain | Confirmed C2 identified |
| Remove from distribution groups | Limits blast radius | Compromised account used for internal phishing |
Actions Taken: - [ ] [Action 1]: Taken by _ at _ UTC. Ticket ref: _ - [ ] [Action 2]: Taken by _ at _ UTC. Ticket ref: _
Evidence Preservation¶
Per Nexus SecOps-071, collect the following before remediation:
- [ ] Memory dump (if live malware): [Tool + procedure]
- [ ] Process list snapshot
- [ ] Network connections snapshot
- [ ] EDR telemetry export (48–72 hours)
- [ ] Authentication logs export
- [ ] Ticket or documentation of all findings
Evidence storage location: [Define per your org's evidence policy]
Escalation Criteria¶
Escalate to Incident Commander / CISO if ANY of the following:
- [ ] Ransomware confirmed on any host
- [ ] Regulatory-reportable data accessed by unauthorized party
- [ ] Active threat actor with persistence across multiple systems
- [ ] Critical infrastructure or executive accounts involved
- [ ] Media inquiry received
- [ ] Attacker has been present > 24 hours (extended dwell time)
Communication Templates¶
Tier 1 → Tier 2 Escalation Note:
Escalating [Alert Name] on [Host] / [User] at [Time].
Triage findings: [2-3 sentence summary]
Enrichment completed: [Yes/No]
Recommendation: [FP / Investigate / Declare Incident]
Analyst → Manager Notification:
[INCIDENT NOTIFICATION] [Severity] incident declared.
Alert: [Name] | Host: [Host] | User: [User]
Current assessment: [Brief summary]
Containment status: [In progress / Complete / Pending approval]
Requesting: [Decision / Resource / Approval]
Closure Criteria¶
Close the ticket when ALL of the following are complete:
- [ ] Disposition documented (TP/FP/Benign)
- [ ] Evidence archived
- [ ] Containment actions documented
- [ ] Affected user/host validated clean (if TP)
- [ ] Detection rule tuning triggered (if FP)
- [ ] Post-incident review scheduled (if Major/Critical)
References¶
- [MITRE ATT&CK technique page: T[XXXX]]
- [Vendor documentation for relevant tool]
- [Internal knowledge base article if applicable]
- Related runbooks: [RB-XXX, RB-XXX]
Runbook version: 1.0 | Nexus SecOps-203 compliant | Review annually