Patch Management is not Vulnerability Management, so stop treating it that way.

It feels a bit odd to be talking about patch management in 2023, this is something that we as IT professionals have been working on for decades. One of the most frequent questions I get relates to  improving a patch management strategy and execution.

Patch Management is a How, Vulnerability Management is  Why.

You can be amazingly efficient at distributing patches, but not change your threat profile an iota. Why? Because patching is just a means of distributing fixes, but isn’t enough on its own. What happens when a patch only partially addresses a vulnerability? What happens if it actually enables a more secure protocol, but doesn’t disable negotiation down to a lower / earlier protocol version? (yes, that’s a TLS reference, well spotted)

You have been very efficient at patching, but not addressed whether you are vulnerable.

That’s the key: orienting your view towards vulnerability changes what you focus on, and it also requires more effort than carte blanche delivery of patches. To that end, taking a more risk-based vulnerability management approach leads to more protection and more efficient use of resources – especially time!

Once you have this framework in place, you are able to prioritize what must be addressed first, but also how the vulnerability can be addressed. This improves your patching execution in two dimensions: you are addressing the most vulnerable parts of your infrastructure first, and that you are balancing the return on the effort against the interruption remediating may cause.

What I’m not saying.

I’m not saying that patch management is not important – it absolutely is. What I am saying is that it’s only one of the ways that you can respond to vulnerabilities.

The traditional ways of addressing vulnerabilities – patch management, configuration update, software update – are all effective… eventually, mostly due to the time it takes to execute.  Mitigating controls are better in reducing the time to respond, but may not be 100% effective and turn into another thing for you to manage and keep visible. And yes, risk acceptance is the final option for “addressing” a vulnerability.

A quick aside on risk acceptance: one of the outcomes of risk-based vulnerability management is that instead of the hackneyed “I accept the risk” (ala Michael Scott declaring bankruptcy), you actually get a reasonable view into the risk that is being reviewed and what the options are for addressing it – and why your business partners may not be able to make that investment. Out of that can be creative ways of mitigating the vulnerability, but also a clear understanding of what is being traded off. This is invaluable, as it both demonstrates the sensitivity of the vulnerability team to the business conditions that they are operating in, and also the opportunity to bring your business partners into the decision making process.

What I’m not saying… also.

I’m not saying that this makes patch management any easier to do. I am saying that it makes it more clear what Must Be Done First, followed by what Must Be Done Next, all the way down to There’s Nothing We Can Do Other Than Replace The Asset.

Transparency and involvement in the decision making process are your best levers in making a more effective vulnerability response.