Fixing, mitigating and accepting

Why this matters

Prioritisation decides what to act on. This lesson is about the acting — and about the fact that "remediate" is only one of several legitimate outcomes.

The exam distinguishes the options precisely, and so should you: remediation removes the vulnerability, mitigation reduces the risk while leaving it present, and acceptance does neither but records the decision. Choosing wrongly between them is a common scenario question, and choosing acceptance without the record is the failure that turns an incident into a finding against the organisation.

The lesson

Patching, configuration change and virtual patching

Patching is the definitive fix: the vendor's update removes the flawed code. Preferred where possible, and not always possible — the vendor may not have released one, the system may be out of support, the patch may require downtime nobody will approve, or it may break a dependent application.

Configuration change often removes the vulnerability just as completely and is frequently faster. Disabling the affected module, turning off the unused protocol, removing the unnecessary feature, changing the default credential. In cloud environments this is usually the fix rather than an alternative to one, per lesson 21 — misconfiguration has no patch.

Virtual patching blocks the exploit without changing the vulnerable system: a WAF rule matching the attack, an IPS signature, a firewall rule removing reachability. It is genuinely useful:

• It is fast, often minutes against days.
• It works for systems that cannot be patched at all — appliances, industrial systems, unsupported software.
• It buys time inside an SLA while the real fix goes through change control.

Its limits need stating with equal clarity. It is signature-dependent, so a variant of the exploit may pass; it protects only traffic that traverses the control, leaving internal paths open; and it is frequently forgotten — the temporary rule becomes permanent, and everybody stops thinking about the underlying vulnerability. A virtual patch should always carry the real remediation ticket with it, and an expiry review, exactly like the deferral record in lesson 23.

Decommissioning deserves mention as the most underused option. A system with no owner, no users and an unpatchable vulnerability should be switched off. It is the only remediation that is guaranteed permanent.

Rollback plans and change windows

Remediation is a change, and changes break things. The security team that breaks production loses the cooperation it needs to do everything else, so this section is about not being that team.

Before applying:

• Test in a representative environment. "Representative" is doing real work in that sentence; a staging system with different configuration tests different software.
• Have a rollback plan — a snapshot, a backup, an uninstall procedure, a previous image — and know how long rollback takes.
• Check dependencies. A library update can break an application that pins an old version.
• Agree the window with the owner, and prefer one where people are available to fix problems.
• Stage the rollout: a canary group, then a wider ring, then the estate. This is the single most effective protection against a bad patch, and it costs only patience.

Two specific cautions worth carrying:

• Reboots. Many patches are not effective until reboot, and a patched-but- not-rebooted system reports as fixed while remaining vulnerable. This discrepancy appears in scan comparisons and confuses people every time.
• Emergency changes. Actively exploited, internet-facing criticals justify bypassing normal change control — through the documented emergency path, not by ignoring the process. The distinction matters afterwards.

Verifying a fix actually fixed it

Never trust a ticket marked resolved. This is the same instinct as verifying an alert before escalating, and it fails for the same reasons.

Verification, in ascending order of confidence:

1. Someone says it is done. No confidence.
2. A configuration or package query confirms the new version on the host.
3. A rescan no longer reports the finding, using the same method that found it — and this is the important qualifier. A finding that "disappeared" from an uncredentialed rescan when the original was credentialed proves nothing, which is the false-negative trap from lesson 20.
4. A targeted test of the specific behaviour confirms the vulnerable path is closed.

Things that produce a false "fixed":

• The scan failed to authenticate and reported nothing.
• The host was offline during the rescan.
• The asset record changed identity, so the old record simply stopped updating.
• The patch was applied and the service not restarted, or the host not rebooted.
• Remediation was applied to one instance of many.
• The scan scope changed and no longer includes the asset.

The discipline: close findings on evidence, and record what the evidence was. A remediation rate computed from tickets closed is a measure of ticket hygiene; one computed from verified rescans is a measure of security.

Risk acceptance, transfer and exceptions

The four classic treatments, and the exam expects you to distinguish them:

• Avoid — remove the exposure entirely. Decommission the system, stop using the feature, exit the activity.
• Mitigate — reduce likelihood or impact. Patching, configuration change, compensating controls.
• Transfer — move the financial consequence elsewhere, typically insurance or a contractual obligation on a supplier. Note carefully: transfer moves liability, not risk. The system is still vulnerable and the incident still happens; somebody else bears part of the cost. Regulatory and reputational consequences rarely transfer at all.
• Accept — take no further action and carry the risk knowingly.

Acceptance is legitimate and routine. What makes it legitimate is the conditions:

• The right person accepts it — someone with the authority to carry the consequence. An analyst cannot accept risk on the organisation's behalf, a point this course has made since lesson 1.
• It is informed: the accepter understood the risk in business terms.
• It is documented, with the content from the deferral list in lesson 23.
• It expires and returns for review.
• It is visible in reporting, so accumulated accepted risk is seen in aggregate. Twenty individually reasonable acceptances can add up to an unreasonable overall position, and only aggregate reporting shows it.

Recurring findings and the process failure behind them

A vulnerability that is fixed and comes back is not a vulnerability problem. It is a process problem, and treating it as the former guarantees a third occurrence.

The common mechanisms:

• Golden image not updated. Hosts are patched individually; new builds come from the same stale image and arrive vulnerable. The most common cause by a distance.
• Configuration management reverting the fix, because the desired state in code still describes the old configuration.
• Container images rebuilt from an unpinned or outdated base, per lesson 21.
• Infrastructure-as-code templates unchanged, so every new deployment reintroduces the setting.
• Autoscaling from an old launch template.
• A manual fix on a system that gets reimaged on a schedule.
• Vendor updates that reset configuration to defaults.

How to handle it properly:

• Track recurrence explicitly as a metric. Findings that reappear after closure are a distinct category and should be reported as one.
• Fix at the source. Update the image, the template, the desired state — the same shift from instance to definition that lesson 21 described for containers.
• Add a detection for the reverted state where you can, so the next recurrence is noticed immediately rather than at the next quarterly scan.
• Treat repeated recurrence as a finding about the process, and report it that way. "This critical has been remediated four times in nine months" is a far more useful sentence to put in front of a manager than a vulnerability count, because it names something that can actually be changed.

That reframing — from the flaw to the mechanism that keeps producing it — is what makes a vulnerability programme improve rather than merely persist, and it is exactly what the reporting lessons at the end of this course are for.

Topics this lesson owns

• [x] Patching, configuration change and virtual patching
• [x] Rollback plans and change windows
• [x] Verifying a fix actually fixed it
• [x] Risk acceptance, transfer and exceptions
• [x] Recurring findings and the process failure behind them