Mitigation and Remediation

What it is

Remediation fixes the cause of a vulnerability, for example by installing a patch. Mitigation reduces the risk without removing the flaw, for example by blocking access to the vulnerable service.

The analyst helps choose the right option, makes sure the work is tracked and approved, and confirms that the fix worked. Closing a ticket is not the same as closing the risk.

How it works

Options for dealing with a vulnerability

Choose a compensating control only if it addresses the same threat to a similar degree. It is a temporary or alternative answer, and it should be documented and reviewed.

Software and web application fixes

For flaws found in code, the fix is to change the code or the way it is built.

• Input validation checks that data has the expected type, length and format before use.
• Parameterised queries keep user input separate from database commands, which stops Structured Query Language (SQL) injection.
• Output encoding prevents injected scripts from running in a browser.
• Updating libraries replaces vulnerable third party components that software composition analysis identified.
• Secure session and credential handling removes hard coded secrets and weak session settings.

Patch management practice

1. Track vendor advisories and the assets they affect.
2. Test patches in a non production environment, because updates can break applications.
3. Schedule installation in a maintenance window, with a rollback plan.
4. Deploy in stages, starting with a pilot group.
5. Verify that the update installed and that the service still works.
6. Document the change and update the asset record.

Emergency patching shortens these steps for flaws under active attack, but the change should still be recorded.

Change management and governance

A change request records what will change, why, the risk, the schedule and the rollback. Approval by a change board gives a controlled and auditable process.

Many organisations set service level targets for remediation by severity, such as a short deadline for critical items and a longer one for low items. The exact numbers are set by policy and differ between organisations.

An exception or risk acceptance should name the owner, the reason, the compensating controls, an expiry date and an approver with authority. It is not a permanent way to ignore a finding.

Validation

After the fix, confirm it worked.

• Rescan the affected systems and check that the finding is gone.
• Verify manually where a scan cannot confirm it, such as checking a configuration value.
• Test the service to confirm it still works.
• Update records and close the ticket only after validation.
• Watch for recurrence, since an old image or script may bring the flaw back.

Before: 192.0.2.40  443/tcp  TLS Version 1.0 Protocol Detection  High   Open
After:  192.0.2.40  443/tcp  TLS Version 1.0 Protocol Detection         Not present
Action: close ticket, record rescan date, keep the host in the next scheduled scan

Reducing the attack surface

Remediation also includes removing what should not exist: unused services, open ports, old accounts and default settings. Hardening to a secure baseline, such as a vendor or Center for Internet Security (CIS) benchmark, prevents many findings from appearing.