You are correct in that the provided solution does suggest a patch that has been superseded, but there is a useful piece of information that I don’t see in IVM that is in Nexpose and that is the proof column of the affected Assets. This column indicates why the asset got tagged with this Vulnerability.
On an Assets that has the superseded patch, can you check these reg keys? If they match this that is why they are getting flagged.
Vulnerable OS: Microsoft Windows Server 2016 Standard Edition 1607
I would add an Exception stating that it is a False Positive (this is allowed even under PCI) but I only know where to do this in Nexpose, I don’t see the option in IVM.
I don’t know if you can modify an IOC of a vulnerability
After troubleshooting with Rapid7 Support, the engineer explained that the new patch (KB) is not changing the OS Build Key (This is a Microsoft issue).
So he recommended to create an exception for this patch which I did.
IVM also has an internal process to avoid flagging such patches.
We have seen similar issues when we give the IT folks a remediation report to work from. It seems to be happening more frequently in the last year or so. It’s confusing to them, and to us, since they have to go research the Regkeys on multiple machines in many cases. You end up with all these exceptions that your eventually have to clean out/justify.
We are seeing vulnerabilities in InsightVM where remediation guidance does not include or show if a superseded MSFT patch is available.
This is causing IT team members handling the patching to push-back on the outdated information and the potential for duplicative work with the original patch and superseded patch.
It would be nice if Rapid7 would update the recommended remediation steps when/if a superseded patch is published.