4 min read
You will not patch every vulnerability
On a Friday at 4:05 p.m., the vendor of the remote access equipment of a 150-person engineering company publishes an advisory: a critical flaw, rated 9.8 out of 10, affects all versions, and no patch exists yet. The equipment is exposed to the internet, and forty engineers connect through it from home. The IT team has three people, and two hundred patches are already waiting in their queue. The company is fictional, the situation is common: no team patches everything, immediately, everywhere, and vulnerability management is therefore a series of choices, some of which will be wrong. It is preparation that limits the damage when they are.
A volume that forces choices
Every year, tens of thousands of new vulnerabilities are published. Patching means testing, finding a downtime window acceptable to the business, sometimes waiting for a supplier who has not yet published its patch, as on this Friday. Some systems simply cannot be updated: industrial equipment, medical devices, old applications whose code nobody maintains any more. In these conditions, setting priorities amounts to accepting a risk on everything else, and that is not negligence, it is the nature of the work.
The team at our fictional company knows this well. Its two hundred pending patches are not all equal, but nothing in the list says so: workstation updates sit next to server flaws, and the Friday advisory arrives in a stream where everything looks urgent. The question then becomes one of triage, that is, of what you look at to decide.
Prioritizing is not sorting by score
The reflex is to sort by severity score. The CVSS score measures the technical severity of a flaw, not the likelihood that it will be exploited in your environment, and the two often differ. Several questions matter more. Is the flaw already exploited in the wild? The catalog of known exploited vulnerabilities, maintained by the US agency CISA and known by the acronym KEV, lists those for which this is established. Is the affected system exposed to the internet? How important is it to the business? Is there a compensating measure, such as turning off a function or filtering certain access? The EPSS score, which estimates the probability that a flaw will be exploited, also helps to separate similar cases.
Applied to our company, this grid gives a clear result, even if Friday does not yet provide all the answers: an exposed piece of equipment, essential to the work of forty people, hit by a critical flaw with no patch, comes ahead of dozens of older flaws buried in an internal network.
The day the unpatched flaw is exploited
During the Log4Shell flaw, in December 2021, the hardest question for many organizations was not “how do we fix it?” but “where do we use this component?”. Knowing what you own, and in which version, is part of being prepared, and it cannot be settled on the day of the advisory. The time between a flaw being published and its first exploitation can also be very short, sometimes a few days.
Let us go back to that Friday at 4:05 p.m. Several decisions have to be made, and they are made badly in a rush. Who decides to isolate the equipment, and can do so without waiting? Who accepts the impact on the business, that is, forty engineers who can no longer connect? How will we know whether we were compromised before the announcement, and how long have we been keeping connection logs? Who informs customers if data may have been accessed, and within what time? These questions are much better asked on a Tuesday in a meeting room than on a Friday evening. The answers can, moreover, take the form of thresholds agreed in advance: if a flaw is exploited and the system is exposed, it is isolated within a set time, and the business owner is informed, not consulted.
Patch more slowly, respond faster
A late patch is made up for by the ability to detect and react, and that ability can be rehearsed. Having the logs at the right moment, knowing the contact at the supplier and their weekend number, knowing how to launch an emergency change, and how to roll it back if it breaks something: all of it is learned by playing it, not by reading it. An organization that has played it once does not improvise on a Friday evening.
For our fictional company, the difference is concrete. Without preparation, the 4:05 p.m. Friday leads to an evening of discussions and, perhaps, a weekend of incident. With an agreed isolation rule, an up-to-date list of equipment and a tested emergency access, it leads to half a day of degraded work and a recorded decision: the remaining risk was accepted by someone, by name, until the patch was published.