A few days ago I met somebody who holds a fairly fatalistic view of Vulnerability Assessment (VA) and, to a lesser extent, broader Vulnerability Management (VM) as well. In fact, this person believed that VA is an utterly pointless endeavor. After all, they said, you can be:
- Not patched and hacked
- Patched and not hacked
- Not patched and not hacked [because there are so many vulnerabilities out there]
- Patched and still hacked [via social engineering, phishing, zero day or an asset not covered by your VM program]
So, they asked, why bother focusing on your vulnerabilities at all? Is this all “compliance B.S.” and not “real security”? Is being vulnerable even correlated with being compromised or breached?
Let’s consider it! Is there truth in it, or is it Fake News?
First, we all agree that a vulnerability assessment is in fact AN ASSESSMENT. Assessments lead to knowing something, rather than becoming something. After you’ve done your (annual, monthly, weekly, daily, continuous) vulnerability scan, you are precisely 0.000% more secure than before said scan.
With this out of the way, what about vulnerability MANAGEMENT? Our data indicates that for organizations that equate occasional patching with VM, the situation is not much different. Fixing even some issues costs real time/money, and often the issues fixed do not affect the attacker at all.
However, we also see that “VM that works” does exist. At least, VM that makes the attacker work much harder and hence possibly make more mistakes does. The difference between “VM that works” and “busybody fake VM” is in the logic used for prioritization of what to remediate (such as patch) or mitigate (such as shield with a NIPS or a WAF)
- Vulnerability assessment has absolutely no security value … unless you utilize the results to reduce your risk.
- Vulnerability management done without significant thinking about remediation priority may in fact also be pointless (vs the labor spent).
- However, ”risk-based” vulnerability management does deliver real security value – as long as you actually practice it!
BTW, if you have a Gartner subscription, check out this new paper (it has such gems as “By 2022, approximately 30% of enterprises will adopt a risk-based approach to vulnerability management.”)
Finally, this teaches us a lesson: RESIST scanner vendor suggestions to “scan more” and “scan often”, and INSIST on better analytics for result prioritization!
- We Scan and We Patch, but We Don’t Do Vulnerability Management
- Vulnerability Management #1 Problem – After All These Years!
- Our Vulnerability Assessment Vulnerability Management Research Publishes (2017)
- Revisiting Vulnerability Assessment and Vulnerability Management Research
- WannaCry or Useful Reminders of the Realities of Vulnerability Management
- My Updated Vulnerability Management Practices Paper Publishes (2014)
- Cannot Patch? Compensate, Mitigate, Terminate!
- What is Your Minimum Time To Patch or “Patch Sound Barrier”
- Patch Management – NOT A Solved Problem!
- Next Research Project: From Big Data Analytics to … Patching
Read Complimentary Relevant Research
Three Critical Factors in Building a Comprehensive Security Awareness Program
Three key elements form the foundation of a successful awareness education program: knowledge of audiences, pervasive and continuous...
View Relevant Webinars
Serialization Building Blocks for a Supply Chain Digital Strategy
Serialization (enabled and embedded bar codes and data capture technology) has now traveled full circle from being considered a specialized...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.