Guinea Pig and Vulnerability Management products. 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:

1. Understand detected vulnerabilities in details, the sense behind the text description
2. 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:

1. Understand the practical steps how a vulnerability can be fixed
2. 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.

Alexander Leonov

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, первым делом теперь пишу туда.