Flipping the Vulnerability Management Model: CVSS → SSVC
Vulnerability Management programs and products often utilize the Common Vulnerability Scoring System (CVSS) as a metric to deduce the severity of a particular vulnerability and make a decision on how to mitigate the vulnerability from being exploited. Organizations may expand the base score that is included with each Common Vulnerabilities and Exposures ID (CVE) by adding additional context to the score using Environmental and Temporal Metrics. These metrics can ingest a variety of signals such as the Exploit Prediction Scoring System (EPSS) or where the system sits in an organization’s infrastructure. These additional signals are very valuable information to help prioritize vulnerabilities, but the scoring system has muddied the waters of vulnerability and risk management.
We should consider changing our approach by using a different model to achieve better results. In this post, I am going to make my case for a shift to a vulnerability management model based on the Stakeholder-Specific Vulnerability Categorization (SSVC) whitepaper from Carnegie Mellon that will help organizations both effectively prioritize mitigation efforts and serve as a basis to measurably reduce business risk.
The Positive Value of CVSS
Both the CVSSv3.1, and the forthcoming v4 which is available for public comment are “framework[s] for communicating the characteristics and severity of software vulnerabilities.” They score several families of metrics to deduce the severity of a particular vulnerability. For the purpose of this post, we will be analyzing CVSSv4 for future applicability. Below, I have described the value that can be derived from the Attack Vector, Privileges Required, and User Interaction metrics. Ideally, we are looking for binary decisions and want to avoid qualitative measurements.
Attack Vector (AV)
This metric reflects the context by which vulnerability exploitation is possible.
This is a critical metric in the CVSS model and to any model that hopes to evaluate vulnerabilities. There are four possible metric values: Network (N), Adjacent (A), Local (L), and Physical (P). When we classify vulnerabilities using this metric, we are saying where an attacker has to sit in the technology stack in order to exploit the vulnerability. This can be useful outside of CVSS scoring. We should be prioritizing vulnerabilities that are remotely exploitable in order to prevent both a foothold from taking place, as well as lateral movement on the network. This shouldn’t be a surprise, as this would result in a higher score in CVSS.
Privileges Required (PR)
This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability.
There are three possible metric values: None (N), Low (L), and High (H). In our model, we want to avoid having to make a qualitative judgment between Low vs. High, so we can simplify this down to True or False. The value here is that if a vulnerability does not need privileges to be exploited, it can be inferred that it is more likely to be exploited since there are less steps to achieve exploitation.
User Interaction (UI)
This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system.
There are three possible metric values: None (N), Passive (P), and Active (A). Again, like with Privileges Required, we want to avoid having to make qualitative judgements, so we can simplify this to True and False for the purposes of the SSVC model. The importance here is that if there is no user interaction required to exploit a vulnerability, it is easier for an attacker to execute, thus more likely to be exploited.
Ordinal Values are not Numeric
The values for each vector are ordinal scales, but are then assigned numeric values. The scoring system then performs arithmetic to determine a severity score. However, we cannot say that a vulnerability with an 8.0 severity score is twice as severe as a vulnerability with a 4.0 severity score. The vALUES used are ordinal, meaning that they are categorical, and the distances between the categories are not known, thus we can not use them in math.
The Negative Value of CVSS
By using CVSS scoring as a base for vulnerability management, we are doing a disservice.
The Common Vulnerability Scoring System (CVSS) is widely misused for vulnerability prioritization and risk assessment, despite being designed to measure technical severity. Furthermore, the CVSS scoring algorithm is not justified, either formally or empirically. Misuse of CVSS as a risk score means you are not likely learning what you thought you were learning from it, while the formula design flaw means that the output is unreliable regardless. Therefore, CVSS is inadequate.
— J.M. Spring, E. Hatleback, A. Householder, A. Manion, D. Shick. “Towards Improving CVSS.”
“[M]ethods such as [CVSS] simply add up multiple ordinal scales to get to an overall risk score…All of these scoring systems do improper math on nonmathematical objects for the purpose of aggregating some concept of risk”
— D. Hubbard, R. Seiersen. How to Measure Anything in Cybersecurity Risk. 2nd Ed. Pg 113–114.
We cannot conduct arithmetic or mathematical operations on ordinal values or labels. It would be like multiplying Orange x Blue x Purple = High.
Additionally, 57% of the top 75% of vulnerabilities with a CVSS v3.x base score are considered High or Critical, which without further context, would require organizations to expedite their mitigation process based on industry-standard remediation timelines. Even with the context of temporal, environmental, or other factors to adjust for severity, it’s basically like starting with the sentiment “half of all CVE-based vulnerabilities require us to patch out-of-cycle, while the other half we’ll ignore or stick into the patching cycle.”
The re-scoring of existing CVEs using CVSS v4 would result in an overall increase of severity scores for existing vulnerabilities. Based on this analysis, it is fair to infer that the distribution of high and critical CVSS scores will continue to rise with version 4, skewing the overall distribution of CVSS scores and further straining prioritization efforts.
Instead of drowning in an ever-increasing number of high and critical vulnerabilities, we must relieve the bottleneck. Instead of using arithmetic on a set of labels to give us a score we must decipher an action from, we want the labels to mean something — a prescriptive action.
Which vulnerabilities (or vulnerability chains — more on this later), warrant expedited action on my part instead of following standard procedure? How can we construct a process that allows us to effectively tackle the rising number of high and critical vulnerabilities that are being reported and scored?
Flip the acronym.
(╯°□°）╯︵ ┻━┻
Enter SSVC
In April 2021, researchers at Carnegie Mellon University’s Software Engineering Institute published version 2.0 of a whitepaper titled “Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization.”
The whitepaper discusses the importance of prioritizing actions during vulnerability management and presents an alternative to CVSS. SSVC is designed to address some of the issues with CVSS by taking the form of decision trees to determine what actions should be taken to address each vulnerability.
Stakeholders in vulnerability management are diverse and this diversity is accommodated in the main functionality of the model. The aim is to improve vulnerability management by framing decisions better through a modeling framework. The framework identifies output actions, inputs, aspects of vulnerability management in scope, aspects of context, and how the model handles context and different roles. The organizing concept of the decision-making procedure is decision trees, which represent important elements of a decision, possible decision values, and possible outcomes. The authors suggest decision trees as a practical formalism for providing widespread advice on vulnerability prioritization.
Instead of relying on CVSS scoring as the base for our prioritization efforts, we should pivot to using an SSVC model. The model allows us to be prescriptive, as long as we codify our decisions into actions.
The paper proposes the first table below, but we should tie a service-level agreement (SLA) timeline directly to these actions to make them more prescriptive:
Decisions, decisions
Decision trees are not only intuitive but also make the decision-making process transparent and explainable. In contrast, CVSS scores can sometimes feel like a black box without delving deep into the (invalid) arithmetic. With SSVC, organizations can see and understand the rationale behind certain actions, which is essential for accountability and informed decision-making.
Another area where SSVC shines is in its incorporation of context. CVSS often falls short in this regard, focusing primarily on technical severity and organizations often just utilize the base score without further context. We know that vulnerabilities don’t exist in a vacuum. The context in which they exist is vital for determining the appropriate response. By taking into account context such as exploit intelligence and systems intelligence in a decision tree, SSVC can ensure more relevant and effective vulnerability management.
CISA’s SSVC
The Cybersecurity and Infrastructure Security Agency has adapted this model into their own publication. However, the actions described are vague and not prescriptive. Walter Haydock has a great write-up linked below and cites many criticisms that I tend to agree with. SSVC models need to have outputs that are prescriptive, and we need to utilize thresholds of data points to make decisions rather than rely on vague, qualitative labels that can be open to interpretation. We can of course interpret what a threshold should be, but ideally we are measuring how well the model is doing and thus adjusting thresholds based on the organization’s appetite for risk.
Decisions and Thresholds
Exploit Intelligence
Exploit intelligence is one of if not the most critical component of a modern vulnerability management program. I am operating under the following definition: Signals from either open-source or closed-source threat intelligence services that provide data on whether or not an exploit for a vulnerability exists or whether or not the exploit has been observed in the wild. I am curious as to the acceptance of this definition, and will happily update it based on constructive feedback.
Exploit intelligence services include CISA’s Known Exploited Vulnerability catalog (KEV), EPSS, Cyentia’s Exploit Intelligence Service (EIS), Mandiant Vulnerability Intelligence, and many more. CISA adds known exploited vulnerabilities to their catalog when there is a clear action for the affected organization to take (so this is not a full list of active exploits, but a good indicator of taking action).
We can ingest data from these services to create threshold’s to base our decision tree on when we think about Exploitability. It is important for organizations to understand that some of these services integrate CVSS vectors and the presence of proof-of-concept (POC) exploit code that is available on ExploitDB, GitHub, or Metasploit. So, if we use the existence of POCs or CVSS vectors as part of another decision in the tree, we may be inadvertently weighting the value of a certain source.
An example decision table for evaluating Exploit Intelligence is below. This is a starting point and should be tuned for model optimization and organizational risk appetite. If anything, it can start the conversation to include Exploit Intelligence in the Vulnerability Management model.
Technical Impact
To simplify the measurement of technical impact to establish a model and provide room for model growth, we can provide a value of Total if the vector string includes VC:H or VI:H, and Partial if not. Here, we are specifically prioritizing vulnerabilities that would lead to compromise of data that can be accessed by the affected system. There are several ways to expand on this measurement, up to and including cyber risk quantification where we assign dollar values to assets, thus quantifying how a loss event would affect the business’s bottom line. For now, all we need for a working model is to use this simplification.
Automation
Another decision we should be making as part of our base model is whether the exploit for the vulnerability can be reliably automated. We can again borrow from CVSS and look for the following vectors to determine if an exploit could be automated if it existed: PR:N + UI:N + (AV:N or AV:A). Basically, we are looking for vulnerabilities that do not require privileges or user interaction, but can be remotely exploited.
Automation, Scalability
In order to automate and scale an approach like SSVC in large enterprises, there are several factors to consider. There are likely several vulnerability scanners at work within large organizations, so we would need some way to aggregate this data in order to have a centralized list of findings across the enterprise. Tools like AWS Security Hub can accomplish this for you, but the tool isn’t targeted specifically for vulnerabilities. Other vendors such as Nucleus Security and Kenna Security (Now Cisco Vulnerability Management) are some vendors geared to automate and scale this approach. Those tools can also correlate Threat Intelligence feeds to serve our Exploit Intelligence decision needs.
Another option is to develop this sort of capability in-house, which comes with its own challenges and pitfalls, namely the business’s commitment to investing in this solution and keeping turnover low to maintain platform stability.
I am still exploring this space, and would love to hear your thoughts on some of these approaches.
Continuous Iteration and Tuning
If this model is to be effective, we must constantly iterate and tune the model to account for the changing attacker landscape and the evolution of our own systems as they themselves iterate to provide better services. I like to think about this as a big equalizer where we can add and adjust the positions of certain dials to account for a state in constant flux and uncertainty. If you aren’t able to tune your tools, you’ll miss out on the music.
Measuring the Model
There are some critical metrics that we can implement in order to measure how well the model is doing either overall or compared to past vulnerability management models. I’ve listed two, but there are several more we could use that I have yet to explore.
(Mean) Time to Action: Based on the action reached at the end of the decision tree, how long does it actually take the organization to act and remediate the vulnerability? Is this time within the SLA we have established? If this number is outside of these SLA ranges over a period of time, it may be time to either obtain more intelligence of our internal systems, or understand if the business’s risk posture has shifted.
Number of vulnerabilities per asset/environment over time: We can measure where our vulnerabilities congregate in our environment to see if we need to make any additional decisions in our decision tree to account for where assets sit and in which environment. This can also inform us of where vulnerabilities are being introduced in the Software Development Lifecycle (SDLC), which could indicate that the vulnerability management program needs to measure vulnerability arrival rates and integrate with the Application Security program.
Vulnerability Chaining
A logical iteration to evaluating CVEs with SSVC is to evaluate chains of vulnerabilities. This concept can be complex, but I really like Walter Haydock’s two-parter on Vulnerability chaining in his Deploy Securely blog. See the links below.
In short, we could essentially treat chains of vulnerabilities identified in our system as individual CVEs and evaluate them with the SSVC model. Once I get a better grasp on how this would work (or if), I will likely revisit this and provide an update to this post.
Data Classification
At the time that the organization is mature enough to start adopting data classification standards such as tagging assets with the types (and number of records) of data that they store or process, this classification can be used to enhance our decision making and inform loss values. This sounds great in theory, so I’d be interested to explore the practicality of such an approach.
In short, we can leverage the classification of data to enhance our Technical Impact decision. For instance, if a vulnerability is present on our Customer Relationship Management (CRM) system that houses credit card data, and it can be accessed on our internal network, we can reliably calculate the probability of a loss event based on the number of records that we could lose based on this data being exfiltrated due to the vulnerability being exploited, and multiply that by how much it is to purchase credit monitoring per individual and/or additional costs.
This is where we can start measuring the risk of the vulnerability quantitatively, and adjust our SSVC decisions based on the organization’s appetite for this risk.
Reachability-Based Dependency Analysis
Another data source that we can include in Technical Impact is reachability-based dependency analysis. This blog by Endor Labs outlines the concept, but essentially it is a form of call graph analysis to determine whether a vulnerable function in our system is actually reachable. This could highly impact our decision to prioritize or de-prioritize the vulnerability — if the vulnerable function is not callable, do we really need to prioritize it?
Closing Thoughts
— George Box, British statistician
The SSVC model attempts to codify prescriptive decisions based on likelihood, impact, severity, and risk, but it will never reflect reality or include every edge case, and by no means does this post cover all nuances or caveats. I hope to see the industry continue to move towards modelling vulnerability management and risk management in such a way that is decision prescriptive, and provides us with real risk quantification.
Some areas that I want to further research are:
- Explore Vulnerability Chaining and ways to evaluate chains
- Further Measures and Risk Quantification
- Automate as much of the process as possible
- Predict the Model’s Performance with Vuln4Cast
- Non-CVE-based Vulnerabilities
- Integrating Container/OS/Kubernetes/Cloud (Mis)Configurations into the model
- First-Party Vulnerabilities
Disclaimer: The views expressed in this article are my own and do not necessarily reflect the view of any organization.
