Thank you for the reply.
I use vuln-sets with rules, which limits the number of rules I can have to be able to exclude the vulns (currently, we exclude 300+ vulns for which there are no fix available).
We don't use the ticket system. I will look more closely at that option.
Basically my issue is this - I want the scan report to show ONLY those vulns for which a patch is available. Otherwise, it "confuses" the build team. ;-)
fromy my exprince you will never end by removing the signature that dosent have fix information also you nedd time to time review the removed signature to see if any updates on the recomendation.
i have log a support request and they ask to raise FMR for this feature and hope to see it in future release.
That is one of the problems I'm having. I just recently took over admnistration of the MVM environment.
After a scan is performed by my group, it's imported into an access DB and the "no fix available" are filtered out. Unfortunately, the filtered list wasn't kept up on. I just audited it and 82 of the "ignores" now have a patch available!!!
Since the MVM database has the status of each vuln in it (0-3), it should be easy to automate the ignore list. If a rule was created to ignore all vulns with a status of "2" (no patch available), then when an update was issued and the status changed to "1" (patch available) it would automatically start reporting on that vuln.
My other issue (for which I originally posted) is that the build guys, who pre-scan their systems, aren't the most diligent. They get a MVM report with 15 vulns, and can't pick out the one they need to patch.
Yes, I'm trying to find a technical fix for a "personnel" issue...
I figure if I can get a report produced that filters out the crap and only has the "patch this, stupid" list left, it "might" help... :-)
Hopefully your request will be added in a future release.
If you're new to MVM and the 'fix available or not' issue, you'll want to see John's post from January on
'How do you do it: Reporting Vuls with Patches available vs vulns without patches available.'
You may see the link over on the right under 'More Like This.'
With regards to the ticketing system:
'Ignoring' a ticket will cause a vulnerability to no longer show up in a scan report, at least until the ticket ages out. (That is my understanding; someone can correct me if I'm wrong.)
However, the vulnerability will still show up in an asset report. In other words the ticketing system can help you to adjust the results of scan reports, but not asset reports. That gives you one report that shows the 'ignored' vulnerability, and one that doesn't, which is sort of what you were saying you want.
Another feature you might be interested in is/are the McAfee non-superceded patch vulnerability sets. See John's thread (the one I mentioned above) for more discussion of that.
Message was edited by: jldunn on 11/14/12 2:22:16 PM CST to add mention of the other discussion and for clarity.
This is very good info. thank you.
I don't know what "filtering" the poster is referring to in method 1.
We do that "externally" now via an access db, but rather than filter on "keywords" it filters out anything that isn't in the faultline db as a "patch available" using the code#
That's exactly what I want to do IN MVM.
I'm closer to my goal.
I figured out that I can specify in my ruleset that "patch availability equals patch available"
I still don't see a way to exclude a list of things by FID for which we've granted exceptions. We do that in the access db as well.
The problem is that the build guys don't have access to that access db. I'm trying to figure out a way to get them access, but that's a whole different story.
Thanks again for the input!