Explain various activities associated with vulnerability management

Vulnerability management is the continuous cycle of finding, evaluating, remediating, and verifying security weaknesses. It’s not just scanning — it’s the full lifecycle from discovery to closure.

Vulnerability Identification

Scanning Types

• Credentialed (authenticated): Scanner logs into systems with valid credentials. Sees installed software, configurations, missing patches. More accurate, fewer false positives.
• Non-credentialed (unauthenticated): Scanner probes from the network without credentials. Only sees what’s externally visible. Faster but less thorough.
• Agent-based: Lightweight agent installed on endpoints reports vulnerabilities continuously. Works for devices that aren’t always on the network (laptops, remote workers).
• Agentless: Scanner-initiated from a central point. Simpler to deploy but requires network access to targets.

Active vs. Passive

• Active scanning: Sends probes to targets. Can be disruptive to sensitive systems (ICS/SCADA).
• Passive scanning: Monitors network traffic to identify vulnerabilities. Non-disruptive but less thorough.

Scanning Cadence

• External-facing systems: Weekly or continuous
• Internal systems: Monthly minimum
• After significant changes: Immediately (new deployments, major patches, configuration changes)
• Compliance-driven: PCI-DSS requires quarterly ASV scans for external systems

Vulnerability Analysis

CVSS (Common Vulnerability Scoring System)

Standard severity rating from 0.0 to 10.0:

• Critical: 9.0–10.0
• High: 7.0–8.9
• Medium: 4.0–6.9
• Low: 0.1–3.9

CVSS includes three metric groups:

• Base: Inherent characteristics (attack vector, complexity, impact)
• Temporal: Factors that change over time (exploit maturity, patch availability)
• Environmental: Organization-specific context (asset criticality, existing mitigations)

EPSS (Exploit Prediction Scoring System)

Modern supplement to CVSS that answers a different question:

• CVSS answers: “How severe is this vulnerability?” (inherent characteristics)
• EPSS answers: “How likely is this vulnerability to be exploited in the next 30 days?” (real-world probability)

EPSS uses machine learning on historical exploitation data to produce a probability score (0-1). A CVSS 9.8 with EPSS 0.01 means it’s critical in theory but nobody’s actually exploiting it. A CVSS 6.5 with EPSS 0.95 means attackers are actively going after it despite the moderate CVSS.

Prioritization strategy: Combine CVSS (severity) + EPSS (likelihood) + asset criticality (impact) for risk-based prioritization that reflects real-world threat landscape.

Beyond CVSS

CVSS alone is insufficient for prioritization. Additional context:

• Exploitability: Is there a known exploit in the wild? (CISA KEV catalog)
• Asset criticality: A medium vulnerability on your internet-facing auth server matters more than a critical vulnerability on an air-gapped test machine
• Exposure: Is the vulnerable system internet-facing, internal only, or segmented?
• Business context: What’s the impact if this system is compromised?

False Positives and False Negatives

• False positive: Scanner reports a vulnerability that doesn’t actually exist. Waste of remediation effort.
• False negative: Scanner misses a real vulnerability. Dangerous.
• Validation: verify scanner findings manually or with a second tool before escalating

Application Security Testing

Covered briefly in 4.1, but CompTIA tests the distinction here in the vulnerability management context:

Method	When	What It Finds	Limitations
SAST (Static)	During development, on source code	Injection flaws, hardcoded secrets, insecure patterns, logic errors	High false positive rate. Can’t find runtime issues.
DAST (Dynamic)	Against running application	Runtime vulnerabilities, auth issues, config errors, injection from the outside	Can’t see source code. Slower. May miss logic bugs.
IAST (Interactive)	During testing with instrumented runtime	Combines SAST + DAST insights with runtime context	Requires instrumentation. More complex setup.
SCA (Software Composition Analysis)	On dependency manifests / SBOMs	Known CVEs in third-party libraries and frameworks	Only finds known vulnerabilities. Can’t assess custom code.

When to use which: SAST early in development (shift-left), DAST in staging/pre-production, SCA continuously (dependencies change constantly), IAST during QA testing cycles.

Threat Intelligence Feeds

External data sources that inform vulnerability prioritization and detection:

Key Sources

• CVE databases: NIST NVD (National Vulnerability Database) — the canonical source for vulnerability details and CVSS scores
• CISA KEV (Known Exploited Vulnerabilities): Authoritative list of vulnerabilities being actively exploited. Federal agencies must patch KEV entries within specified timelines. Essential for prioritization.
• Vendor advisories: Microsoft Patch Tuesday, Apple security updates, Cisco security advisories
• ISAC feeds: Industry-specific threat intelligence (FS-ISAC for finance, H-ISAC for healthcare)
• Commercial feeds: Recorded Future, Mandiant, CrowdStrike threat intelligence
• Open source: AlienVault OTX, Abuse.ch, VirusTotal

