Why is Vulnerability Management Painful and What can We do about it ?

Among all of the security engineering disciplines, vulnerability engineers have probably the most power as it is one of the rare security disciplines where standards exist to calculate severities and compliance standards come with pre defined SLA.

With that great power comes great responsibility and if not used well, makes the organization work on wrongly prioritized vulnerabilities (and miss the 'right' ones to fix).

Vulnerability management is an established category in security vendor space and there are lots of big and small vendors. And yet, vulnerabilities from unpatched CVEs is the most growing category as initial attack vector. It is still taking unreasonable amount of time to patch the right CVEs. Why is that ?

There are 4 sides of the vulnerability coin - the vulnerability engineer (or appsec engineer) who understands the risk and exploitability of the vulnerability ; the development engineer who understands the effort to fix (and to maintain customer expectations from the app) ; the customer who is looking to ensure the vulnerabilities are fixed per their SLA before they deploy/use the app ; the auditor who is looking to ensure the same per a standard. Everyone is trying to ensure the right thing is done in their own world, Thats where the games begin.

How many times does a security team made the development team fix an exploit thats highly unlikely because of its per policy ? How many times the development team refused to upgrade to latest and put band aids in to reduce the point blank vulnerabilities ? How many times did the security team got forced to accept risk on something that they are not comfortable with only to get called out by a customer ?

The mismatch of expectations comes from the data that is needed to take the right decision and elevating that data to all the teams so each member is seeing the same items when they talk about risk.

Lets take the example of the recent OpenSSH vulnerability, and see what that data is, and what the right decision is.

The vulnerability management scanner will report the vulnerability as high to almost critical. as an unauthenticated attacker can exploit the vulnerability over the network. Though shall fix it with in 15 days dev team.

a little bit more data indicates there is an exploit - and customers are asking about it because it got some press. the security team is on hook to make the dev (or infra) team fix it , stopping the feature sprint.

a little bit more data indicates that the POC does not work .

lets look at the exploit more closely . the attacker would need a lot more information about the server side, not as easy for 'un authenticated attacker' can exploit the vulnerability

Only 32 bit systems are vulnerable

And there is a work around for the vulnerability.

Looks like i can put in the detection measures to examine attempts .

and there are mitigation measures

Imagine a call where the appsec , dev, infra teams got on a call with all the above data in front of them.

a) i dont think there will be wide disagreements on what the right decision(s) is, whether to fix some systems right away or whether to put detection measures in place and fix it in quarterly patching or whether to put the work around in place etc

b) even if there are disagreements, the decision will get made with wide open eyes, the risk easily explainable to customers and auditors

"Democratization" of easily consumable, exhaustive vulnerability information would save an organization prioritize and work on the right CVEs , cause less friction among teams and enables the organization to explain the risk to stake holders.

The problem though is that the information is not available in the vulnerability scanners and it takes hours of time to read and make judgement calls about the vulnerability, about the exploit, about assets on which the vulnerability exists, about the way the code is packaged etc.