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