Software vulnerabilities are an important component in the complex nature of cyber risks, alongside Darknet exposure and insufficient information security policy and awareness. Vulnerabilities are indexed in a public inventory called CVE (Common Vulnerabilities and Exposures), which contains a key value (e.g., CVE-2022-1234) and description for each vulnerability. Usually the vulnerability itself is referred to as CVE.
There are plenty of known vulnerabilities, and the amount has increased over the years: In 2001 there was 1,677 new CVEs registered; in 2011, there was 4,155 (+247.7% in a decade); and in 2021 the numbers reached 20,169 (+485.4% in a decade). Therefore there is a need to prioritize mitigation and remediation. This challenge concerns IT personnel, CISOs, and everyone within the organization who relates to cybersecurity issues. According to FIRST publication, “firms are able to fix between 5% and 20% of known vulnerabilities per month”, and “only a small subset (2%-7%) of published vulnerabilities are ever seen to be exploited in the wild”.
The ability to make a realistic assessment of the significance of each CVE, its relevance to resources and functions, and its exploitability, is essential for proper prioritization of vulnerability handling by CISOs, and from a cyber insurance point of view for a correct assessment of a client’s cyber risk.
There are several scoring systems dedicated for CVEs. The most known is CVSS, but there are some alternatives that are not as widely used. Here we’ll review some of these systems and discuss their sufficiency.
CVSS
CVSS (Common Vulnerability Scoring System) measures severity based on technical analysis of multiple factors which represent the feasibility, technical difficulty, distribution, and impact of the vulnerability, along with the theoretical value of the compromised resource. CVSS rates CVEs on a scale from zero to ten.
CVSS was criticized as lacking in several aspects. Among the criticism drawn, the use of ratio scales for ordinal scale parameters, which results in a potentially inaccurate calculation of severity differences between cases; a lack of empirical basis for the formula as a standard; a lack in transparency of logics and supports behind the formula; and doubts regarding the validity of the weighting and rating methods.
One of the prominent weaknesses of CVSS is its failure to account for context. Vulnerabilities are often chained by hackers, meaning they exploit one to enable the exploitation of another. In this way a pair of low-risk CVEs in themselves could present a much more dangerous threat. For example, by exploiting CVE-2021-26855 an attacker can get a response from a Microsoft Exchange server with sensitive information including users’ SID (Security identifier). Then, the information can be used with CVE-2021-27065, which is a file writing vulnerability.
Another form of contextual variable is defence mechanisms (like input sanitisation) that prevent implementation of a given/existing CVE.
There are some interesting attempts to develop and offer an alternative or complementary scoring systems, aiming to address the weak aspects of CVSS. Two of them are EPSS and SSVC.
In view of the small proportion of exploitable vulnerabilities, EPSS (Exploit Prediction Scoring System) focuses on feasibility. The system looks at all published CVEs and revises the CVSS score of each, by their probability to materialize. It weights the CVE descriptive features, and base factors from CVSS, but adds to them more findings from the real world. EPSS counts if there are accessible exploits for a particular vulnerability, and to what extent these exploits were used in the field (based on data from AT&T and Fortinet).
EPSS aims to provide accuracy and reduce the scope of vulnerabilities that are considered as requiring attention, so they overlap more and more with the vulnerabilities that are actually exploited.
The practical advantage of EPSS compared to CVSS, with regards to efficiency was demonstrated by First.org. On a sample of 1,000 CVEs with a CVSS score of 8.8 or higher, it was tested how many CVEs needed to be remediated in order to fix approximately 50% of all exploited vulnerabilities, under the prioritisation of each scoring system. With EPSS v2, this coverage rate (50% of all exploited CVEs) was gained by the top 47 CVEs, while with CVSS the requirement was to address 253 CVEs.
SSVC (Stakeholder-Specific Vulnerability Categorization) emphasizes the perspective differences between vendors (patch developer) and asset owners (patch applier, e.g., users). The system focuses on the need for decision from the point of view of the consumer.
SSVC is perhaps more of a framework than a scoring system. It doesn’t produce numerical scores for each CVE, but defines figurative variables and qualitative results, which design dedicated decision trees, that are intended to reflect the way users may see urgency differently than the ones who own the product and should patch the vulnerability.
Decision points include exploitation (whether there’s an exploit in the field) and exposure (whether the user’s network is accessible); technical impact (developer’s angle) and mission impact (user’s angle); and more. The values these variables get should determine the answer to the question of when to patch. The decision of whether the vulnerability demands immediate attention or it should be addressed as part of a scheduled update.
The benefits of SSVC are the clear, discreet assignment of priorities. In some it requires effort to “route” a vulnerability through the tree, that is, to classify and match CVEs to the appropriate category.
As explained, EPSS and SSVC look at the whole record of published CVEs and try to “sort the wheat from the chaff” however this isn’t a complete solution. EPSS does not intend to be used solely, but rather alongside CVSS or another robust scoring system. EPSS excels at calculating probability but does not calculate severity. SSVC provides a framework more than actual scores.
More importantly when combining inputs from multiple scoring systems, there is still a need for further inspection. Every fixed system will fail to consider interference and cross-effects between two or more CVEs, and since concatenating exploits / chaining vulnerabilities is common, this is a significant flaw.
There are considerations that could not be included in a broad system. As articulated in the specification of CVSS v3.1:
Consumers may use CVSS information as input to an organizational vulnerability management process that also considers factors that are not part of CVSS in order to rank the threats to their technology infrastructure and make informed remediation decisions. Such factors may include: the number of customers on a product line, monetary losses due to a breach, life or property threatened, or public sentiment on highly publicized vulnerabilities. These are outside the scope of CVSS.
We suggest a concept of primary, secondary and tertiary vulnerability analysis levels that utilises the insights of the “institutional” systems, the base metrics of CVSS and the probability and perspective optimization that EPSS and SSVC provide. Added to these then a dynamic, hand-made analysis by a team of security researchers providing calculations based on a wide and in-depth collection of Darknet sources and in a way that enables detection, measurement and monitoring of actual trends.
