Analyzing Vulnerabilities -- Tricks

Trick 1 False Positive ≠ Low Severity — These Are Not the Same Thing

The exam specifically tests whether you can distinguish between a false positive and a low-severity real finding. These are fundamentally different, and confusing them is a tested mistake.

False positive: The vulnerability does NOT exist on the system. Investigation reveals the scanner matched a signature but the system is not actually vulnerable. The correct action: document the investigation, mark it as a false positive, and remove it from the active remediation queue. It is not a real risk.

Low-severity finding: The vulnerability DOES exist on the system. It is real, confirmed, and present — it is just not urgent. The correct action: keep it in the tracking system, schedule remediation at the next appropriate maintenance window, and monitor it. It is a real risk that happens to be low priority.

Why this matters on the exam: A question may describe a finding that "does not require immediate action" and ask how to classify it. The answer depends entirely on whether the vulnerability is real or not — not on whether it is urgent. Closing a low-severity real finding as a false positive removes a genuine vulnerability from oversight.

Rule: False positive = the vulnerability is not real. Low severity = the vulnerability is real but not urgent. Never close a real vulnerability as a false positive.

Trick 2 False Negatives Are More Dangerous Than False Positives — Know Why

The exam asks which type of scan error is more dangerous. The answer is always false negative, and the exam expects you to know why.

False positive consequence: Analyst investigates a non-existent vulnerability, documents it, closes it. Time is wasted. No breach occurs. The real security posture is unaffected.

False negative consequence: A real vulnerability exists. The scan did not detect it. The organization believes the system is clean. They do not patch. They do not monitor for exploitation. They do not include the system in incident response procedures for that vulnerability. Meanwhile, attackers may know about the vulnerability and probe for it. The false negative is an invisible blind spot that a false positive never creates.

The root cause to memorize: False negatives are caused by outdated vulnerability signatures. If the scanner's database does not have a signature for a vulnerability, it cannot detect it. The primary control: update signatures before every scan.

Exam trigger phrases for false negative questions: "unexpectedly clean report," "newly disclosed vulnerability," "signatures not updated," "organization believes it is safe but is not."

Rule: False positive = wasted time. False negative = invisible breach risk. False negative is always more dangerous. Cure: update signatures before every scan.

Trick 3 CVSS Version Matters — 2.0 and 3.x Can Score the Same Vulnerability Differently

The exam tests awareness that a single CVE may have two different CVSS scores in a report — one from CVSS 2.0 and one from CVSS 3.x. This is not a discrepancy or error; it is expected because the two versions use different methodologies.

What the exam expects you to know:

CVSS 2.0 is the legacy version; still present in older databases and some scanners
CVSS 3.x is the current standard; more detailed scoring that often produces higher scores for the same vulnerability
When two scores appear, note the version — do not assume the scores are interchangeable
Use the CVSS 3.x score for prioritization when both are available
The NVD at nvd.nist.gov publishes both versions and labels which is which

The trap answer: A question may present a scenario where an organization is using a 2.0 score of 6.5 (Medium) when the 3.x score is 9.1 (Critical) and ask what went wrong. The answer is: they used the wrong CVSS version and deprioritized a Critical finding as Medium.

Rule: CVSS 3.x is current. CVSS 2.0 is legacy. Same CVE, different scores. Always identify the version. Use 3.x for prioritization.

Trick 4 Risk Tolerance Is Not Fixed — It Changes With Severity, Exposure, and Organizational Context

A common exam mistake is treating risk tolerance as a single organizational policy that applies the same way to every finding. Risk tolerance is context-dependent and adjusts based on the specific vulnerability's characteristics.

Factors that lower risk tolerance (demand faster patching, less testing time acceptable):

High CVSS score (especially Critical 9.0+)
Internet-facing system affected
Public exploit code exists or active exploitation confirmed in the wild
Critical infrastructure organization (healthcare, utilities, financial, government)
System directly tied to revenue or public safety

Factors that raise risk tolerance (allow standard or extended test cycle):

Low CVSS score
Isolated test environment; no network connectivity to production
No public exploit code; theoretical vulnerability only
Internal-only system with small, technical user base

Standard tiered SLAs (memorize these for the exam): Critical: 24–72 hours — High: 7–14 days — Medium: 30 days — Low: next scheduled maintenance window.

The patching dilemma (exam-tested): Patch immediately → minimizes exposure window but skips testing, introducing operational risk. Test thoroughly → minimizes operational risk but extends vulnerability window. Risk tolerance determines how this trade-off resolves for each specific finding.

Rule: Critical + internet-facing + active exploitation = compress testing. Low + isolated + theoretical = wait for maintenance window. Same org, different tolerance per finding.

Practice Scenarios

Scenario A: A security analyst reviews a vulnerability report and finds a finding rated CVSS 3.5 (Low). She checks the associated CVE in the NVD and confirms the vulnerability is real — it is a minor information disclosure in an internal tool that reveals non-sensitive version information. Her manager asks her to mark it as a false positive and close it so the report looks cleaner. Should she do this, and why or why not?

Answer: No. The vulnerability is real and confirmed — it should not be classified as a false positive. A false positive is a finding that does not exist on the system. This finding exists; it is simply low severity. Marking a real finding as a false positive to clean up the report removes a genuine vulnerability from the tracking system. The correct action: keep the finding in the system, classify it as Low severity, and schedule it for the next regular maintenance window. If the manager believes the finding is not a security concern, the appropriate resolution is to document a risk acceptance decision — not to misclassify it as a false positive.

Scenario B: An organization runs a vulnerability scan every Monday. The most recent scan (Monday) showed no critical findings. On Wednesday, a threat intelligence alert confirms active exploitation of a critical zero-day in a web framework the organization uses. By Thursday, the security team checks Monday's report again and confirms it shows no findings for that framework. A senior engineer says "We're fine — it's not in the report." Is the senior engineer's conclusion correct? What should the team actually do?

Answer: The senior engineer's conclusion is incorrect. Monday's scan reflects Monday's signature database. The zero-day was disclosed on Wednesday, after the scan — meaning the scanner had no signature for it and could not have detected it. The clean report for that framework is a false negative: not because the system is safe, but because the scanner lacked the signature to detect the vulnerability at scan time. The team should: (1) update scanner signatures immediately, (2) rescan the affected systems with current signatures, (3) check threat intelligence for indicators of compromise, and (4) if the framework is confirmed present, treat it as a CVSS-appropriate emergency remediation rather than waiting for next Monday's scheduled scan.

Scenario C: A vulnerability scan identifies the same CVE on two systems. System A is an internet-facing customer payment portal with 50,000 daily transactions and a CVSS 3.x score of 8.5. System B is a development workstation in an isolated lab with no production network access and the same CVSS 3.x score of 8.5. The security team has capacity to patch one system this week. Which should they patch first, and what factors justify the decision beyond the equal CVSS scores?

Answer: System A (the payment portal) should be patched first. The CVSS score is identical, so the decision must be made on environmental variables and exposure factor: (1) Network exposure — System A is internet-facing and reachable by any external attacker; System B is isolated with no external connectivity. (2) User base and revenue impact — System A processes 50,000 daily customer transactions; exploitation could expose customer payment data and interrupt revenue-generating operations. System B's exploitation would affect only developers in an isolated environment. (3) Exposure factor — exploitation of System A could cause complete disruption of customer-facing operations (high exposure factor); exploitation of System B causes minimal business impact. The CVSS score captures technical severity. Environmental variables capture business risk. Both are required inputs to prioritization, and in this case they both point to System A.

Analyzing Vulnerabilities — Exam Tricks