IMHO, security vendors use the term “Vulnerability Management” extremely inaccurate. Like a guinea pig, which is not a pig and is not related to Guinea, the current Vulnerability Management products are not about the actual (practically exploitable) vulnerabilities and not really about the management.
Vulnerability should mean something solid and reliable, something that can be practically used by a malicious attacker or penetration tester.
When (so-called) Vulnerability Management vendors start working with indirect information from third-party about potential vulnerabilities in the software, that were possibly exploited by someone in some unknown conditions, or simply distance from responsibility: “we just provide information from the software vendor; software vendor knows better about the vulnerabilities in his own products”, it’s all falling into to the area of fortune telling and counting angels on the head of a pin.
Hardcore process of identifying weaknesses that real-life attackers can use moves to a boring compliance. For example, as PCI DSS requires, there should be no vulnerabilities above medium level (CVSS Base score > 4). At the same time, no one cares how fair this assessment of criticality is or how real these vulnerabilities are. All the analytics build on such formal data loses its sharpness and practical value.
Management implies some variability of actions. And if the solution in 95% of cases is “update the software” (it won’t be worse) or “configure the software” (it won’t be worse either), then this is not management, but oldie-goldies from Captian Obvious. And, of course, doing nothing is also an option, it can be even called “risk acceptance”.
Regular updates and hardening are, of course, great and important. But is it really necessary to prove this by active scanning constantly? Does this really help reduce the the unnecessary work for IT? I think not really, but, let’s leave this for another post.
More suitable name for the VM products that we have right now
IMHO, the current “Vulnerability Management” products should be called differently. With a strong emphasis, that it deals with potential vulnerabilities. Maybe something like “Potential Vulnerability Modeling” or “Patch Management Validation“. Because this is what such systems can actually do: not to find the real vulnerabilities, but to detect process violations, to show that admins or devops don’t update their hosts systematically .
What should the real (NG?) Vulnerability Management systems do?
Real Vulnerability Management solutions should, of course, go much further than this.
From the Detection side they should:
- Understand detected vulnerabilities in details, the sense behind the text description
- Offer practical scenarios of exploitation for a specific environment of a particular organization and (optionally) exploit this vulnerabilities
In other words, the main content of their knowledge bases should not be exploit, not a detection script generated from the patch description. Vulnerability Management system must understand how each vulnerability in the knowledge base can be exploited.
And from the Remediation side they should:
- Understand the practical steps how a vulnerability can be fixed
- Update the hosts automatically, integrating with automated (regression) testing systems
Such Vulnerability Management system should, if not replace the human analyst entirely, to solve most of his routine tasks.
Hi! My name is Alexander and I am a Vulnerability Management specialist. You can read more about me here. Currently, the best way to follow me is my Telegram channel @avleonovcom. I update it more often than this site. If you haven’t used Telegram yet, give it a try. It’s great. You can discuss my posts or ask questions at @avleonovchat.
А всех русскоязычных я приглашаю в ещё один телеграмм канал @avleonovrus, первым делом теперь пишу туда.
There are some solutions which try to calculate risk level based on info from vulnerability scanners, inventory and network configuration. So you can prioritize findings and patch exploited vulnerabilities first. We’re going to try one such tool, called Skybox.
Hi Artem! Sure, for example Kenna that, I reviewed it in “Kenna Security: Analyzing Vulnerability Scan data“. But this again confirms the fact traditional Vulnerability Management vendors are not good enought in their job and it is necessery to perform a lot of additional analysis and data enrichment operations to make scan data more actionable.
Technically, ExploitDB has the fields and capability to serve as this exploit knowledgebase you describe, but after researching hundreds of entries at random, I’ve concluded that it’s entirely unreliable. It lists privilege escalations as remote code execution and vice versa. It lists vuln checks as exploits. ExploitDB, along with the rest of the industry’s vulnerability knowledgebases and databases are obsessed with quantity over quality.
Garbage in/garbage out.
At some point, we have to either start from scratch or clean up these knowledgebases – I don’t see any other way forward.
Adrian, exactly! Thanks for comment! Each exploit needs to be verified: compiled, run against a vulnerable host, changes on the host should be recorded and documented, etc. This is of course a nuch more complicated work than collecting some unverified code. I hope that somewhere there are private exploits databases that are much more reliable. 🙂
Pcysys.com does exactly what you described above.
I prefer to use the terms “Vulnerability Assessment” (the identification of potential vulnerabilities) and “Vulnerability Management” (Prioritization of workflow, risk evaluation, and remediation tracking)
Pingback: What’s wrong with patch-based Vulnerability Management checks? | Alexander V. Leonov
Pingback: MIPT/PhysTech guest lecture: Vulnerabilities, Money and People | Alexander V. Leonov
Pingback: No left boundary for Vulnerability Detection | Alexander V. Leonov
Pingback: Vulnerability Management at Tinkoff Fintech School | Alexander V. Leonov
Pingback: Vulnerability Management vendors and Vulnerability Remediation problems | Alexander V. Leonov