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)
So:
- 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!
Related posts:
- 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
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
5 Comments
I suspect that the hesitancy to embrace VA and VM may be due, in part, to the sheer volume of vulnerabilities that organizations uncover with a VM program. To your point, without taking a risk-based approach to prioritizing remediation, patching, and compensating controls, it can be overwhelming to stare down a [sometimes very] long list of to-dos. Risk-based VM is the most effective way to whittle down that overwhelming list of to-dos into a realistic, and impactful, plan of actions.
Thanks for the comment, indeed we’ve seen people start VA and their day 1 list has 100,000 entries..
To be fair, replace “vulnerability *” or “patched” with “security,” and the same principle holds. It’s a pretty meaningless approach to a discipline that only exists when there is insecurity. Security isn’t a puzzle with a correct answer and then you’re secure. This sort of view is my old view on “security religions,” where some people will hold that a measure is useless when it isn’t perfect, and if it’s not perfect, it’s trash.
There are countless reasons/examples why improving your vulnerability situation will lesson the impact of events (less systems pwned?), reduce likelihood of events, improve response (less junk), even improve awareness as it promotes inventory and discovery tasks. Even fixing many issues makes the process better; it might mean fixing some low risk items, but it makes it easier to fix higher risk issues rather than dust off old procedures that probably don’t exist when another struts vuln is announced.
Well, for sure, we still see this crowd (“some people will hold that a measure is useless when it isn’t perfect, and if it’s not perfect, it’s trash.”)
And
>To be fair, replace “vulnerability *” or “patched” with “security,” and the same principle holds.
Yes, indeed. I suspect any and all ASSESSMENT is only useful as long as you act on the findings (ref pentests, etc)
Great analysis. You hit the point squarely: there’s a difference between learning your state and doing something about it.
Well done, Anton!