15.2 Updates, Patching, and Vulnerability Management
Key Takeaways
- Patch management is a controlled lifecycle: inventory, awareness, testing, approval, deployment, and verification.
- Vulnerability management is broader than patching and adds discovery, prioritization, ownership, tracking, and reporting.
- Risk-based prioritization weighs severity, exploit availability, active exploitation, exposure, asset value, and compensating controls.
- Emergency patching accelerates testing, approval, and deployment when a critical exposed flaw is actively exploited.
- Compensating controls reduce risk temporarily when a patch cannot be applied immediately, and must be tracked until remediated.
Patch Management as a Controlled Lifecycle
Patching is one of the most practical hardening activities, and on the CC exam it sits in Domain 5 (Security Operations, 18 percent). Software and firmware contain defects; some defects become vulnerabilities attackers can exploit. Patch management is the controlled process of getting the right updates onto the right systems without causing avoidable outages.
The flow has six repeatable stages:
| Stage | What happens | Why it matters |
|---|---|---|
| 1. Inventory | Know every asset and software version | You cannot patch what you do not know exists |
| 2. Awareness | Vendor advisories, scans, threat intel | Identifies which patches apply |
| 3. Testing | Apply patch in a representative environment | Confirms it will not break critical functions |
| 4. Approval | Tie change to business risk and change control | Authorizes the work |
| 5. Deployment | Roll out, often phased | Applies the fix |
| 6. Verification | Re-scan, check patch level, sign-off | Confirms the flaw is actually closed |
In a hospital, applying a server patch without testing could disrupt scheduling or patient-care systems — but delaying a fix on an internet-facing, remotely exploitable system is also dangerous. Good patch management balances urgency against operational impact.
Vulnerability Management and Risk-Based Prioritization
Vulnerability management is broader than patching. It discovers assets, scans or assesses them, validates findings, prioritizes remediation, assigns owners, tracks deadlines, applies fixes or mitigations, and reports residual risk. Not every fix is a patch — some require a configuration change, disabling a service, tightening permissions, replacing unsupported software, adding a firewall rule, or formally accepting risk.
Prioritization must be risk based, not just "highest score first." The Common Vulnerability Scoring System (CVSS) gives a 0–10 base score, commonly read as:
- 9.0–10.0 Critical
- 7.0–8.9 High
- 4.0–6.9 Medium
- 0.1–3.9 Low
But a CVSS number alone is not the priority. A Critical flaw on an internet-facing VPN gateway with known active exploitation outranks a High flaw on an isolated lab box with no network path. Real prioritization weighs severity, exploit availability, active exploitation, exposure/reachability, asset sensitivity, business criticality, and compensating controls. The U.S. CISA Known Exploited Vulnerabilities (KEV) catalog is a strong signal that a flaw is being used right now and should jump the queue.
Emergency Patching, Mitigation, and Verification
Normal maintenance windows are useful, but emergencies happen. A vendor announces a critical remote code execution (RCE) flaw on a public web server and attackers are already scanning for it. Waiting a month is unacceptable. An emergency change process allows accelerated testing, approval, deployment, and communication — fast, but still recorded.
When a patch cannot be applied immediately, compensating controls reduce risk in the meantime:
- Disable the vulnerable feature or module
- Block the path at a firewall or web application firewall (WAF)
- Remove internet exposure / segment the system
- Increase monitoring and alerting on that asset
Mitigation is not permanent remediation, so it must be tracked until the real fix lands.
Verification is the step most teams skip. A dashboard may say "deployed" while several laptops were offline and missed it; a scanner may still flag an old library because an app bundles its own copy; a firewall rule may block one exploit path and leave another open. Verify by checking patch levels, rescanning, reviewing logs, testing the application, and getting owner sign-off. After a big effort, ask what slowed you down — incomplete inventory? unknown owners? no rollback plan? — and feed it back into the next cycle.
Exam cue: choose patching for a known vendor fix, vulnerability management for an ongoing discover/prioritize/track program, and compensating controls when an immediate fix is impossible but risk must drop now.
Scanning, Asset Lifecycle, and Risk Treatment Choices
Discovery is the part of vulnerability management that quietly determines everything else: you can only protect what you know about. Programs combine an asset inventory with regular vulnerability scanning. Scans come in two flavors the CC exam expects you to distinguish. An unauthenticated (network) scan probes a host from the outside, seeing roughly what an attacker would — open ports and exposed banners. An authenticated (credentialed) scan logs in and inspects installed software versions, patch levels, and configuration, producing far fewer false negatives.
Credentialed scanning catches the bundled-library problem where an app ships its own vulnerable copy that a network probe would miss.
Scanning also surfaces a hidden hardening risk: end-of-life (EOL) software. When a vendor stops issuing security updates, no patch will ever arrive, so the only real treatments are replacement, isolation, or formal risk acceptance. The exam treats "upgrade or replace unsupported software" as a hardening action, not just an IT chore.
The four risk-treatment options
Every confirmed vulnerability ends in one of four documented decisions, and CC questions often test whether you can name them correctly:
| Treatment | What it means | Example |
|---|---|---|
| Remediate | Eliminate the weakness | Apply the vendor patch or replace the software |
| Mitigate | Reduce risk without full fix | Add a WAF rule or disable the feature (compensating control) |
| Transfer | Shift impact to a third party | Cyber-insurance, managed service contract |
| Accept | Formally tolerate the residual risk | Owner signs off on a low-severity, low-exposure flaw |
The critical exam nuance: risk acceptance must be formal, recorded by an accountable owner with an expiry and review date. "We just left it" is not acceptance; it is an unmanaged exposure.
Closing the loop with metrics
A functioning program tracks time to remediate against severity-based deadlines (for example, criticals in days, mediums in weeks), assigns each finding an owner, and reports residual risk to leadership. Open findings without owners or deadlines is the classic failure mode the exam wants you to recognize — discovery without accountability never reduces risk.
A flaw scores CVSS 9.8 but exists only on an isolated lab server with no network path, while a CVSS 7.4 flaw sits on an internet-facing VPN gateway listed in CISA's Known Exploited Vulnerabilities catalog. Which should be remediated first?
Which choice best describes how vulnerability management differs from patch management?
A critical internet-facing service cannot be patched for 48 hours pending testing, but exploitation is active. What is the best interim action?