gensecaihq/wazuh-autopilot/ir-playbook-vulnerability-spike

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

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".

1. 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?

1. 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).

1. 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)

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)

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