Blog post

Revisiting Vulnerability Assessment and Vulnerability Management Research

By Anton Chuvakin | August 07, 2015 | 2 Comments

vulnerability managementsecurityannouncement

Together with our new team member, Augusto Barros (blog, Twitter), we have embarked on an update to Gartner GTP vulnerability assessment (VA) and vulnerability management (VM) research. Let me tell you, we have some awesome plans!

First, here are the key documents we have on the topic (only GTP documents listed):

We are planning to overhaul our guidance in how to do both VA and VM right, refresh our tool coverage of “vendors that matter” and create 3 documents, along the lines of:

  1. Vulnerability Management Process Implementation Guidance – how to run your entire VM capability/program, remediate, mitigate and beat your server ops people into submission 🙂
  2. Vulnerability Assessment and Security Configuration Assessment Implementation Guidance how to scan/assess correctly, to get the best value of VA tools, analyze report data, etc
  3. Vulnerability Assessment and Security Configuration Assessment Tools Comparisons – how to compare VA tools right, pick the right capabilities, etc

Among other things, we plan to touch on what VA vendors are doing to address challenges with public cloud environments (IaaS, PaaS, SaaS), mobile devices as well as (NEW!) IoT and OT devices. We are also working on a new vulnerability management process guidance, that would be roughly 37% more actionable 🙂

And here is my CALL TO ACTION:

  • Vendors, got anything to say about vulnerability assessment? Here is a briefing link … you know what to do!
  • Enterprises, got a fun VA/VM-related story to share – both WIN stories or FAIL stories will do fine? Hit the comments or email me privately (Gartner client NDA will cover it, if you are a client).

Past posts on vulnerability management:

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • Andre Gironda says:

    From the ground floor, most practitioners dislike the way that managers engage with vulnerability management programs. Managers like to play whack-a mole a lot.

    First of all, never count the number of vulnerabilities for anything. For those truly married to the accounting method of IT, at least enumerate the number of weaknesses (CWE) or attack paths (CAPEC) that plague your environment instead of listing CVEs or calculating CVSS. Then rate those by risk using FAIR, NIST SP 800-30 or similar. You can’t rate CVEs in the same way!

    You need security professionals who are skilled enough in metasploit-framework and Burp Suite Professional to explain which vulnerabilities lead to which exploit scenarios. Documenting vulnerability information is key. Your environment and your budget defines the next steps, whether it’s loading all of your host, service, vuln, and credential information in a tool like lair-framework (FOSS) or Dradis (FOSS and supports IPv6 networks). Even Cisco has a FOSS tool to do this called KvasirSecurity. Some orgs may want huge commercial efforts such as ProVM Auditor, CORE INSIGHT, or Immunity Security SWARM, but most, if they want anything commercial at all, can do by with cloud solutions like Dradis Pro or Kenna Security — especially when dealing with external, directly-Internet-facing infrastructure.

    The fully-integrated solutions such as OpenVAS or aschmitz/nepenthes (FOSS) — or even the more-popular Qualys QG, Tenable, and Tripwire commercial solutions are too much — they don’t allow the vulnerability data to become useable — only leaving the data to sit in repositories of useless information that form a bad basis for risk communication, let alone risk prioritization. This is the common, “too early, too often”, overly-integrated model for vulnerability management programs you see today: all hat and no cattle. What is really bad is something like RSA vRM. Don’t integrate vulnerability management to GRC portals. GRC portals are great for intelligence-led CND programs (see the book, “Building an Intelligence-Led Security Program”), but for other reasons. You have to vet this data before you can use it for anything. Stop boiling the ocean!

    • Thanks a lot for the comment — sorry for a delayed response [I am away at a conference!]

      I’d argue with your metasploit advice. I’d rather just see “yup, there is an exploit” rather than try to metasploit it, fail and then assume it is safe.

      How is OpenVAS “fully integrated”? What is integrated with what, precisely?

      Also, why are you “pro kenna / risk IO” but “anti VRM”? I’ve seen people accomplish roughly similar things with them… IMHO, VRM split away from their [nasty, naturally] GRC roots a bit….

      BTW, thanks for Dradis pro reference — I never heard about them and now I do. I may owe you a beer here 🙂