Vulnerability and Patch Management Risk

Known holes are the easy way in

Many breaches use vulnerabilities that had a fix available for months. Vulnerability and patch management is the process of finding those holes and closing them before attackers use them.

Example. A file transfer appliance has a critical flaw that criminals are actively exploiting. The patch has been available for six weeks, but it sits in a queue behind 300 “critical” findings on internal test servers.

A continuous cycle

Vulnerability management is a cycle that never stops. The diagram shows its six stages. Inventory what exists, and scan it regularly. Prioritise findings by risk. Remediate them by patching, reconfiguring or compensating within set deadlines. Verify the fix by rescanning. Report time to fix, overdue items and exceptions.

Vulnerability management cycle: inventory, scan, prioritise, remediate, verify, report.

Scanning starts with a complete asset inventory: you can’t scan what you don’t know about. Authenticated scans see more than unauthenticated ones. Penetration tests then show whether weaknesses can actually be exploited.

Fix what matters first

Prioritise vulnerabilities by severity, active exploitation, exposure, asset criticality and compensating controls.

A severity score (such as Common Vulnerability Scoring System (CVSS)) describes the vulnerability, not your risk. Prioritise by:

whether it is being exploited in the wild
exposure: internet-facing or internal
asset criticality: what the system holds or runs
existing compensating controls

Remediation deadlines should be set in policy by risk level (for example, days for exploited critical flaws on exposed systems, weeks for lower risk), and an exploited vulnerability can justify the emergency change route.

When you can’t patch

Unpatchable systems: assess the risk, add compensating controls, accept formally with an expiry date, and track to closure.

Some systems can’t be patched: the vendor no longer supports them, or a patch would break a critical process. That’s a risk decision, not a technical footnote. It needs compensating controls (segmentation, restricted access, monitoring, virtual patching), a formal acceptance by the risk owner with an expiry date, and a plan to replace or upgrade.

Metrics that mean something

Weak metric	Better metric
Number of scans run	Share of assets scanned, including cloud
Total vulnerabilities found	Critical vulnerabilities past their deadline
Patches deployed	Average time to remediate, by severity
Exceptions granted	Exceptions past their expiry date

How the exam asks about it

If the question asks…	The answer is usually…
How to prioritise vulnerabilities	By risk: exploitation, exposure, asset value
The vendor no longer supports a system	Compensating controls, risk acceptance and a replacement plan
BEST vulnerability management key risk indicator (KRI)	Critical vulnerabilities open past deadline
FIRST requirement for scanning	A complete asset inventory
Emergency patch for an exploited flaw	Fast-track through emergency change management

In short

Vulnerability management is a continuous cycle: inventory, scan, prioritise, remediate, verify and report.
Prioritise by risk: exploitation in the wild, exposure and asset criticality, not severity score alone.
Remediation deadlines should be set by policy according to risk, and tracked.
Systems that can't be patched need compensating controls and a formal, time-limited risk acceptance.
Useful metrics are time to remediate and overdue critical vulnerabilities, not the number of scans run.

Exam traps

Fixing vulnerabilities in order of CVSS score alone.
Scanning only the assets you know about.
Patching production without testing, or never patching because testing takes too long.
Letting unpatchable systems sit with no owner or end date.

Slides

Click the slide and use the arrow keys. F toggles full screen.