vulnerability-prioritization v1.1A

Immutable. This exact content never changes and is served at /api/v1/blob/93016af6b9b5a819.

---
name: vulnerability-prioritization
description: Prioritize Wazuh vulnerability-detector findings with CISA KEV, FIRST EPSS, CVSS and asset context into CISA SSVC decisions and remediation SLAs; use for vulnerability sweeps, CVE alerts or patch-priority questions.
allowed-tools: get_wazuh_vulnerabilities get_wazuh_critical_vulnerabilities get_wazuh_vulnerability_summary get_wazuh_agents get_agent_ports get_sca_policy_checks get_wazuh_alerts search_external_context get_case create_case update_case add_finding save_report
metadata:
  category: vulnerability
  display_name: Vulnerability Prioritization
  standards: [cisa-kev, first-epss, cisa-ssvc, nist-csf-2, nist-800-53r5, cis-v8-1]
  version: "1.1"
---
# Vulnerability Prioritization

CVSS alone ranks too many things "critical". Prioritize by exploitation evidence, then
likelihood, then impact in *this* environment. Aligns with NIST CSF 2.0 ID.RA, NIST SP
800-53r5 RA-5 / SI-2, CIS Controls v8.1 Control 7 (Continuous Vulnerability Management),
and NIST SP 800-40r4 (enterprise patch management as preventive maintenance).

## What Wazuh gives you

The vulnerability detector matches the syscollector package inventory against CVE feeds
and raises one alert per CVE and package, with fields under `data.vulnerability.*`:
`cve`, `severity`, `cvss.cvss3.base_score` (or `score.base`), `package.name`,
`package.version`, `status` (Active / Solved), `published`, `reference`.

| Rule | Level | Meaning |
|---|---|---|
| rule 23503 | 5 | Active, severity Low |
| rule 23504 | 7 | Active, severity Medium or Untriaged |
| rule 23505 | 10 | Active, severity High |
| rule 23506 | 13 | Active, severity Critical |
| rule 23502 | 3 | CVE no longer affects the package (solved, e.g. after an upgrade) |
| rule 23507 | 3 | vulnerabilities cleared for the agent |

So the alert level is just the vendor severity. It says nothing about exploitation or
exposure, and that's what this skill adds. rules 23502 and 23507 are good remediation
evidence: use them to confirm a fix instead of re-scanning. Detection lags the package
scan interval, so note data freshness.

For configuration weaknesses on the same hosts (open services, weak SSH settings), load
`wazuh-sca-hardening`. SCA failures often turn a Track item into Attend.

## Data gathering

1. `get_wazuh_vulnerability_summary` — counts by severity and top CVEs.
2. `get_wazuh_critical_vulnerabilities` — the critical/high set with affected agents.
3. `get_wazuh_vulnerabilities(agent_id=...)` — per-host detail when scoping.
4. `get_wazuh_vulnerabilities(agent_id=..., severity="critical")` per host for scoping
   (`vulnerability_assessment` on the MCP server is a prompt template, not a callable tool).
   `get_agent_ports(agent_id)` shows whether the vulnerable service is actually
   listening. That's your Exposure input.
5. For exploitation data use `search_external_context` with the **CVE id only**:
   "CVE-XXXX-YYYY CISA KEV", "CVE-XXXX-YYYY EPSS". Never send hostnames.

## Decision order

1. **CISA KEV** — listed in the Known Exploited Vulnerabilities catalog? Exploitation
   in the wild is confirmed. (KEV entries also carry a federal due date.)
2. **FIRST EPSS** — probability of exploitation activity in the next 30 days (0–1) and
   percentile. EPSS ≥ 0.1 (or ≥ 90th percentile) is a strong signal.
3. **CVSS** (v4.0 where available, else v3.1) base score, adjusted for environment:
   internet exposure, compensating controls, asset criticality.

## SSVC decision (CISA Deployer tree, simplified)

Decision points: **Exploitation** (none / public PoC / active), **Exposure** (small /
controlled / open — i.e. internet-facing), **Automatable** (yes/no — can an attacker
reliably exploit at scale), **Mission & Well-being impact** (low / medium / high).

| Outcome | Typical conditions | Meaning |
|---|---|---|
| **Act** | active exploitation (KEV) + open exposure or high impact | remediate immediately, escalate |
| **Attend** | active exploitation with controlled exposure, or PoC + open exposure + automatable | remediate sooner than standard; supervisor attention |
| **Track\*** | PoC or high EPSS but limited exposure/impact | track closely; standard timeline, re-check often |
| **Track** | no known exploitation, low exposure | standard patch cycle |

## Remediation SLAs (org defaults — adjust to policy)

| SSVC | Target |
|---|---|
| Act | 48 hours (or KEV due date if sooner), mitigate same day if patch unavailable |
| Attend | 7 days |
| Track* | 30 days |
| Track | next regular maintenance cycle (≤ 90 days) |

Mitigations when patching is not possible: disable the vulnerable service, restrict
exposure (firewall / host_deny via a human-approved plan), virtual patching, increased
monitoring (hand off to detection-engineer).

## Output table

```
| CVE | Package | Hosts | KEV | EPSS (pct) | CVSS | Exposure | SSVC | SLA | Action |
```

Group by CVE, list affected host counts, top 25 rows. Note data freshness (last
vulnerability scan time per agent).

## Output

- `save_report(kind="vulnerability", title, body_md)` with the table and summary for
  sweeps; for a spike tied to a case, `add_finding` titled `Vulnerability priorities`.
- `create_case` for any **Act** item on an internet-facing or critical asset (severity
  high/critical), with CVE, hosts and recommended mitigation.
- standard_refs: `CISA-KEV`, `FIRST-EPSS`, `CISA-SSVC`, `NIST-800-53r5:RA-5`,
  `NIST-800-53r5:SI-2`, `CIS-v8.1:7`.