The meaning of superseded patches

Last Updated on July 4, 2018 by Dave Farquhar

One of my clients asked me to explain superseded patches and how they relate to vulnerability management and patch management. This is a common question about a common complaint. Knowing the meaning of superseded patches and how to handle them is absolutely critical for running a successful security program.

The concept

Vendors release patches every month. Sometimes a patch alters a component that a previous patch fixed. The resulting patch fixes both vulnerabilities. So there’s no longer any reason to apply the earlier patch. The vendor withdraws it, and patch management teams get confused.

An example

I brought up MS08-067, which elicited a giggle. MS08-067 is the most notorious Microsoft patch. I can’t think of any other patch from 2008 we still talk about.

But you can’t download MS08-067 anymore. MS12-054 superseded it. If you apply MS12-054, you fix MS08-067. If you talk about MS08-067 to a grizzled patch veteran, they may “correct” you and say MS12-054. It’s happened to me. To me, all that matters is fixing MS08-067. To them, what matters is which patch to deploy to get me off their back.

What it looks like

Let’s say you never deployed MS08-067. In your vulnerability scan reports, you’ll see vulnerabilities tagged to MS08-067. You’ll also find vulnerabilities tagged to MS12-054. Deploy MS12-054, and both groups go away. Vulnerabilities generally get tagged to the earliest patch that fixes them.

Why not the newest? That would be handy, but even Microsoft sometimes disagrees about what patch supersedes what. The earliest is always very well documented.

Qualys provides a patch report, which eliminates superseded patches. When people ask me for one and only one reason to use Qualys over Nexpose or Retina, the patch report is my answer. But the patch report can’t possibly reach the six-sigma accuracy of a Qualys vulnerability report. Tenable doesn’t have a separate patch report, but its tools provide a way to omit superseded patches from its scan results.

My recommendation is still to use the Qualys patch report, if it’s available, or Tenable’s filtered report. Even if it’s wrong one percent of the time, chasing down that remaining one percent is trivial compared to trying to deploy thousands of patches that the vendor withdrew years ago.

What about Kenna?

What if you do your reporting by exporting your data to Kenna? Kenna’s functionality regarding superseded patches is new, having been released in mid-2018. Managers like Kenna’s view for big-picture reporting, and there’s a lot of value in that.

I like Kenna a lot and recommend it, but that doesn’t mean I rely only on it. One of the reasons I get results is because I’m fine with using data in whatever format and tool allows us to collaborate and solve problems.

Regardless of how your company reports to executive management, you can still provide a patch report to your patch management teams. It’s still useful information, even if it’s off the record. I gave off-the-record analysis to my infrastructure colleagues all the time, using whatever tools we had at our disposal. Management only cared about results, not what tools we used. I found the information that helped the techs was frequently useless to managers, and the information that helped managers often wasn’t useful to the techs. They’re looking at different parts of the issue. And that’s OK.

When you deploy the subset of patches from the patch report, then rescan and re-import into Kenna, the improvement is still visible. If anything, the results may be better than anyone expected.

If you found this post informative or helpful, please share it!