6 Replies Latest reply: Nov 16, 2012 10:49 AM by vfguy11 RSS

    supressing vuln checks

    vfguy11

      Is it possible to supress reporting of vulns for which there are no known patches?

       

      I'd like to clean up the report that is generated to not show 20+ vulns for which there are no fixes.

       

      Also, I'd like to know if there is the possibility to create an "exclusion list" for vulns for which we have granted exemptions.  I still want to scan for them, just not report them.

       

      Thanks.

        • 1. Re: supressing vuln checks
          subhani

          HI , there are multiple ways . First ,you can go and uncheck the check itself  from Scan Configuration .This is the best Option .Secondly ,use the ticket generation option and than close the tickets by setting their status to Ignored .In that case ,no tickets will be generated  for future scans.

          • 2. Re: supressing vuln checks
            vfguy11

            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.  ;-)

             

            Thanks.

            • 3. Re: supressing vuln checks
              devilson911

              Hi,

               

              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.

              • 4. Re: supressing vuln checks
                vfguy11

                Thank you.

                 

                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.

                 

                Thanks again.

                • 5. Re: supressing vuln checks
                  jldunn

                  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.

                   

                  J. Dunn

                   

                  Message was edited by: jldunn on 11/14/12 2:22:16 PM CST to add mention of the other discussion and for clarity.

                   

                  on 11/14/12 2:31:14 PM CST
                  • 6. Re: supressing vuln checks
                    vfguy11

                    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!