8.3.2. Patch and Vulnerability Management
💡 First Principle: Patching is the operational expression of vulnerability management — it converts "we know about this vulnerability" into "we have eliminated this vulnerability." The window between vulnerability disclosure and patch deployment is a period of elevated risk: the vulnerability is public knowledge, exploit code may exist, and the organization's systems remain exposed. Minimizing this window is the primary objective of patch management.
Patch management lifecycle (operational):
| Phase | Activities | Security Consideration |
|---|---|---|
| Identification | Monitor vendor advisories, CVE feeds, CISA KEV, vulnerability scan results | Prioritize by exploitability + asset criticality, not just CVSS |
| Evaluation | Assess applicability, dependencies, and potential impact | Some patches require prerequisites; some break specific configurations |
| Testing | Deploy to staging environment mirroring production | Verify functionality, performance, and stability before production push |
| Deployment | Push to production within SLA windows | Deploy to highest-risk assets first; maintain rollback capability |
| Verification | Re-scan patched systems; confirm vulnerability remediated | A "deployed" patch that failed to install provides no protection |
| Documentation | Record patch status for compliance and audit | Unpatched exceptions must go through risk acceptance process |
Patch SLA tiers (risk-based):
| Severity + Context | Target SLA | Rationale |
|---|---|---|
| Critical + CISA KEV (actively exploited) | 24–48 hours | Active exploitation means the clock is running |
| Critical + internet-facing | 72 hours – 7 days | High exposure; exploit likely imminent |
| Critical + internal only | 14 days | Lower exposure but still urgent |
| High | 30 days | Standard patch cycle |
| Medium/Low | Next maintenance window | Risk-appropriate deferral |
Emergency patching bypasses the standard change cycle when the risk of delay exceeds the risk of an untested change. The emergency change process still requires: authorization (ECAB or delegated authority), documentation (even if retrospective), and post-implementation review. An emergency patch deployed without any governance is an uncontrolled change — it may fix the vulnerability but introduces risk from the untested deployment itself.
Vulnerability lifecycle management:
Patching addresses known, patchable vulnerabilities. But the vulnerability management program must also handle:
- Unpatchable vulnerabilities — Legacy systems, embedded devices, or vendor-unsupported software where no patch exists. Require compensating controls (network segmentation, WAF, enhanced monitoring) and documented risk acceptance.
- Zero-day vulnerabilities — No patch available yet. Response: deploy available mitigations (disable vulnerable feature, block attack vector at network perimeter), increase monitoring for exploitation attempts, prepare for rapid patch deployment when available.
- Configuration vulnerabilities — Not fixed by patching; require configuration changes (disable weak ciphers, close unnecessary ports, remove default accounts).
⚠️ Exam Trap: Deploying a patch does not automatically mean the vulnerability is remediated. The patch may fail to install, may require a reboot that hasn't occurred, or may be incompatible with the system's configuration. Post-deployment verification scanning is essential — without it, the organization's vulnerability count drops on paper while the actual exposure remains unchanged.
Reflection Question: A vulnerability scanner identifies a critical remote code execution vulnerability in a web application framework used by 40 production applications. The vendor has released a patch, but the application teams report that the patch breaks authentication in 6 of the 40 applications due to a deprecated API dependency. Describe how you would manage this situation: which systems get patched immediately, what compensating controls protect the remaining 6, and what governance process manages the exception.
