Your question looks a lot like this one:
I don't have any "out of the box" ideas for you... but I know some ideas are getting tossed around internally. I just don't know yet how likely it is. Seems to be a rather complex problem.
John, that's what I do as well. The scan results are sucked into MS Access and filtered out as follows:
DoCmd.RunSQL "DELETE * from tblvulnerabilities WHERE ([Recommendation] LIKE '%is not aware%' OR [Recommendation] LIKE '%is unaware%' " & _
"OR [Recommendation] LIKE '%has not released%' OR [Recommendation] LIKE '%is not available%' OR [Recommendation] LIKE '%is currently unaware%' " & _
"OR [Recommendation] LIKE '%no patch is available%' OR [Recommendation] LIKE '%has not provide%') AND ScanID=" & ScanID
Like you said, not perfect, as there are some errors in the spelling of the keywords.
Seems to me the solution is to add a new code for "vulns with a patch or workaround" and add the corresponding option in the rule-set. Another option would be to break out the single field into multiple t/f fields for each possibliity patch, workaround, no patch available, n/a, and other.
We've also encountered this issue as well..the ideal solution is for McAfee to maintain the "patched" database field as it was initially intended. However our workaround is that we have a custom database with a table containing a copy of the vulnerability information (faultlineID,Vulnerability Name, Patched, X, Y, Z) in content.vuln -- and run a job to ensure this table stays synchronized and up to date with MVM's DB.This table has all the vulnerabilities within content.vuln and when we see a patched value that does not match the recommendation or we know does have an available patch,
I would like to see McAfee manage and maintain it's database fields more consistently. For instance the supersededID value in content.vuln would be beneficial if it followed it's outlined intention as per the MVM DB Schema.
vfguy11 - What exactly is PAC? I would like to get involved in this group if it resorts in being able to expedite some of these issues we face as customers & providing valuable feedback to McAfee on where to focus their development efforts.
I disagree with your assessment that the "the ideal solution is for McAfee to maintain the "patched" database field as it was initially intended." (i.e. nothing). That doesn't address the issue. I'm not privy to what "it was initially intended" with the patched field in the content.vuln table, but it would seem that it was to differientate between classes of vulns:patched, no patch available, unknown and n/a (whatever that means). A workaround is a method of addressing a vulnerability and should be called out. Maybe in a new field. I don't care how it's implemented, but as I said before, the goal is to address security issues.
You say that you use an external DB to indicate to you when there is a patch value that doesn't match the recommendation. It sounds like you're doing something simlar to what I posted above. However there are spelling errors that don't always get caught (I've validated this). Matching a text value to a number value is just ugly. While we can certainly work around the shortcomings of issues in MVM by creating external databases, that's not a "solution" for this particular issue.
Your issue with the supersededID is a completely different issue from the one that has been discussed here for which you can submit a PER.
The PAC is McAfee's Product Advisory Council. I don't know how you get invited to that.
Darren here, the Product Manager for MVM. Thank you all for your posts and contributions to this subject. Here is how we are currently treating patches/workarounds within the product and the associated workflow.
Patch Status Information
0: No information available
1: Patch exists - a binary or installer exists to fix the issue
2: No Patch exists - no binary or installer exists to fix the issue
3: N/A - these are informational or policy checks
In terms of workflow here is how the content is delivered and updated
1) If a patch is not available and there is a formal workaround from the vendor, then this information will be recorded in the recommendations section.
2) If a patch and a formal workaround exists then only the patch information is recorded
3) If a patch later becomes available (for example after a 0 day) then the patch information replaces the workaround recorded in the recommendations section
I hope that helps clarify how we are treating this complex issue. We are looking at ways of refining this so that the information becomes clearer, in light of the use cases listed above.
Joe and John - I will work with you through email and the PER system on this complex subject and keep you updated.