Integration

• Feed IOCs (IPs, domains, hashes) into SIEM, EDR, firewall for automated blocking
• Cross-reference scan results with KEV to identify actively exploited vulnerabilities in your environment
• Use threat intel to inform scanning priorities — if a new campaign targets your industry, scan for those specific CVEs immediately

Bug Bounty Programs

In the vulnerability management context (not just the audit context from 5.5):

• Supplements internal scanning and pentesting with crowd-sourced discovery
• Researchers find vulnerability classes that automated tools miss (business logic flaws, chained exploits)
• Continuous — unlike annual pentests, bounty programs run year-round
• Vulnerability Disclosure Program (VDP): Similar to bug bounty but without monetary rewards. Provides a channel for researchers to report findings safely.
• Every organization should have at minimum a VDP with a security.txt file at /.well-known/security.txt

Cyber Insurance

Listed in the CompTIA blueprint but often overlooked:

• What it covers: Breach response costs (forensics, notification, credit monitoring), legal fees, regulatory fines (where insurable), business interruption, ransomware payments (controversial)
• What it doesn’t cover: Reputational damage, loss of competitive advantage, pre-existing known vulnerabilities
• Underwriting requirements: Insurers increasingly require MFA, EDR, backup verification, IR plan, and vulnerability management program before issuing a policy
• Connection to vulnerability management: Poor vulnerability management (unpatched systems, no scanning) can void coverage or increase premiums. Insurers may audit.

Exceptions and Exemptions Process

Formal workflow for when vulnerabilities can’t be remediated within SLA:

1. Request: System owner submits exception request with business justification
2. Risk assessment: Security team evaluates the risk of leaving the vulnerability unpatched
3. Compensating controls: Identify and implement alternative protections (segmentation, enhanced monitoring, WAF rules)
4. Approval: Security leadership (or risk committee for critical exceptions) approves with conditions
5. Documentation: Exception recorded in risk register with owner, justification, compensating controls, and expiration date
6. Review: Exceptions reviewed on schedule (30/60/90 days). Extended, remediated, or escalated.

Key point: An exception without compensating controls is just risk acceptance — and that requires a different approval level.

Vulnerability Response

Remediation

Fix the vulnerability directly.

• Patching: Apply vendor-provided update. The most common and preferred response.
• Configuration change: Disable a vulnerable feature, restrict access, tighten permissions.
• Code fix: For custom applications, fix the vulnerable code.

Mitigation

Reduce the risk without fully eliminating the vulnerability.

• Network segmentation to limit exposure
• WAF rules to block known exploit patterns
• Enhanced monitoring on the vulnerable system
• Used when patching isn’t immediately possible (legacy systems, change freeze)

Acceptance

Document the decision to accept the risk without remediation.

• Must include business justification, risk owner sign-off, and compensating controls
• Not a permanent state — review regularly

Exceptions

Formal process for granting temporary or permanent exceptions to patching requirements.

• Time-limited, documented, approved by security leadership
• Compensating controls required

Patch Management

Process

1. Identification: Vendor releases patch or advisory
2. Evaluation: Assess relevance, severity, and applicability to your environment
3. Testing: Deploy to staging/test environment. Verify no regressions.
4. Deployment: Roll out to production during maintenance window
5. Validation: Verify the patch resolved the vulnerability. Re-scan.
6. Documentation: Update patch records, close vulnerability tickets

Prioritization

Not all patches are equal. Prioritize by:

1. Actively exploited vulnerabilities (CISA KEV)
2. Internet-facing systems
3. Critical CVSS with available exploits
4. High-value/critical business systems
5. Everything else

Challenges

• Legacy systems that can’t be patched (EOL software, ICS/SCADA)
• Application compatibility breaking after patches
• Patch availability delays from vendors
• Downtime requirements for patching critical systems

Vulnerability Reporting and Metrics

Key Metrics

• Mean Time to Remediate (MTTR): Average time from discovery to fix. Lower is better.
• Vulnerability density: Vulnerabilities per asset/system. Identifies problem areas.
• Patch compliance rate: Percentage of systems at current patch level
• Aging vulnerabilities: Count of vulnerabilities open beyond SLA (30/60/90 days)
• Scan coverage: Percentage of assets scanned. Gaps = blind spots.

Reporting

• Dashboard for security operations (real-time)
• Executive summaries for leadership (monthly/quarterly)
• Compliance reports for auditors (as required)

Offensive Context

Vulnerability management from the attacker’s perspective is a race. When a CVE is published and a patch is released, the clock starts. Attackers reverse-engineer patches to develop exploits (n-day attacks). The window between patch release and patch deployment is when most exploitation happens — not through zero-days, but through known, patched vulnerabilities that organizations haven’t applied yet. Your patch deployment speed is directly correlated with your attack surface.