Blog

The Subjective Nature of a CVSS Score

A CISO’s Perspective

During a recent internal threat modeling exercise, a member of the Eclypsium team discovered that a vendor had mis-scored a few related vulnerabilities across a consumer/enterprise grade product line. The vendor presented these vulnerabilities as a CVSS severity of Medium when our understanding of the issue resulted in a High. The vendor under-scored the Access Vector and Scope categories of the CVSS calculation. Adjusting these based on our understanding of firmware resulted in a CVSS of 8.2 (High) with a corresponding Vector String of CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

The vendor’s score reflected what Eclypsium frequently encounters when speaking with others about firmware-level vulnerabilities and subsequent risks:

  • An assumption that firmware attacks require an Access Vector of Physical. In this case, the attack could leverage a completely software based exploit because parts of the affected firmware are stored in physical memory.
  • An assumption that the Scope of a firmware vulnerability is Unchanged. In this case, the consequence of exploitation would include arbitrary code execution in other firmware components which is not traditionally available to an operating system.

These two significant adjustments shift the attack surface drastically to now make this vulnerability ripe for weaponization in malware with very real ability to do harm. While this interpretation of the attack requires privileged access, the ability to chain a traditional escalation of privilege attack to get to administrative privilege is not difficult to imagine.

I’ve chosen not to call out the vendor specifically. There could be several reasons why the vendor may have published this score ranging from innocently making a data entry error, to a lack of understanding of current attacker capabilities, to intentionally playing down the severity of this issue. This discovery led to an extended internal conversation with my threat intel team and our subject matters experts on the potential downstream consequences of this situation.

From my perspective as a CISO, the potential importance of a CVSS score cannot be understated when you consider the role it plays in many risk and vulnerability management systems.

  • Risk Management. While the authors of CVSS specifically claim “CVSS Measures Severity, Not Risk,” for some organizations risk procedures leverage the Base CVSS score to triage the risk a vulnerability presents; the lower the score, the more time an organization may allow itself to formally assess the risk.
  • Source of Truth. Absent firmware expertise in house, you could also run into conflicting reports. For example, CVE-2020-8708. If your source of truth is NVD, this is reported as a High 8.8; whereas Intel reports this as a Critical 9.8.  The difference in score is based upon decisions about the Scope. It may be worth touching base also with your vulnerability scanner solution vendor to see which they trusted as well.
  • Vulnerability Management (procedural). Most organizations have internal timelines for mitigating vulnerabilities in their environment based upon the CVSS score. These timelines may be derived from internal risk appetites or imposed upon them by customer obligations or regulatory guidance. Regardless of how timelines are established, most still have a substantial difference in time to patch or upgrade a Medium and High vulnerability. This delta presents a window of opportunity for attackers who can weaponize these vulnerabilities.
  • Vulnerability Management (technical).  Most vulnerability management programs leverage some technical solution to scan their environments. Embedded in the presentation and reporting functions of these solutions is often a “risk score” that frequently correlates with the base CVSS score. Consequently, the incorrect severity of a vulnerability is carried over into reports, metrics, and response. Organizations lacking the resources to scrutinize vulnerabilities will often consider their vulnerability scanning tools to be single sources of truth for this aspect of their risk posture.

Our internal conversation continued across many thoughtful tangents involving vendor trust, ultimate accountability for understanding the risk to an organization, the risk of accepting technological sources of truth, and of course the CVSS scoring model itself (which we unilaterally all still consider a valuable tool for the community to leverage when discussing vulnerabilities).  All deeply interesting discussion perhaps for another time.  

What are your thoughts? Is the mis-calculation of a CVSS score a concern? Let me know.