Building on a point Geoff Hancock made this week, and the part that decides whether it works in practice.

TL;DR

  • A large patch release does not test how fast you patch. It tests whether you can find the few systems that cannot wait, and whether someone can authorise action before the window closes.
  • That only works if the map from software to service to owner to exposure already exists. Assemble it under pressure on the day and “awaiting owner confirmation” becomes the standing excuse for a system that is still open.
  • The same question is harder one tier out, in the software your suppliers run, where you have no scanner and no owner to call.

Geoff Hancock, who has been a CISO seven times and writes the Saturday Cyber Journal, made a point this week that deserves a wider audience. The real test of a big patch release is not how fast you patch. It is whether you can identify the few actions that cannot wait, and whether someone can authorise them in time. He is right. I want to build on it, because the thing that decides whether his argument works in practice is not on the patch report at all.

The report tells you what is vulnerable, not what to do

When a large release lands, the first numbers to reach leadership are counts. How many vulnerabilities were announced. How many assets the scanner flagged. Those numbers describe the weather. They do not tell you which affected system an attacker can actually reach, what they would gain, or what breaks if you take it down tonight. A recent Microsoft release was reported to address close to a thousand vulnerabilities, two of them under active exploitation. Sorted into one severity-ranked queue, that is not a decision. It is a backlog.

The real question, and why it stalls

The question that matters is narrow. Which affected systems cannot wait for the normal patch window? Answering it means moving from the affected software to the affected service. You have to know which of the vulnerable products you actually run, what depends on them, who owns that service, and whether the vulnerable path can be reached. Geoff calls this finding the service, not just the software. It is exactly where most processes stall, because the answer is not on the scanner output.

The map has to exist before the release

Here is the part I want to add. Most teams try to build that map on the day. Asset to service to owner to exposure, assembled under time pressure while the clock runs. That is why “awaiting owner confirmation” becomes the standing explanation for a system that is still exposed. The map cannot be a fire drill. It has to exist before the release and be kept current, so that when the release lands the urgent question is answerable in an hour, not a week.

This is the difference between a tool and an operation. The scanner is a tool. It produces the queue. Turning that queue into a small set of governed decisions is a discipline, it is relentless, and on a stretched team it is the first thing to fall over. The tool was never the hard part. The operation around it is.

Someone has to be able to say yes

Finding the system is only half of it. Something has to be done before the patch window, and that usually means an emergency change to a live service. A patch owner can schedule an update. That same person often cannot authorise taking a customer service offline for two hours tonight. Geoff’s point, which I would put at the centre, is that you decide who holds that authority before the incident, not during it.

That is a governance question, and it has a clean answer. The risk belongs to the people who own the business, the board and the executive. The operation’s job is to make their decision exercisable. Map the decision rights in advance. Name who can approve a service interruption, and name their backup for after hours. Bring the recommendation to that person while there is still time for the choice to matter. The risk stays theirs. The work of surfacing it, in time and with a costed option, becomes the operation’s.

Record the wait, verify the close

Two habits separate a managed exposure from a hopeful one. First, when you choose to wait, record it with the same care as a decision to act. Name the system, the reason the fix cannot go in yet, the interim control holding the line, and the date the decision expires. A documented exception with no expiry and no interim control is not managed risk. It is an open hole with a form attached. Second, after the change, check the thing that actually worried you. A green deployment status is evidence, not proof. Confirm the component is on the fixed version and the path you were concerned about is closed.

The harder version, one tier out

There is a harder version of all of this, and it is the one most firms cannot see. The affected software is often not yours. It sits inside a supplier’s service, or in a shared component two tiers beneath it. There you have no scanner and no owner to call, and the same question, which of these cannot wait, is far harder to answer. The discipline that works on your own estate has to extend into your supply chain, where the only thing you have is the map. I have written separately about what actually sits beneath a material service provider, and why the usual tools cannot see it.

150 on the register. Thousands beneath. A handful that everyone shares.

What good looks like

None of this is exotic. It is a current position, a set of pre-agreed decisions, a recommendation brought to the right person, a recorded call, and a verified close. Run once a quarter under pressure, it fails. Run continuously, as an operation, it means the next release is a set of decisions you are ready to make, not a scramble.

That is what running risk as an operation means, and it is what BayRisk does. We keep the position current and run the decision discipline around it, so that when a release lands the hard question is already answerable, and the risk goes to the person who owns it. The patch you can schedule was never the problem. The decision you cannot wait for is, and that is the one worth being ready for.

With thanks to Geoff Hancock, whose piece prompted this one. His original is worth reading in full.

References