Key Takeaways: Vulnerability Management

A one-page reference. Reread this before an exam or before moving on. Dense by design.

The core vocabulary (memorize cold)

Term One-line definition
Vulnerability management The continuous, closed-loop process of finding, ranking, fixing, and verifying weaknesses — and reporting on it. Risk reduction under permanent scarcity, not reaching zero.
Vulnerability scanner A tool that checks assets against a database of known weaknesses. Authenticated = logs in, reads exact versions/config (accurate, deep). Unauthenticated = probes from outside (sees true external exposure, but guesses).
CVE Common Vulnerabilities and Exposures — a unique public identifier for one disclosed flaw (e.g., CVE-2021-44228). A name, not a score.
CVSS Common Vulnerability Scoring System (FIRST) — intrinsic severity, 0.0–10.0. Low/Med/High/Critical. Severity, not priority.
EPSS Exploit Prediction Scoring System (FIRST) — probability of exploitation in the next 30 days, 0–1. The likelihood signal.
KEV Known Exploited Vulnerabilities catalog (CISA) — a fact that a vuln is being actively exploited right now. The strongest likelihood signal.
Risk-based prioritization Ranking remediation by real risk = CVSS × EPSS/KEV × asset context, not by CVSS alone.
Patch SLA A policy-backed maximum time to remediate, tiered by risk. Clock starts at discovery.
Exception (risk acceptance) A documented, time-bound, approved deviation from an SLA, with justification, compensating control, owner, and expiry.
Attack surface management Continuous discovery/inventory of exposed (esp. internet-facing) assets — feeds the Discover stage.
SBOM Software bill of materials — an inventory of a system's components/dependencies. Introduced here; full treatment Chapter 29. Answers "where do we run library X?"

The lifecycle (a loop, never a line)

DISCOVER → ASSESS → PRIORITIZE → REMEDIATE → VERIFY → REPORT → (back to DISCOVER)
(assets/   (scan)   (risk-based) (patch /    (re-scan, (metrics,
 attack             order)       mitigate /  confirm   trends,
 surface)                        accept)     closed)   SLAs)
  • Remediate has THREE options: patch (fix), mitigate (segment/WAF/restrict/disable — reduce risk without the fix), accept (governed exception). Beginners forget the last two.
  • "Fixed" is only real after VERIFY (re-scan confirms gone). "Deployed" ≠ "remediated."
  • Vuln management ≠ patch management (Ch.11). Patch mgmt = how to deploy an update (one tool in Remediate). Vuln mgmt = which patches matter, how fast, what to do without one, and how to prove the loop works.

Prioritization: CVSS vs. EPSS vs. KEV (the exam loves this)

Signal Answers Type Scale
CVSS How bad if exploited? Intrinsic severity 0.0–10.0
EPSS How likely to be exploited (30 days)? Predicted probability 0.0–1.0
KEV Is it being exploited right now? Fact (catalog) yes / no
Asset context How exposed/valuable is my asset? Your environment judgment

The one rule: Risk ≈ f(CVSS) × g(EPSS, KEV) × h(asset exposure & value). CVSS alone is half of one factor. KEV-listed + exposed → jumps the queue. A CVSS 6.5 KEV-listed internet-facing flaw beats a CVSS 10.0 nobody is exploiting on an isolated box.

Prioritization decision aid

