3.5.2. Patching, Change Management, and Risk Decisions
💡 First Principle: Every vulnerability has a response option — patch, compensate, accept, transfer, or avoid — and the right choice depends on the vulnerability's risk in context, the cost of remediation, and the organization's risk tolerance.
Patch and Configuration Management Process:
Testing — Patches are deployed to non-production first (dev → test → staging → production). Critical patches may compress this timeline (emergency change process) but never skip validation entirely. The longest testing window belongs to production servers running business-critical applications, because a regression there costs the most: test against a staging copy that mirrors production before release.
Implementation — Phased rollout for broad patches; canary deployment (small initial group) for high-risk changes.
Patch vs. configuration remediation — A security patch replaces or updates software components (new binaries or code) to remove the flaw itself. A configuration remediation changes the settings of the existing software, such as disabling a service or protocol, tightening permissions or removing default accounts, to reduce attack surface without changing the software version. Both need testing and change control.
Rollback — Every patch deployment needs a defined rollback procedure. If the patch causes issues, what's the plan to restore the system to its prior state? Snapshot-based rollback (VMs) vs. manual rollback for physical systems.
Validation — After patching, re-scan to confirm the vulnerability is actually remediated. Version-based scanner detection confirms the patch was applied; authenticated scanning confirms the vulnerability is no longer present.
Maintenance Windows — Scheduled times for applying changes to minimize business impact. Critical systems may have narrow maintenance windows (overnight on weekends); some systems (HA clusters) can be patched in rolling fashion with no downtime.
Exceptions — When a vulnerability cannot be remediated per standard timeline (legacy system, vendor constraint, critical business process), an exception documents: the vulnerability, the reason remediation isn't feasible, the compensating controls in place, the residual risk, and the exception expiration date (requires re-review).
Risk Management Options:
| Response | When to Use |
|---|---|
| Mitigate | Apply the patch or implement a technical fix |
| Accept | Risk is below threshold, or cost of fix exceeds cost of impact |
| Transfer | Shift risk via cyber insurance or contractual SLA |
| Avoid | Decommission the system/service creating the risk |
| Compensate | Primary control infeasible; implement alternative controls (a form of mitigation) |
SLOs (Service-Level Objectives) for patching define timelines by severity: Critical within 24–72 hours, High within 7–14 days, Medium within 30 days, Low within 90 days. These SLOs vary by organization and regulatory requirement.
⚠️ Exam Trap: Risk acceptance is a formal, documented decision — not ignoring a vulnerability. Accepting risk means a responsible person with authority has evaluated the vulnerability, determined the risk is acceptable, and signed off. Undocumented "acceptance" is simply an unmanaged vulnerability.
Risk Concepts: Inherent Risk, Residual Risk, Risk Appetite
| Concept | Definition | Example |
|---|---|---|
| Inherent risk | Risk in the absence of any actions by management to alter its severity (NIST, from COSO) — risk before controls | Customer database with no MFA or segmentation: High |
| Residual risk | Portion of risk remaining after security measures have been applied (NIST SP 800-30) | Same database after MFA, segmentation and monitoring: Medium |
| Risk appetite | The broad amount and type of risk an organization is willing to accept in pursuit of its mission (NIST) | Board: customer-data systems must sit at Low |
Residual risk is what gets compared with the appetite. In the example, Medium residual risk is above a Low appetite, so the organization must treat it further (mitigate, transfer, avoid) or have an authorized owner formally accept it as a documented exception. Residual risk never reaches zero, so the goal is "within appetite", not "none".
Likelihood and impact are weighed together, not averaged and not ranked by likelihood alone. A vulnerability with low likelihood but catastrophic impact (for example, exposure of every customer record) still warrants high priority and real investment; low likelihood is not grounds to accept it. A likely but trivial-impact finding is the reverse.
Policies, Governance, and SLOs: Appetite is set by leadership and becomes concrete through governance: a vulnerability management policy states who owns remediation and how exceptions are approved, and SLOs turn appetite into deadlines per severity. Measuring SLO compliance is how the organization proves it is operating within its stated appetite.
Validation of Remediation
A fix is not finished until it is confirmed on every affected asset:
- Rescan every asset in the finding — not a sample; the hosts where deployment failed are exactly the ones a sample misses.
- Prefer credentialed checks. Distributions often backport security fixes without changing the version number, so banner- or version-only checks produce false positives (Red Hat documents this directly) and can also hide unpatched hosts.
- Confirm the fix is active — for example, a service restart or reboot the update requires.
- Test compensating controls where they were used instead of a patch: does the firewall rule or WAF policy actually block the attack path?
- Close per host with evidence; reopen any host that still reports the finding.
Missing patches after a deployment cycle — If a rescan still shows a share of hosts unpatched after a cycle run through a tool such as WSUS or Microsoft Configuration Manager, suspect the hosts before the tool: servers that are offline, network-isolated, in a segment that cannot reach the update server, or not pointed at it by Group Policy never receive the deployment. Check the patch tool's reporting for hosts that have not checked in recently and compare it with the asset inventory.
Watch for patch side effects — After patching, look for new failures: unexpected service stops (Windows System log Event ID 7031 or 7034, Service Control Manager reporting that a service terminated unexpectedly), application errors and user reports. Repeated service crashes after an update suggest it destabilized the host; identify which services failed and roll back that host if needed. A required reboot is a different, expected signal.
⚠️ Exam Trap: A change ticket marked "complete" proves the deployment job ran, not that the vulnerability is gone. Only a rescan or direct check of the asset validates remediation.
Reflection Question: Your vulnerability scanner identifies a critical RCE vulnerability in a custom application used by the finance department. The vendor has released a patch, but the finance team says they cannot take the application offline for patching until after the quarterly close in 3 weeks. What risk management response options are available, and what should be documented regardless of which option is chosen?
