willwebster5 Response Playbooks
Turn detections into automated response. This skill analyzes what a detection looks for, recommends tiered response actions appropriate to the threat, and hands off to fusion-workflows for workflow YAML generation. It bridges the gap between "alert fires" and "something happens."
Response architect, not workflow builder. This skill decides what response fits a detection. The
fusion-workflowsskill builds the actual workflow YAML.
When to Use This Skill
- You have detections deployed (or proposed) and need response automation
- You want to design SOAR playbooks for a set of detections
- You need to map detection severity/type to appropriate response actions
- You're deciding which detections warrant automated containment vs. notification-only
Handoff Input
This skill accepts:
- Direct invocation — user points at detections by name, file path, or description
- Handoff doc from source-threat-modeling — read the doc and use its context for Phase 1
If consuming a handoff doc, skip Phase 1 questions already answered in the doc.
Phase 1: Detection Intake
Goal: Understand what each detection looks for and what's at stake.
For each detection the user wants response automation for:
Step 1: Read the detection
- If it's a deployed detection: read from
resources/detections/ - If it's from a handoff doc: read the context provided
- If described verbally: ask enough questions to understand the threat
Gather:
- Detection name and CQL logic
- Severity level
- MITRE ATT&CK mapping (technique + tactic)
Step 2: Identify the center entity
What is the primary subject of this detection?
| Entity Type | Examples |
|---|---|
| User account | Identity-based threats — credential attacks, privilege escalation |
| Host/endpoint | Malware, LOLBins, persistence, lateral movement |
| IP address | Network-based threats — C2, scanning, exfiltration |
| Cloud resource | Infrastructure threats — config changes, IAM abuse |
| Application | SaaS/app-level threats — data theft, API abuse |
Step 3: Assess blast radius
If this detection fires as a true positive, how bad is it?
| Blast Radius | Meaning | Examples |
|---|---|---|
| Critical | Active compromise, data loss in progress | Ransomware, active exfiltration, admin account takeover |
| High | Escalation or movement underway | Privilege escalation, lateral movement, credential theft |
| Medium | Suspicious but contained | Policy violation, anomalous login, config change |
| Low | Informational, worth tracking | New device, unusual time of day, minor anomaly |
Present the intake summary (detection, entity, blast radius) and confirm with user before proceeding.
STOP — Get user confirmation on the intake assessment.
Phase 2: Response Recommendation
Goal: Propose a tiered response plan for each detection.
Response Tiers
| Tier | Name | Automation Level | Description |
|---|---|---|---|
| Tier 1 | Observe | Always auto-fire | Create case, log event, notify Slack/email |
| Tier 2 | Investigate | Always auto-fire | Enrich alert with host details, user history, related alerts |
| Tier 3 | Contain | Requires human approval | Disable user, isolate host, revoke session, block IP |
| Tier 4 | Remediate | Manual only | Reset credentials, remove persistence, restore from backup |
Recommendation Process
For each detection:
1. Tier 1 — Observe (every detection gets this)
- Create case with appropriate severity
- Notify the relevant channel (Slack, email, PagerDuty based on severity)
- Log to SIEM for correlation
2. Tier 2 — Investigate (based on center entity)
| Entity Type | Enrichment Actions |
|---|---|
| User account | Recent auth history, group memberships, risk score, MFA status |
| Host/endpoint | Running processes, network connections, login history, installed software |
| IP address | Geo lookup, reputation check, historical connections, associated users |
| Cloud resource | Config change history, access logs, associated IAM roles |
| Application | Recent API calls, data access patterns, admin actions |
3. Tier 3 — Contain (based on severity + threat type)
| Severity | Threat Type | Containment Recommendation |
|---|---|---|
| Critical | Active attack (exfil, ransomware, admin takeover) | Immediate containment with approval gate |
| Critical | Credential compromise (MFA fatigue, brute force success) | Disable user + revoke sessions with approval gate |
| High | Lateral movement | Isolate host with approval gate |
| High | Privilege escalation | Suspend elevated access with approval gate |
| Medium or below | Any | Skip containment — observe and investigate only |
Every Tier 3 action MUST have a human approval gate. Never auto-execute containment. False positive containment is worse than delayed response.
4. Tier 4 — Remediate (always manual, but document it)
Document what the SOC should do after containment:
- Credential reset procedures
- Host reimaging steps
- Config rollback process
- Evidence preservation requirements
- Scope assessment (who/what else was affected?)
Validate available actions
Before recommending, confirm what's actually available in the tenant:
python .claude/skills/fusion-workflows/scripts/action_search.py --vendor <vendor>
python .claude/skills/fusion-workflows/scripts/action_search.py --use-case <use-case>
Only recommend actions that are available. If a recommended action isn't available, note it as a gap and suggest alternatives.
Present the response plan
For each detection, present:
Detection: <name>
Severity: <severity> | Entity: <entity type> | Threat: <MITRE tactic>
Tier 1 (auto):
- Create case (severity: <X>)
- Notify <channel> with: detection name, affected entity, key indicators
Tier 2 (auto):
- <specific enrichment actions>
Tier 3 (approval required):
- <containment action> — requires SOC analyst approval
Tier 4 (manual):
- <remediation steps for SOC to execute>
STOP — Get user approval on the response plan before generating handoff docs.
Phase 3: Workflow Generation & Handoff
Goal: Produce handoff documents for fusion-workflows to build the actual workflow YAML.
For each approved response plan, write a handoff doc to docs/handoffs/.
Filename: YYYY-MM-DD-response-playbooks-to-fusion-workflows-<detection-name>.md
Template:
# Handoff: Response Playbooks → Fusion Workflows
## Objective
Create a Fusion workflow to automate response for: <detection name>
## Source
- **Produced by:** response-playbooks skill
- **Date:** <today>
- **Target skill:** fusion-workflows
## Context
| Field | Value |
|---|---|
| Detection name | <name> |
| Detection resource_id | <id, if deployed> |
| Severity | <severity> |
| Center entity | <entity type> |
| MITRE technique | <ID> — <name> |
| MITRE tactic | <tactic> |
## Approved Response Plan
### Tier 1 — Observe (auto-fire)
- **Create case** — severity: <X>, title template: "<detection name> — <entity value>"
- **Notify** — channel: <channel>, include: detection name, affected entity, source IP, event count
### Tier 2 — Investigate (auto-fire)
- **Enrich** — <specific actions and what data to pull>
### Tier 3 — Contain (approval required)
- **<Action>** — <details>
- **Approval gate:** SOC analyst must approve before execution via <mechanism>
### Tier 4 — Remediate (manual)
- <Steps for SOC to execute manually after containment>
## Decisions Made
These have been reviewed and approved by the user. The receiving skill should NOT re-ask:
- <decision 1>
- <decision 2>
## Constraints
- Tier 3 actions MUST have a human approval gate — never auto-execute containment
- Notification must include: <required fields>
- <any tenant-specific constraints>
## Workflow Structure
- **Trigger:** Detection alert (detection name: <name>)
- **Flow:** Tier 1 actions → Tier 2 enrichment → conditional Tier 3 containment (with approval)
- **Approval mechanism:** <how the approval gate should work>
## Artifacts
- <paths to any files from earlier phases, or "None">
Tell the user: "Handoff doc written to <path>. Invoke the fusion-workflows skill and point it at this file to generate the workflow YAML."
Response Pattern Library
Common detection-to-response mappings. These inform recommendations but don't override human judgment — use them as starting points.
| Detection Type | Entity | Severity | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
|---|---|---|---|---|---|---|
| Credential attack (brute force, stuffing, MFA fatigue) | User | Critical | Case + Slack | Auth history, risk score | Disable user, revoke sessions | Credential reset |
| Privilege escalation (new admin, role change) | User | High | Case + Slack | Access audit, change history | — | Review and revert access |
| Data exfiltration (bulk download, unusual export) | User/App | Critical | Case + Slack | Download history, data classification | Revoke sessions, block IP | Audit data exposure |
| Suspicious network (C2 beacon, unusual dest) | Host | High | Case + Slack | Process list, network connections | Isolate host | Reimage, hunt for lateral |
| Cloud config change (SG, IAM policy) | Cloud Resource | Medium | Case + Slack | Config diff, who-changed-what | — | Revert change |
| Anomalous login (impossible travel, new device) | User | Medium | Case + Slack | Login history, device inventory | — | — |
| Audit log tampering | Source | Critical | Case + Slack + page | Log gap analysis | Isolate source, freeze state | Forensic investigation |
| Service account abuse | User | High | Case + Slack | Service account scope, recent API calls | Rotate credentials | Audit all service account access |
Key Principles
- Never auto-execute containment. Tier 3 actions always require human approval. False positive containment is worse than delayed response.
- Every detection gets Tier 1. At minimum: create a case and notify someone.
- Match response to blast radius. A medium-severity anomalous login doesn't need host isolation.
- Validate before recommending. Use action discovery to confirm what's available in the tenant.
- Document Tier 4 even though it's manual. The SOC needs to know what comes after containment.