We’re getting pushed by our vulnerability team to push old patches to our Windows server fleet. I understand we can do this by including the “Enable Superseded Patch Evaluation” at the start of our baseline. Do Microsoft test the results of applying superseded patches over the top of patches already applied that superseded the these older patches (hope this makes sense)?
Really just wanting to properly understand what the pitfalls of enabling superseded patch evaluation is and are there risks to things going south (blue screens, etc)?
My personal recommendation here is to apply the latest patches rather than superseded patches. My logic being:
Patches can be superseded for a number of reasons, including functional improvements (i.e. a newer patch may fix functional issues associated with a superseded patch)
The latest patch will often include additional vulnerability fixes than a superseded patch
Fewer patches will often need to be deployed when pushing the latest patch
Do you have more details on why the vulnerability team is suggesting older patches be deployed? Is it because that is the patch being recommended by a vulnerability scanner?
Generally…no they don’t test that. Many of the old/superseded patches will prevent themselves from installing over a newer version, returning the message ‘This patch is not applicable to your system’.
The right way to patch superseded vulnerabilities is actually to apply the latest version of the patch that supersedes the older one.
Enabling ‘Evaluate superseded content’ is generally done for reporting fidelity - so you can use a tool like BigFix Compliance to report “how many months out of date” for the system. Remediation usually means applying current patches.
We had this come up with our Tenable/Nessus vuln team. Went back and forth over superseded and finally proved to them (and Tenable devs) that supersedence was disabled by default in Nessus. Once that became clear we were able to work around it in the reports and go with latest patches only.
Thanks everyone for the input. Especially interesting to hear others have had issues with Vulnerability teams. We used to use Nessus, think it is Qualys now. Had to do something very similar when WannaCry was doing the rounds, even to prove that Nessus was only checking the DLL version of a few files where as Bigfix was checking the full file manifest from the patch. Anyway, will definitely be pushing back to see how Qualys handles MS patch supersedence, quick search shows that as recently as a year ago it wasn’t handled well.
Anyway, my take away is;
We should flick the switch on “enable superseded patch evaluation” only for reporting.
Patches should still be laid down in newest to oldest order with a sub-order of Service Stack, .Net, Cumulative updates, other.
Patches marked Superseded should not be included in baselines, however if showing relevant should be investigated to track down the current patch that should be rendering this superseded patch non-relevant.