ir-playbook-vulnerability-spike v2.1A

Immutable. This exact content is served forever at /api/v1/blob/b548570c967a9897.

---
name: ir-playbook-vulnerability-spike
description: Incident-response playbook (PB-005) for vulnerability spikes — sudden jumps in new CVE findings, the same CVE across many hosts, KEV-listed CVEs on exposed assets, SCA regressions, or exploitation attempts against vulnerable assets; use when Wazuh vulnerability-detector alerts surge (rules 23505, 23506) or web/IDS exploitation alerts (rules 31106, 31152, 86601) hit a known-vulnerable host.
allowed-tools: get_wazuh_alerts search_security_events get_wazuh_agents get_agent_ports perform_risk_assessment get_case search_cases update_case add_entities link_mitre add_finding list_actions
metadata:
  category: response
  display_name: IR Playbook — Vulnerability Spike
  standards: [cisa-kev, first-epss, cisa-ssvc, nist-800-53r5, cis-v8-1, iso-27001-2022, nist-800-61r3, mitre-attack]
  version: "2.1"
---
# IR Playbook — Vulnerability Spike (PB-005)

Owned by the **vuln-management** agent; escalates to the incident swarm when exploitation is observed. Severity
varies with CVSS, KEV status, exposure and asset criticality. MITRE ATT&CK (exploitation): T1190, T1203, T1210,
T1068. Rule IDs are from the stock Wazuh 4.14 ruleset (levels official). Full procedure: `references/playbook.md`.

## 1. Detection signals

| Signal | Wazuh rules (level) | Trigger |
|---|---|---|
| New active vulnerabilities by severity (group `vulnerability-detector`) | rule 23506 (L13, Critical), rule 23505 (L10, High), rule 23504 (L7, Medium), rule 23503 (L5, Low) | spike > 3σ above the 7-day average and ≥ 10 findings |
| Vulnerability fixed / cleared | rule 23502 (L3, CVE solved by an update), rule 23507 (L3, vulnerabilities cleared) | use for remediation tracking, **not** as new findings |
| CVE without severity yet | rule 23508 (L3, awaiting analysis) | re-check once NVD scores it |
| Same CVE on many hosts | vulnerability inventory (`get_wazuh_vulnerabilities`) | CVE on ≥ 20 % of hosts and ≥ 5 hosts |
| Web exploitation attempts | rules 31103 (L7, SQL injection), 31104 (L6, common web attack), 31106 (L6, web attack returned HTTP 200), 31152 (L10, multiple SQLi from one source), 31153 (L10, multiple web attacks from one source), 31115 (L13, over-long URL) | against a vulnerable asset |
| IDS / exploit attempts | rule 86601 (L3, Suricata alert — severity comes from the signature), rule 40104 (L13, possible buffer overflow) | ≥ 5 attempts or 5× daily average |
| Hardening regression (SCA) | rule 19011 (L9, check passed → failed), rule 19014 (L9, not applicable → failed), rule 19004 (L7, policy score < 50 %), rule 19005 (L9, score < 30 %) | clusters on the same benchmark control |
| KEV match | CISA KEV catalog (external) | any KEV-listed CVE present → auto-escalate |

Note: the detector's levels follow the CVE severity **label** (Low/Medium/High/Critical), not a CVSS threshold you set.

## 2. Assessment (vuln-management agent)

1. Fleet view: `get_wazuh_vulnerability_summary`, `get_wazuh_critical_vulnerabilities`, then `get_wazuh_vulnerabilities`
   per affected agent (`severity`, `compact: true`); `perform_risk_assessment`
   per crown-jewel agent. Alert trend: `get_wazuh_alerts` with `rule_groups: ["vulnerability-detector"]`,
   `level: "10+"`, `timestamp_start: "now-7d"`.
