Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
1509 Views 11 Replies Latest reply: Feb 13, 2013 7:57 AM by John M Sopp RSS 1 2 Previous Next
John M Sopp The Place at McAfee Member 88 posts since
Nov 17, 2009
Currently Being Moderated

Jan 22, 2013 1:45 PM

"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?

  • Community Leader 479 posts since
    Nov 3, 2009
    Currently Being Moderated
    1. Jan 25, 2013 5:52 PM (in response to John M Sopp)
    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!
    Cathy

  • vfguy11 Newcomer 25 posts since
    Oct 17, 2012
    Currently Being Moderated
    2. Jan 28, 2013 6:00 PM (in response to cgrim)
    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.

     

    Thanks.
    Joe.

  • Community Leader 479 posts since
    Nov 3, 2009
    Currently Being Moderated
    3. Jan 28, 2013 6:08 PM (in response to vfguy11)
    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. 

     

    Thanks!
    Cathy

  • vfguy11 Newcomer 25 posts since
    Oct 17, 2012
    Currently Being Moderated
    5. Jan 31, 2013 10:16 AM (in response to John M Sopp)
    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.

  • edburns Newcomer 16 posts since
    Jan 4, 2013
    Currently Being Moderated
    6. Feb 1, 2013 12:26 AM (in response to John M Sopp)
    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.

  • vfguy11 Newcomer 25 posts since
    Oct 17, 2012
    Currently Being Moderated
    7. Feb 1, 2013 10:12 AM (in response to edburns)
    Re: "Fixable by patch" vs "fixable by other means"

    edburns,

     

    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.

  • darrenthomas McAfee Employee 2 posts since
    May 23, 2011
    Currently Being Moderated
    9. Feb 12, 2013 6:23 PM (in response to John M Sopp)
    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.

     

    Thanks

     

    Darren


    Darren Thomas
    Sr. Product Manager, Vulnerability and Discovery
1 2 Previous Next

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 5 points
  • Helpful Answers - 3 points