What is a false positive in vulnerability scanning?
A scanner finding that investigation reveals does NOT actually exist on the target system. The scanner flagged a vulnerability, but the system is not genuinely vulnerable — the patch was already applied, the exploitable configuration does not exist, or the signature is imprecise.
What is a false negative in vulnerability scanning, and why is it more dangerous than a false positive?
A false negative is a vulnerability that genuinely exists but the scanner did not detect it. More dangerous because it creates a blind spot: the organization believes the system is safe, does not patch, and does not monitor for exploitation. A false positive wastes time; a false negative leaves real risk invisible.
A scanner identifies a real vulnerability but rates it Low severity. Is this a false positive?
No. A low-severity real finding is NOT a false positive. False positive = the vulnerability does not exist. Low severity = the vulnerability exists but is not urgent. Calling a low-severity real finding a false positive removes a genuine risk from the tracking system.
What is the primary cause of false negatives, and what is the primary defense?
Primary cause: the scanner's signature database does not contain a signature for the vulnerability — either because it was disclosed after the last update, or no signature has been written yet. Primary defense: update signatures to the latest available database before every scan.
What is CVSS, what is its score range, and where are scores published?
Common Vulnerability Scoring System — the industry standard for quantifying vulnerability severity. Score range: 0 to 10, where 10 is most critical. Scores are published in the National Vulnerability Database (NVD) at nvd.nist.gov. Factors include access vector, complexity, authentication, and CIA impact.
Why do CVSS 2.0 and CVSS 3.x scores for the same vulnerability sometimes differ significantly?
The two versions use different scoring methodologies. CVSS 3.x adds a scope metric and distinguishes the vulnerable component from the impacted component, generally producing higher scores for the same underlying vulnerability. Always note the CVSS version when comparing scores across reports or databases.
What is a CVE, who maintains the CVE list, and what is the identifier format?
Common Vulnerabilities and Exposures — standardized identifiers for publicly known security vulnerabilities. Maintained by MITRE at cve.mitre.org/cve. Format: CVE-YEAR-NUMBER (e.g., CVE-2024-12345). Enables consistent cross-referencing across scanners, databases, vendor advisories, and patches.
What is the exposure factor and how is it used in the SLE formula?
Exposure factor = percentage of asset value or service capacity lost if the vulnerability is exploited (0–100%). Used in: SLE = Asset Value × Exposure Factor. A 100% exposure factor means total loss; 50% means partial loss. Higher exposure factor = more business harm per exploitation = higher remediation priority, even if CVSS scores are equal.
Name four environmental variables that can change the priority of a vulnerability beyond its CVSS score.
1. Network exposure — internet-facing vs. internal vs. isolated lab. 2. User base — external customers vs. internal employees; number of users. 3. Revenue dependency — whether downtime causes direct financial loss. 4. Exploitability — whether public exploit code exists and is actively used in the wild.
What is risk tolerance in vulnerability management, and what is the core patching dilemma it reflects?
Risk tolerance = the level of vulnerability exposure an organization accepts during the window between discovery and completed remediation. Core dilemma: patch immediately (minimize exposure window, skip full testing, accept operational risk) vs. test thoroughly (minimize operational risk, extend vulnerability exposure window). Tiered SLAs: Critical 24–72h, High 7–14d, Medium 30d, Low next window.