2. Answer: which CVEs, CVSS vector, **KEV-listed?**, EPSS, public exploit (`search_external_context` for public CVE
   data only)? How many hosts, which are internet-facing/DMZ/production (`get_wazuh_agents`, `get_agent_ports` for
   exposed services)? Evidence of **exploitation** (`search_security_events` for web/IDS rules above against the
   affected agents)? Real spike or artifact?
3. Sanity checks: new agents enrolled or detector feed updated in the last 24 h → expected jump; spike limited to one
   OS/package family → one upstream advisory, batch remediation; spike + exploitation alerts on the same assets →
   incident (section 4).
4. `search_cases` for the CVE; open a case when exploitation is suspected or a KEV CVE is exposed; otherwise record the
   prioritization in a vulnerability report. `add_entities` (hosts with `agent_id`, CVE ids), `add_finding`.

## 3. Prioritization (KEV → EPSS → CVSS + environment → SSVC)

| Order | Rule |
|---|---|
| 1 | KEV-listed → **Act**; remediate by the CISA due date (BOD 22-01) or sooner if exposed |
| 2 | EPSS ≥ 0.1 or public/weaponized exploit → raise one priority level |
| 3 | CVSS base adjusted for environment (C/I/A requirements, internet exposure, asset tier) |
| 4 | SSVC decision: Track / Track* / Attend / Act |

Default SLAs (response / patch): critical 15 min / 24 h, high 1 h / 72 h, medium 4 h / 7 days, low 24 h / 30 days.
Critical escalation when CVSS ≥ 9.0 **and** an exploit is public or exploited in the wild **and** the asset is
internet-facing or production.

## 4. Exploitation response

If exploitation alerts hit a vulnerable asset or a zero-day is suspected: hand off to investigation with the CVE,
affected agent ids and alert evidence (post-exploitation checks: web shells, new listeners, reverse shells), and
`link_mitre` T1190 (or T1210/T1068) on the case.

## 5. Response (response-planner)

| Situation | Proposal |
|---|---|
| Active exploitation from external sources | `propose_action(type="block_ip", params={"ip_address": <src>, "agent_id": <id>})`, or `"all_agents": true` for a campaign |
| Per-host firewall drop | `propose_action(type="firewall_drop", params={"agent_id": <id>, "ip_address": <src>})` |
| Exploited host showing compromise | `propose_action(type="isolate_host", params={"agent_id": <id>})` (supervised) |
| Post-exploitation process | `propose_action(type="kill_process", params={"agent_id": <id>, "process_id": <pid>})` |

Patching, WAF virtual patches, disabling vulnerable services and compensating controls are human tasks —
`add_finding` with owner, due date (SLA/KEV) and verification method.

## 6. Remediation tracking and verification

- After patch windows, vuln-management re-runs `get_wazuh_vulnerabilities` per agent and watches for rule 23502
  (solved) to confirm the CVE is gone; `get_sca_policy_checks` confirms hardening controls pass (rule 19010, failed → passed).
- The responder verifies executed actions (`wazuh_check_blocked_ip`, `wazuh_check_agent_isolation`).
- Exceptions (no fix, business constraint) need an owner, compensating control and review date.

## 7. Records

- Vulnerability report (vuln-management `save_report(kind="vulnerability")`) with a priority table: CVE, KEV, EPSS,
  CVSS, hosts, SSVC, SLA/due date.
- Findings with `standard_refs`: `CISA-KEV`, `FIRST-EPSS`, `CISA-SSVC`, `NIST-800-53r5:RA-5`, `CIS-v8.1:7`, `ISO-27001:A.8.8`.
- Missing exploitation signatures → hand off to detection-engineer; management summary → reporting.

## Escalation

| Condition | Escalate to |
|---|---|
| KEV CVE on an internet-facing asset | Asset owner + change manager (emergency change), SOC lead |
| Exploitation confirmed | Incident swarm (investigation, response-planner), IR lead |
| Zero-day suspected | IR lead, vendor, threat-intel; consider isolating exposed assets |