Is there a way to know if Qualys matches the CVEs to superseded/non-superseded patches?
The patch report template can be imported to your account directly from Qualys. Hopefully you can see how to do this but you can import the Template from Qualys directly then modify.
I believe there is an outstanding FR on this. Have you run a patch report to see?
Is there any specific template to run for finding this out?
Here's the thing and you all need to be aware, patch supercedence works best for Microsoft OS Patches.
If you start adding filters to a report with Exclude Superceded Patches enabled, you will break the supercedence chain on the backend and the results will not be reliable.
As a security professional, I believe in transparency so my recommendation and personal preference is to NOT exclude NRKs, superceded patches, etc...from executive reporting. But that's me - my argument is whether or not there's a superceded patch, it is still a missing patch, and the vulnerability is still exploitable...
Can you provide more information about superseeded patches pertaining to Microsoft?
The statement Microsoft provides is that a monthly patch includes any patches for new vulnerabilities that month, as well as the roll-up of monthly patches released prior. What I am seeing in my environment is that Qualys is not listing the latest patch as being needed (i.e. for the example let's say November) for the most current month however it shows as still being vulnerable for the previous months ( September, August, July....) This occurs more frequently with the monthly MS Office related monthly patches (i.e. Microsoft Office and Microsoft Office Services and Web Apps Security Update, MS Office monthly patches, and even the MS Office Remote Code Execution vulnerabilities). Please note this only happens on those servers that may have missed a round or two of patching in previous months.
We are giving the vulnerabilities to our team to address and they notify us that our local reporting server has identified the patch as not needed because it is superseeded and an updated patch has since been applied.Clarity on whether the vulnerability still exists (as well as any supporting documentation) would be helpful. In addition, please describe the best path forward for not providing are engineers with remediation steps for superseeded patches (if they are in deed no longer vulnerable).
I do not have an issue with seeing the patch if the vulnerability still exists, however if the patch has been re-mediated through a newer updated patch than that should not be listed.
I am quite interested here as well to validate thinking
Hi Brandon ( aq_bb ),
I apologize for the delay in responding, I was out on a personal holiday.
I am unable to speculate on the scenario you have described but am totally open to reviewing raw scan results that support the above and let you know my thoughts. Please direct message me (DMFezzaReed) with your email address and I will provide a secure upload link.
I am examining supersedance in my environment as its causing some havoc. Are you saying patches get superseded but leave vulnerabilities from early cve/kbs?
We are running into this issue as well we patch Windows one cycle out, so October's patch went into production in our November's downtime, and run our vulnerability scans at the end of the month. what we are finding is that when I look at missed patches I look at missed patches from the month before ( so in November I was looking for September patches missed) but as every new patch from Microsoft superseded the previous patch, I'm having issues getting an accurate number of missed window's patches, when trying to reconcile with our patch management solution. How are you or others dealing with this?
you could create a patch report or a normal report, but use a custom Search List with a published time criteria for the month you care about like this:
the answer is environment and audience specific. no one answer is best. If you want to brief non-actionable information to admins mixed in with what they actually would need to do to resolve the issue as a whole then do so. I prefer to only show actionable vulnerability information, that means excluding non-running kernel based detection's and though not always reliable superseded patches.
Specifically with Microsoft patches, superseded patches generally get updated into the relevant QIDs, but sometimes they get missed and false positives appear.
Retrieving data ...