Qualys superseded updates and caveats  

The vulnerability scanner Qualys has the ability to filter superseded updates in its reports and over the API. This is a popular feature. Unfortunately, it does have some caveats that aren’t always very well understood. Here’s what you need to know about Qualys superseded updates and its caveats.

Why filter superseded updates in Qualys and what’s the caveat?

There is a good reason for filtering superseded updates. If it’s August and I missed my July maintenance window, so I didn’t push out the July updates, that is no longer a huge problem. Since about 2016, Microsoft updates have been cumulative. They supersede one another. So you don’t have to push both the July and the August updates. For that matter, if you’ve missed several months updates in a row, you can push the current months updates to catch up.

And in fact, it’s a lot better if you do. If I push the July update, suppress the reboot, and then push the August update, and then reboot, I don’t get the August update. I get July. I have to reboot again to get August. But I won’t know that until I see the pending reboot QID in a report, or if I happen to be digging around in the ETL files.

So if I’m a Windows administrator, I can save myself a lot of heartache by asking for a report that hides superseded updates, and then making sure that I reboot every system at the end of my maintenance window. And if I have time, and extra reboot will frequently pay dividends. But as with many things, there is a catch.

Search lists

This isn’t as popular of a feature, but Qualys allows you to create search lists. Search lists are groups of vulnerabilities that meet certain criteria that you define. Let’s take an example from earlier in my career. I administered a fleet of about a thousand servers. About 100 of those were Oracle database servers. The operating system and most of the software was my responsibility to update. But the Oracle database was the responsibility of a different team. They didn’t want me messing around with their database, just like I didn’t want them messing around with my operating system. It would usually be okay, but that one time when something went wrong, it would be a disaster.

Search lists are Qualys’ solution to that.

The problem is that search lists and the superseded updates filter break each other. The result is somewhat unpredictable but you’ll end up with some superseded updates being in the list that shouldn’t be. The decision tree logic isn’t designed to handle more than a single filter.

The other problem with filtering superseded updates

There is one other problem with filtering superseded updates. It can mask another problem. If you deployed your updates every month, but you missed any reboots, you end up being behind on updates. If you are filtering the superseded updates, the only indicator that you might have a queue of file updates waiting for a reboot is that single informational QID, 90126, about a pending reboot detected. And let’s just say not enough people know about QID 90126.

So I’m not a huge fan of this feature. If I see superseded updates in a report, that gives me an idea how many times I need to reboot. In extreme cases, I’ve seen a system need 12 or 13 reboots to catch up. QID 90126 tells me I have a problem, but the number of superseded updates is the only indicator I have of how many reboots the system needs.

Working around the limitation

This is where being a former system administrator pays dividends. I know how to work around the problem. Security professionals prioritize by severity. It’s what we are taught to do. But sometimes the fastest way to give a security professional what they want and need is to not give them exactly what they asked for. This is one of those cases.

When you are talking updates from the likes of Microsoft, Adobe, Oracle, and Google, prioritizing by severity frequently results in extra work. Because you apply an update to address some critical vulnerability from 2 months ago, and then you turn around a month later and deploy an update to fix a slightly newer high severity vulnerability. If you had applied the newest available update, you would have avoided all of that.

So what I recommend doing is deploying the newest available update first. Even if Qualys rates it low severity. Find one system that has a backlog, deploy the newest update, reboot it, then scan it again and observe the results. If it’s only slightly better, reboot it again, and repeat. If the system is more than 2 months behind, you may find it takes several reboots to catch up. But you only had to push a single update.

Knock down as much of the backlog as you can by deploying the current months updates and rebooting. Then you can shift to prioritizing by criticality.