Vulnerability management – we’re doing it wrong

Security professionals (and the people who measure our performance like auditors and regulators) have traditionally taken a stance that “all serious vulnerabilities should be patched” and that the way to decide whether a vulnerability is “serious” is to look at its Common Vulnerability Scoring System (CVSS) score. If the vulnerability gets a CVSS score of 7 or higher, it is “serious” and “must be remediated.”

As a result, many security folks spend much of their time reading vulnerability scanner reports and browbeating our operations colleagues into installing patches and updates. When we see a report with no Critical or High issues noted, we “know” we are secure (and that our auditors will be happy ). Job done. Miller Time.

Unfortunately, in many cases, we’re getting it wrong, creating lots of pointless work for our colleagues AND diverting resources from finding and fixing real security issues. No wonder we never get invited to parties.

Problem 1 – We’re using CVSS wrong

CVSS scores were never meant to provide a one stop assessment of the risk of software vulnerabilities – this fact is spelled out in the CVSS documentation. It is tempting to try to use CVSS as an easy peasy prioritization mechanism. We can all understand that a 9.8 vulnerability is “worse” than a 6.7 vulnerability and “must” take priority. And not to pick on auditors, but using the presence or absence of high scored vulnerabilities as a measure of how effective an organization’s vulnerability management program (and by proxy its entire security program) makes their reports easier to write and digest.

Unfortunately, relying on CVSS scores does not reveal the actual risk posed by specific vulnerabilities in specific implementations, or account for the operational and business risks of applying patches and updates, or the opportunity costs of expending time and resources on patching what can sometimes end up being very low risk vulnerabilities. Conversely, a vulnerability with a low CVSS score could be potentially disastrous for a specific business process within a specific organization.

CVSS scores are useful when viewed as one factor amongst many used to determine patching priorities, but relying on them to provide total guidance is risky both from security and operational efficiency standpoints.

Problem 2 – The vulnerability tsunami

We are drowning in software vulnerabilities. According to tracking site, there were just over 16,500 vulnerabilities assigned CVE numbers and CVSS scores in 2018. In 2021, the number topped 20,000 and looking at statistics for the first half of 2022, it is possible that security teams could have close to 25,000 vulnerabilities to deal with this year. While most vulnerabilities score below 7 on the CVSS scale (about 80% in 2021 and 2022), this will still leave many organizations with dozens to hundreds of “must patch” vulnerabilities to address every year if we rely strictly on CVSS scoring.

Patching and updating has costs and risks which are just as real as the security risks of not applying needed vulnerabilities:

  • Systems need to be taken down and restarted, potentially making them unavailable.
  • Personnel who could be working on other tasks need to be redirected to patching tasks, sometimes with little notice and with impacts on other tasks and projects.
  • Overtime takes a financial and morale toll on the organization.
  • Systems need to be tested to ensure that the patches didn’t break existing functionality. If they did, fixing the problems or rolling back patches can take time and effort.

If the patch or update is really necessary to prevent a security incident, all of this impact and risk is worth it. However, since CVSS scores don’t (and are not meant to) provide a one stop metric for risk, much of the effort organizations spend on chasing a “clean” vulnerability scan report is wasted “security theater” which provides the organization with a false sense of security and accomplishment and distracts limited attention and effort reserves from finding and fixing real security issues.

In my next post, I’ll take a look at some of the other factors we can add to the vulnerability assessment process that can focus our efforts on the vulnerabilities that actually pose risk to our organizations.

Leave a Reply