Showing results for 
Show  only  | Search instead for 
Did you mean: 

"Fixable by patch" vs "fixable by other means"

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?

11 Replies
Level 13
Report Inappropriate Content
Message 2 of 12

Re: "Fixable by patch" vs "fixable by other means"

Hi John,

Your question looks a lot like this one:

"Patches vs. Workarounds"

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.

stay tuned!

Level 9
Report Inappropriate Content
Message 3 of 12

Re: "Fixable by patch" vs "fixable by other means"

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.


Level 13
Report Inappropriate Content
Message 4 of 12

Re: "Fixable by patch" vs "fixable by other means"

Hi Joe,

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. 


Re: "Fixable by patch" vs "fixable by other means"

The best we came up with so far is a keyword based'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.

Level 9
Report Inappropriate Content
Message 6 of 12

Re: "Fixable by patch" vs "fixable by other means"

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.

Level 7
Report Inappropriate Content
Message 7 of 12

Re: "Fixable by patch" vs "fixable by other means"

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.

Level 9
Report Inappropriate Content
Message 8 of 12

Re: "Fixable by patch" vs "fixable by other means"


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.

Re: "Fixable by patch" vs "fixable by other means"

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)

McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 10 of 12

Re: "Fixable by patch" vs "fixable by other means"

Hi Everyone

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.



You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community