feat: add source-threat-modeling and response-playbooks skills

.claude/skills/response-playbooks/SKILL.md

@@ -0,0 +1,277 @@
+---
+name: response-playbooks
+description: >
+  Detection-to-response mapping and SOAR playbook design. Analyzes detections,
+  recommends tiered response actions (observe, investigate, contain, remediate),
+  and produces handoff docs for fusion-workflows to generate workflow YAML.
+  Use when planning response automation for detections, designing SOAR playbooks,
+  or mapping detections to Falcon Fusion workflow actions.
+allowed-tools: Read, Write, Grep, Glob, Bash
+---
+
+# 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-workflows` skill 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:
+
+```bash
+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:**
+
+```markdown
+# 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
+
+1. **Never auto-execute containment.** Tier 3 actions always require human approval. False positive containment is worse than delayed response.
+2. **Every detection gets Tier 1.** At minimum: create a case and notify someone.
+3. **Match response to blast radius.** A medium-severity anomalous login doesn't need host isolation.
+4. **Validate before recommending.** Use action discovery to confirm what's available in the tenant.
+5. **Document Tier 4 even though it's manual.** The SOC needs to know what comes after containment.