If… Then priority
On KEV (actively exploited) and reachable/valuable asset P1 — Emergency (mitigate now)
EPSS ≥ ~0.5 (likely exploited soon) on exposed asset P1/P2
CVSS ≥ 9 and EPSS non-trivial, exposed P2 — Critical
High CVSS but EPSS ~0, not KEV, low exposure P3/P4 — scheduled/routine (don't emergency it)
Same CVE on internal/segmented vs. internet-facing Internal = lower priority (context breaks the tie)

Patch SLAs (risk-based, not CVSS-based)

Tier Internet-facing / KEV Internal
Emergency (KEV + exposed) 24–72 h 7 d
Critical 7 d 14 d
High 14 d 30 d
Medium 30 d 60 d
Low 90 d 90 d / accept
  • Clock starts at DISCOVERY (so discovery cadence + KEV monitoring matter as much as the patch step).
  • Set tighter than the compliance floor (PCI-DSS etc. set a minimum; compliance is the floor, not the ceiling).

The exception process (where programs quietly die)

A legitimate exception needs ALL five:

Element Why
Real justification Not "too busy" — a true blocker (patch breaks X; vendor fix due Q2).
Compensating control Genuinely reduces risk now (segment, WAF, restrict, disable). No control = unaddressed risk in costume.
Accountable owner A named business owner accepts the risk, at seniority proportional to it.
Expiry + mandatory re-review The anti-drift control. No exception is permanent.
Risk-proportional approval Bigger risk → higher signature (KEV-on-CDE risk ≠ manager-level).

The permanent "temporary" exception (organizational drift) is the #1 failure: silent renewal, lost owner, decommissioned compensating control. It is how known, exploited vulns live for years → the most common breach.

The vulnerability that never gets fixed (§23.5)

Why it persists Manage it by
No patch (EOL/unsupported) Mitigate (segment, WAF, restrict, disable feature)
Patch breaks something critical Monitor intensely (SIEM/detection — assume prevention fails)
Un-patchable black box (vendor/medical/OT) Force re-decision (expiring exception → senior owner)
Organizational drift (← deadliest: unowned) Track openly as accepted risk in the register
Unfunded legacy debt (combine all of the above)

Reporting: report the loop, not the inventory

  • Useless: "41,000 open vulnerabilities" (rises with better discovery; not risk; not actionable).
  • Truthful metrics: MTTR by tier, SLA-compliance rate, open KEV exposure, backlog aging, exception health (expired-but-active), remediation-vs-discovery rate, scan coverage.
  • By audience: operational = prioritized worklist; tactical = MTTR/SLA/KEV trends; board = a few trend lines (KEV exposure ↓, critical-SLA compliance, top accepted risks w/ owners). Never a raw count.

Certification crosswalk

Concept CompTIA Security+ (ISC)² CISSP domain
Vuln-management lifecycle 4.0 Security Operations Security Operations
Scanning (auth/unauth, credentialed) 4.0 Security Operations Security Assessment & Testing
CVE / CVSS / EPSS / KEV, prioritization 2.0 Threats, Vulns & Mitigations; 4.0 Security Assessment & Testing; Risk
Patch SLAs / patch management 4.0 Security Operations Security Operations
Exception / risk acceptance 5.0 Governance, Risk & Compliance Security & Risk Management
Attack surface management, SBOM 2.0; 4.0 Asset Security; Security Operations

Project additions this chapter

  • Meridian program: vulnerability-management policy + risk-based patch SLAs + governed exception process + program metrics.
  • bluekit toolkit: vulnmgmt.py — priority(cvss, kev, epss) (KEV/high-EPSS beats raw CVSS) and patch_sla(sev) (days-to-remediate by tier).

Common pitfalls

  • Prioritizing by CVSS ("patch all Criticals first") — ignores exploitation likelihood and asset context.
  • Trusting a clean unauthenticated scan — blind to missing OS patches and local config.
  • Treating "internet-facing" as "has a public IP" — systems that ingest untrusted data are exposed too.
  • Skipping Verify — "ticket closed" ≠ "re-scan confirms gone"; hosts hide second copies.
  • The permanent "temporary" exception — no expiry, no re-review, lost owner, dead compensating control.
  • Causing an outage by scanning fragile/OT assets — throttle, schedule, go passive.
  • Reporting a raw finding count that hides the dangerous tail (open KEV, stale exceptions, aging backlog).
  • Believing compliance = secure — Northgate passed audits and got breached through a known, exploited flaw.