Chapter 29 Quiz: Vulnerability Management¶

B — Consider the low EPSS score; the vulnerability is theoretically severe but has very low observed exploitation probability, allowing a risk-adjusted timeline

CVSS measures theoretical severity based on attack vector, complexity, and impact — not real-world exploitation likelihood. EPSS (Exploit Prediction Scoring System) provides a probability estimate of exploitation in the wild within 30 days. A high CVSS + low EPSS vulnerability may be deprioritized relative to a lower CVSS + high EPSS vulnerability actively being exploited. Risk-based programs combine both signals.

B — Discover → Triage → Remediate → Verify → Report

The standard vulnerability lifecycle is: Discover (identify assets and vulnerabilities via scanning/intelligence), Triage (assess severity, exploitability, and business context), Remediate (patch, mitigate, or accept with compensating control), Verify (rescan/retest to confirm closure), Report (communicate metrics and status to stakeholders). Scanning is part of Discovery.

B — The affected asset is classified as a critical business system with high Confidentiality, Integrity, and Availability requirements

The CVSS v3 Environmental Score allows organizations to adjust the base score based on the target asset's Modified Impact Metrics — specifically the Confidentiality, Integrity, and Availability (CIA) requirements of that asset in the organization's context. Critical assets with high CIA requirements will amplify the environmental score above the base. Temporal scores reflect vulnerability maturity and patch availability, not asset criticality.

B — Document a risk acceptance with compensating controls (network isolation, IDS signatures, enhanced monitoring) and set a formal exception with expiration date

When a patch cannot be applied within SLA, the VM program should require a formal exception with: documented business justification, risk acceptance by an appropriate owner, compensating controls to reduce exposure, and an expiration date that forces re-evaluation. Risk acceptance is not the same as ignoring the vulnerability. Downgrading the criticality classification (D) manipulates metrics rather than managing risk.

C — Tenable Nessus

Tenable Nessus is the leading vulnerability scanner built on the Nessus engine, available as Nessus Professional (commercial) and Nessus Essentials (free, limited to 16 IPs). OpenVAS is the open-source fork of the original Nessus codebase now maintained by Greenbone. Qualys is a separate cloud-based VM platform. Nexpose is Rapid7's scanner.

A — CVE identifies specific vulnerabilities; CWE classifies weakness types; CPE identifies affected software/hardware configurations

CVE (Common Vulnerabilities and Exposures): a unique identifier for a specific publicly known vulnerability (e.g., CVE-2021-44228 — Log4Shell). CWE (Common Weakness Enumeration): a category system for types of software weaknesses (e.g., CWE-79 — XSS, CWE-89 — SQL Injection). CPE (Common Platform Enumeration): a standardized naming scheme for software, hardware, and OS configurations used to match vulnerabilities to affected assets.

B — Focus on vulnerabilities in the CISA Known Exploited Vulnerabilities (KEV) catalog and those with EPSS > 0.5 on internet-facing critical assets

With limited resources, risk-based prioritization requires triaging by: active exploitation evidence (CISA KEV), exploitation probability (EPSS), asset exposure (internet-facing), and business criticality. CISA BOD 22-01 mandates KEV remediation for federal agencies, but KEV is widely adopted as a prioritization signal. Starting with medium-severity (B) is a common trap — high-probability exploits in lower CVSS findings often pose greater real-world risk.

B — Document the false positive finding, mark it as an exception with justification, and verify the patch status through alternative means (e.g., package manager query)

False positives must be formally documented with evidence and justification, not simply deleted. The scanner's exception/suppression workflow maintains an audit trail. Independent verification of patch status (e.g., querying the OS package manager) provides assurance that the patch is genuinely applied, protecting against actual misclassification.

B — Complete and accurate asset inventory ensures no assets are missed during scanning — unknown assets cannot be patched

VM programs are only as effective as their asset visibility. Assets not in inventory are not scanned; unscanned assets are unpatched; unpatched assets are attack surface. Asset inventory is the foundational dependency of VM: you cannot manage what you cannot see. This is often cited as the top VM program failure point.

B — Verification — independently confirms that remediation was effective rather than relying on the change team's self-report

Verification is the post-remediation rescan that independently confirms the vulnerability is closed. It is mandatory because: patches may be applied incorrectly, applied to the wrong host, or a different version may still be vulnerable. Self-reported closure by the patching team is not sufficient in a rigorous VM program. Verification provides the audit evidence that the SLA was met.