Just wondering if anyone was able to scheme a way to farm out the vulns for which a patch(or future patch) is the remediation vs those where a config change is a remediation.
I attempted to use the CVSS remediation level as well as the mvm database field "patched" but neither really gives me what I am loking for..
Any outside of the box thinkers out there with a solution they would like to share?
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.
Hi Cathy, I've registered for the PAC. Any chance that these discussions extend to that group? I'd be very interested in helping and understanding the complexity of the issues.
I've never been part of the PAC - so I can't say for sure. I think that's really the whole purpose though: To influence PM and Development about which direction the product needs to go in.
The best we came up with so far is a keyword based search..it's decent, but Not a perfect science..
I put in a PER for this but I haven't had a great deal of success getting viable solutions after submitting PERs.
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,
we change that flag in our custom db table. That way when doing custom reporting via SQL queries you can just join in that custom database and table for your where clause condition. However, this solution would not work if you rely purely on the Foundstone Console for generating reports. We also use this approach as we need a solution to not only indicate if there is a patch available but to capture the date when a vulnerability changes status from no patch available to patch available (often the case when Oracle vulnerabilities are released there is a period of time prior the patch being available). This way we don't start the remediation clock until there is a way to remediate the finding.
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.
FYI I have also submitted PERs for botht he superseded ID issue, and the "fix status issue" discussed in this thread SN#s 8486,18106)
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.