Patch Management

Prioritise: not everything at once

An organisation cannot test and apply every patch instantly, so it must prioritise, and the prioritisation combines the factors the CVSS chapters established:

• Severity, from the CVSS score: how bad the flaw is intrinsically.
• Exposure: is the affected system internet-facing, does it process untrusted input, is it reachable by attackers? A critical flaw on an internet-facing server is an emergency; the same flaw on an isolated internal system is not.
• Exploitation status: is the flaw being actively exploited in the wild? A flaw under mass exploitation jumps the queue regardless of severity, which the CVSS chapters flagged as the factor teams most often omit.

So the order of work is not "highest CVSS first" but "highest risk first", combining severity with exposure and active exploitation. An internet-facing system with a flaw being exploited now is patched before a higher-severity flaw on an isolated system nobody is attacking.

Apply without breaking

The reason patching is not instant is that a patch can break something, and an organisation that has been burned by a bad update becomes reluctant to patch, which is itself a security problem. So patch management includes:

• Testing patches, where feasible, in a non-production environment before applying to production, to catch breakage.
• Staged rollout, applying to a subset first and watching, then to the rest, so a problem affects few systems.
• A rollback plan, so a bad patch can be reversed.
• Maintenance windows and change control, balancing the urgency of the fix against the disruption of applying it, with the balance tilting toward speed for critical, exposed, actively-exploited flaws.
• Automation, because manual patching across a large estate is where systems get missed. Automated patch deployment, with the testing and staging above, is how an organisation patches promptly and completely.

The tension to acknowledge honestly: speed against stability. Patching fast reduces the exploitation window but risks breakage; patching slowly avoids breakage but leaves the window open. The resolution is to patch critical, exposed flaws quickly (accepting some risk of breakage, mitigated by staging and rollback) and to apply less urgent patches on a regular tested cycle.

Handle what cannot be patched

Some systems cannot be patched promptly or at all: an appliance with no available update, a legacy system a critical application depends on, an embedded device. For these, patch management includes compensating controls, the idea from the defender's-mirror chapter:

• Isolate the unpatchable system on its own segment, so a flaw in it cannot spread.
• Restrict access to it as tightly as possible.
• Monitor it closely, since it cannot be fixed.
• Plan its replacement, because an unpatchable system is a liability with a limited safe life.

An honest patch-management programme records what cannot be patched and what compensating controls protect it, rather than pretending everything is current.

A worked example, framed defensively

An assessor reviews an organisation's patch management.

• There is no accurate inventory of software and versions, and no software bill of materials for the applications. The most serious finding, because it means the organisation cannot know what a new advisory applies to. Recommendation: build and maintain an inventory, including component dependencies.
• Advisories are not systematically tracked; the team learns of flaws ad hoc. Recommendation: subscribe to and monitor advisories for the inventory.
• Patching is done on a fixed monthly cycle regardless of severity, so a critical internet-facing flaw waits weeks. Finding: prioritise by risk, patching critical exposed flaws out of cycle.
• An unpatchable legacy appliance runs on the main network with no compensating controls. Finding: isolate it, restrict and monitor it, and plan replacement.
• Patching is manual, and several systems are found running outdated versions the team believed were patched. Finding: automate, so systems are not missed.

The report's theme is that installing updates was never the problem; the gaps are inventory, tracking, prioritisation, and reliable application, which are the discipline of patch management. The assessor establishes them by reviewing process and records, not by exploiting the unpatched flaws.

What beginners get wrong

• Thinking patch management is "install updates". Installing is the easy last step; the discipline is inventory, advisory tracking, prioritisation and reliable application.
• Not maintaining an inventory. You cannot patch what you do not know you run, including indirect dependencies; a software bill of materials is the tool.
• Patching by CVSS alone. Prioritise by risk: severity plus exposure plus active exploitation, so an exploited internet-facing flaw jumps the queue.
• Patching everything on one fixed cycle. Critical exposed flaws need out-of-cycle speed; a rigid cycle leaves urgent windows open.
• Not testing or staging. A bad patch that breaks production makes the team reluctant to patch; test, stage, and keep a rollback plan.
• Pretending everything is patchable. Unpatchable systems need compensating controls (isolate, restrict, monitor) and a replacement plan, recorded honestly.

Quick revision

• Patch management closes the exploitation window, which shuts for a system only when it is patched; most real attacks exploit known, patched flaws on unpatched systems.
• It is more than installing updates. The hard parts: inventory (you cannot patch what you do not know you run, including indirect dependencies; a software bill of materials helps), tracking advisories for the inventory, prioritising by risk (severity + exposure + active exploitation, not CVSS alone), and applying reliably (test, stage, roll back, automate, balancing speed against stability).
• Unpatchable systems get compensating controls, isolate, restrict, monitor, and a replacement plan, recorded honestly.

Test yourself

1. Why is patch management described as the control that prevents the most harm?

Because the great majority of real compromises exploit known, already-patched vulnerabilities on systems that were not updated, rather than zero-days, and the exploitation window closes for a given system only when that system is patched. Patch management is the discipline that closes that window promptly, so despite being unglamorous it prevents more harm than any single clever control.

1. Why can patch management not be reduced to "install updates"?

Because installing is the easy final step, while the discipline consists of the hard parts around it: maintaining an accurate inventory of what is run, including indirect component dependencies; tracking advisories to learn when fixes exist; prioritising which patches to apply first; and applying them reliably across an estate without causing breakage. A failure in any of these leaves systems unpatched even when updates are available.

1. Why is an accurate inventory the first requirement, and what tool assists it for application components?

Because you cannot patch what you do not know you run, so when an advisory for a critical flaw arrives, an organisation without an inventory cannot answer whether and where it runs the affected software, which is the paralysis seen in the Log4Shell case. A software bill of materials, a machine-readable list of the components in each application including indirect dependencies, assists by turning that question into a query.

1. How should patches be prioritised, and why is CVSS score alone insufficient?

By risk, combining the CVSS severity with the exposure of the affected system, whether it is internet-facing and reachable by attackers, and whether the flaw is being actively exploited in the wild. CVSS alone is insufficient because a medium-severity flaw on an internet-facing system under active exploitation presents more real risk than a higher-severity flaw on an isolated system nobody is attacking, so exposure and exploitation status reorder the queue.

1. How should systems that cannot be patched be handled?

With compensating controls and a plan: isolating the unpatchable system on its own network segment so a flaw cannot spread, restricting access to it as tightly as possible, monitoring it closely since it cannot be fixed, and planning its replacement because it is a liability with a limited safe life. An honest patch-management programme records what cannot be patched and the controls protecting it rather than assuming everything is current.