Table 1 — False Positive vs. False Negative (The Two Scan Errors)
| Property | False Positive | False Negative |
|---|---|---|
| Definition | Vulnerability reported that does not actually exist | Vulnerability exists but scanner did not detect it |
| Direction of error | Over-reporting (too many findings) | Under-reporting (too few findings) |
| Primary cause | Imprecise or outdated signature; patched system; configuration mismatch | Signature database out of date; no signature for the vulnerability yet exists |
| Immediate consequence | Wasted analyst time; unnecessary remediation work | Blind spot: organization believes system is safe when it is not |
| Security consequence | Low — no real vulnerability is missed | High — real vulnerability remains unpatched and unmonitored |
| Primary defense | Tune scanner; validate findings before acting; keep signatures current | Update signatures before every scan; supplement with threat intelligence |
| Exam trap | A low-severity real finding is NOT a false positive — it is a real finding at low priority | An unexpectedly clean report may indicate outdated signatures, not a secure environment |
| Which is more dangerous? | Less dangerous — creates work but not breach risk | More dangerous — leaves real risk unrecognized and unaddressed |
Table 2 — CVSS Score Ranges and Version Differences
| Score Range | Severity Label | Typical SLA | Example Characteristics |
|---|---|---|---|
| 9.0 – 10.0 | Critical | 24–72 hours | Network-exploitable, no authentication, full system compromise |
| 7.0 – 8.9 | High | 7–14 days | Network-exploitable, some complexity, significant data exposure |
| 4.0 – 6.9 | Medium | 30 days | Limited access vector, authentication required, partial impact |
| 0.1 – 3.9 | Low | Next maintenance window | Local access only, difficult to exploit, minimal impact |
| 0.0 | None / Informational | Scheduled review | No direct security impact; configuration note or best practice |
| CVSS Version | Status | Key Difference |
|---|---|---|
| CVSS 2.0 | Legacy; still appears in older reports | Older methodology; generally produces lower scores than 3.x for the same vulnerability |
| CVSS 3.x | Current industry standard | Adds scope metric; distinguishes vulnerable component from impacted component; more granular scoring |
| Same vulnerability may score differently under each version. Always note which version a score is from before comparing findings across systems or time periods. | ||
Table 3 — CVE Reference Databases and Their Roles
| Database | Maintained By | Primary Use |
|---|---|---|
| CVE List (cve.mitre.org/cve) | MITRE | Authoritative source for CVE numbering and identifiers; each entry uniquely names one vulnerability |
| National Vulnerability Database (nvd.nist.gov) | NIST | Adds CVSS scores, severity ratings, enhanced search, and links to vendor patches; synchronized with CVE list |
| Microsoft Security Response Center | Microsoft | Vendor-specific remediation details; patch download links; Windows/Office/Azure-specific guidance |
| Vendor Security Portals | Individual vendors | Platform-specific advisories, patches, and workarounds; more actionable than generic CVE entry for that vendor's products |
| CVSS Calculator (in NVD) | NIST / FIRST | Compute scores for newly disclosed vulnerabilities before official scoring is published |
Table 4 — Vulnerability Classification by Scan Type
| Scan Type | Target Environment | Common Findings | Remediation Routing |
|---|---|---|---|
| Application scan | Desktop software, mobile apps | Outdated libraries with CVEs, insecure default configurations, weak cryptographic implementations, insecure data storage (mobile) | IT operations team; software vendor update cycle; mobile app security team |
| Web application scan | Web servers, web-based software | SQL injection, cross-site scripting (XSS), authentication flaws, insecure session management, misconfigured access controls | Development team; immediate priority because internet-facing |
| Network scan | Infrastructure devices, communication paths | Open ports with vulnerable services, misconfigured firewalls, unpatched routers/switches/VPN concentrators, unauthorized devices | Network operations team; infrastructure security team |
| Scan effectiveness for all three types depends on signature currency — a scanner without current signatures will miss vulnerabilities regardless of scan type. | |||
Table 5 — Exposure Factor Examples
| Exposure Factor | Business Meaning | Example Vulnerability Scenario | SLE Calculation Example |
|---|---|---|---|
| 100% | Total loss of asset or service | Buffer overflow that completely disables the system or destroys all data; ransomware that encrypts and renders all files inaccessible | Asset value $500,000 × 100% = SLE $500,000 |
| 50% | Partial loss of service capacity or value | DDoS vulnerability that throttles but does not eliminate a service; degraded availability affecting half of users | Asset value $500,000 × 50% = SLE $250,000 |
| 10% | Minor loss affecting small subset of functionality | Vulnerability affecting a rarely-used feature or a small segment of the user base | Asset value $500,000 × 10% = SLE $50,000 |
| SLE formula: Single Loss Expectancy = Asset Value × Exposure Factor | Higher exposure factor = more business harm per exploitation event = higher remediation priority even when CVSS scores are similar | |||
Table 6 — Environmental Variable Prioritization Matrix
| Environmental Variable | Higher Priority Condition | Lower Priority Condition | Why It Matters |
|---|---|---|---|
| Network exposure | Internet-facing; directly reachable by external attackers | Internal-only; isolated test lab; air-gapped | Attackers can only exploit what they can reach; internet-facing systems face the entire threat landscape |
| User base | External customers; large number of users affected | Internal employees only; small number of users | Larger user base = greater breach impact; external users = reputational and legal risk |
| Revenue dependency | System downtime has direct, measurable financial consequences | Supporting system; downtime inconvenient but no direct revenue impact | Revenue impact translates vulnerability risk directly to financial risk for the organization |
| Exploitability | Public exploit code exists and is actively used in the wild | Theoretical weakness; no public exploit; requires sophisticated attack chain | Availability of exploit code dramatically lowers attacker skill threshold |
| Organizational type | Healthcare, utilities, financial services, government (critical infrastructure) | General IT; software company; non-critical operations | Critical infrastructure faces both elevated consequences and heightened regulatory requirements |