It is 2015 – so how come we don’t know which system vulnerabilities to fix first?! Depending on how one counts, the first vulnerability assessment (VA) tools (aka “vulnerability scanners”) appeared in 1994-1995, i.e. 20+ years ago. In “IT years” this is like 2-3 universe lifespans :–). The joke – that is soooo not funny to many in IT – about “scan, make a report of 100-500 pages, toss it over the wall to ops – and then pray” has persisted for too long…
In any case, a skeptic [and….aren’t we all in infosec?] may say that this unsolved problem is a part of a bigger – but just as unsolved – problem of risk measurement. Many organizations simply do not know what their top risks are, thus it is reasonable that they also don’t know what their top vulnerabilities are. Still, I want to focus this post at the vulnerability management (VM) domain, rather than at the overall risk.
As my esteemed colleague Augusto Barros pointed out in his recent post on VM, vulnerability management just hasn’t changed that much over the years. Thus, some of the problems of vulnerability management that were acute in, say, 1997 are still very painful now – more painful, in fact, due to much larger IT, BYOD, cloud, mobile, OT, IoT, etc.
Back in 2011, we tried to summarize some of the vulnerability prioritization methods people can use to actually rank their vulnerabilities in a more useful manner (this is also featured in more recent GTP research on VA/VM). I am saddened to report that most organizations still seem to go by “fix the HIGHs, ignore the rest.” While the literati criticize the CVSS as a sole means for prioritization, I am even sadder to report that CVSS is a mere dream for those still struggling to fix only the HIGH severity issues….
There you have it – another log thrown into a security bonfire of cynicism 🙂
Past posts on vulnerability management:
- Revisiting Vulnerability Assessment and Vulnerability Management Research
- 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
I think there is a missing piece to this puzzle – the ability to deploy the necessary patches. This is key part of the problem, if you cannot deploy more than a few patches in a change window why identify more than a few patches for deployment. If rolling out software changes in an environment is difficult or problematic, you would focus your effort on the high priorities patches first.
In effect, the downstream process is exerting back pressure on the upstream process. Making change control, system configuration management and software deployment easier or less costly in time and resources will provide the means to solve the vulnerability management problem.
Alex, thanks for the comment — indeed, there are plenty of pieces missing for many orgs. I agree that an ability to push patches quickly and safely — anything that can increase the downstream process bandwidth would be super-welcome