Taking The Next Steps For Vulnerability Risk with SSVC

The Stakeholder-Specific Vulnerability Categorization (SSVC) framework was developed as a joint effort between Carnegie Mellon University and the Cybersecurity Infrastructure Security Agency (CISA) to respond to the recognized need for a more tailored approach to vulnerability scoring and prioritization. This new method has been helping organizations assess risks to their infrastructure since 2019. 

The SSVC system improves upon the existing Common Vulnerability Scoring System (CVSS) by accounting for the impact of an exploit on a specific organization rather than just focusing on the technical severity of the vulnerability. Simply put, SSVC informs the organization of the risks to data, users, and assets within its environment instead of worrying about the technical risk to the vulnerable software or system in isolation. SSVC is becoming the industry standard system used to evaluate risk because it equips leaders and technical teams with the information they need to evaluate how remediation should be handled within their environments. Specifically, the SSVC model helps stakeholders comb through an ever-increasing number of vulnerabilities in a way that highlights the most damaging vulnerabilities specific to the organization.

In this article, we discuss exactly how SSVC differs from CVSS and how it can provide more actionable information to organizations when prioritizing risk mitigation and vulnerability remediation. We discuss how each system determines a risk score and why it may be a good idea to focus on using the SSVC model sooner rather than later.

Summary of key SSVC concepts

Evaluating with the Common Vulnerability Scoring System (CVSS)

Let’s look at how an organization would evaluate risk with the CVSS and SSVC models, using CVE-2023-36908 as an example. You can find more details about the score here.

CVE-2023-36908 is a Windows Hyper-V information disclosure vulnerability with an overall CVSS score of 6.5, which classifies this as a medium vulnerability. Since most organizations have a standard response time based on the CVSS score, it should be sufficient enough to take one look at that score of 6.5 to know that this will be patched within X days according to the organization’s standard. This example is pretty straightforward.

Now let’s take a look at CVE-2023-4051. This vulnerability affects versions of Mozilla’s Firefox browser and Thunderbird email client, potentially leading to user confusion and possible spoofing attacks. It’s been assigned a base score of 7.5, which means it’s a high vulnerability. We can assume that most organizations will prioritize this vulnerability over others, but the actual risk might not be as severe as the CVSS score indicates.

To help us further determine the risk this CVE may pose to the organization, we can use something called the  CISA Known Exploited Vulnerabilities (KEV) catalog, a database of known exploited vulnerabilities hosted by the CISA that tracks CVEs that have been confirmed to have been exploited in the wild. The KEV catalog can be viewed in a browser with a search engine or exported in either CSV or JSON format. 

{{banner1="/banners"}}

We can check whether there are reported instances of CVE-2023-4051 by entering the CVE ID into the search bar of the KEV catalog, but we won’t find any results. While that doesn’t guarantee that exploits haven’t happened and won’t happen, it does allow us to modify the temporal score within the CVSS calculator to view the adjusted risk. The temporal score takes into account the following factors:

• Whether exploitable code exists and to what level: A functional exploit will always result in higher scores than a proof of concept.
• Report confidence: CVEs being reported or confirmed by a vendor usually result in higher scores than those that have only been reported by one or more external sources, such as a security researcher or bug bounty program.‍
• The level of available remediation: A vendor-provided patch will help more than a workaround, and a workaround will go further than no available remediation.

We can use the CVSS score calculator to adjust this score to “Unproven that exploit exists” since this exploit is not in the KEV catalog and is described as a possibility. Doing so brings the overall score down to 6.9, which now classifies this vulnerability as medium.

{{banner2="/banners"}}

Evaluating with the Stakeholder-Specific Vulnerability Categorization (SSVC) system

Now that we understand how the CVSS scoring system works, let’s look at the SSVC decision tree. The SSVC system uses five factors to score vulnerabilities into four categories to empower organizations to determine what course of action should be taken when looking at specific risks. These factors consider whether an exploit exists and whether that exploit is automatable. The SSVC decision tree then accounts for the level of technical impact on an organization, its mission, and the well-being of the organization, the people at risk, and the data at risk. 

This information helps influence not only technical decisions but business decisions as well. If the only solution to remediating a vulnerability within your environment incurs additional cost through licensing or hardware, knowing the true risk that the vulnerability poses to your environment through the SSVC model allows your organization to make smarter financial decisions than a CVSS score would. 

The diagram below illustrates the level of detail involved in calculating vulnerability scores using the SSVC system. 

We’ll examine each available choice starting with the current level of exploitation. Assuming the current exploitation level is either none or poc, we can already rule out the possibility of “Act” being the end score.

Now, we need to input whether the vulnerability is automatable. Even if we’ve input “none” for the exploitation, an automatable vulnerability will always result in the possibility of a more severe score.

Now, we need to determine whether the technical impact would be partial or total. CISA defines “partial” as an exploit giving an attacker limited control over your environment or data and “total” as giving an attacker total control over your environment or data.

“Total” technical impact will always result in the possibility of a more severe score. 

Finally, we look at the vulnerability’s impact to mission and well-being. There are three choices: low, medium, and high, and of course high will always result in the most severe score possible for that subsection of the decision tree.

Now we’ll use CVE-2023-4051 as an example, we can determine what action to take and how quickly to do so. Starting from the far left, we know that CVE-2023-4051 is not in the KEV, so we’ll move forward, understanding that there’s no exploit. We’ll assume CVE-2023-4051 is automatable, and there would be a technical impact if it were somehow exploited. The impact on mission and well-being further highlights how tailored the SSVC results can be. 

Since CVE-2023-4051 potentially leads to “user confusion and possible spoofing attacks,” the impact on the mission and well-being greatly depends on the type of organization evaluating this vulnerability. A smaller business with mostly internal systems and no external users will almost certainly agree that this vulnerability can be classified as “Track.” 

In contrast, a travel organization such as an airline company with multiple booking pages where payment info and PII are accepted and stored could have “total” and “high” impacts on mission and well-being, resulting in classifying this vulnerability as “Track*” instead.

The further along the SSVC decision tree you move, the more you need to consider your organization’s environment and needs. While it’s pretty clear whether a CVE has an active exploit available and whether it’s automatable, the level of impact on your environment can become a bit harder to assess. 

Continuing to use CVE-2023-4051 as our example, would a spoofing attack be more likely to compromise a customer’s information by capturing login credentials and/or credit card details? Or would a spoofing attack be more likely to capture the credentials of an internal user with elevated privileges, thus opening up the environment to more risk? These decisions factor into how the SSVC model categorizes vulnerabilities within your environment based on what you consider more or less damaging.

{{banner3="/banners"}}

Comparing CVSS and SSVC

Now that we’ve evaluated CVE-2023-4051 using both the SSVC and CVSS (both base and adjusted temporal scores) we can see the differences between them. CVSS initially scored this at 7.5, making this a high priority for every organization regardless of size or function. After confirming with the Known Exploited Vulnerability catalog that this specific CVE has no known exploit, we were able to adjust the temporal score and bring the overall score down to 6.9, indiscriminately making it a medium priority. Then we evaluated CVE-2023-4051 using the SSVC model, working through the decision tree with unique considerations for the types of businesses that might use this system. 

In both scenarios, our decision resulted in a variation of tracking. The older system would have us prioritize remediation for this vulnerability without regard for the type of environment we have or the work we do. The newer SSVC system allowed us to determine the true risk to the environment by evaluating the impact this vulnerability might have within this specific environment. The CVSS scoring system prioritized this vulnerability—whose description used the words “could” and “possible”—as a high priority, which is likely an overclassification. The SSVC scoring system appropriately identified the risk in a specific environment, which led to proper classification of the vulnerability, allowing for a more appropriate response by the team responsible for monitoring and remediating such vulnerabilities.

Implementing the SSVC system

Now that we understand what the SSVC system is and how it differs from CVSS, we need to begin working with it. While implementing a new system may seem like a daunting endeavor, breaking it down into smaller tasks can help ensure a smooth transition. 

There are also ways to automate the scoring of risks using the SSVC model. Many tools have a way to integrate the SSVC model into your environment using asset tags and other information. Automation can also be achieved using if/then logic as well as and/or statements. For example, we can say: “IF an exploit is active AND that exploit is automatable, THEN…” and we’ve already narrowed our options to “Attend” and “Act.” We can further narrow our options based on asset accessibility and criticality: Public-facing assets carry greater risk than internal assets, and the more critical the asset is to the organization, the greater the risk. 

It is important to note that in order to be able to automate the SSVC decision tree, your organization must agree on the following:

• Asset inventory: Know what assets exist within your organization and where they operate. Know how many databases you have, how many servers you have, their functions, and where they sit within your environment. 
• Asset importance: Prioritizing vulnerabilities requires you to rank the assets that they impact based on how they affect your business. ‍
• What vulnerabilities exist within your environment: Categorize your vulnerabilities by type.

Although this is not an exhaustive list, it should give you a good starting point when considering how to begin automating the SSVC model within your organization.

Here are some best practices that underpin the design of Silk Security’s product and align with its philosophy and functionality:

• Start with mission-critical application environments: Your environment’s most critical assets should always be the highest priority in the vulnerability remediation process. Testing the SSVC system against your most critical assets may help reduce the number of vulnerabilities requiring immediate attention when compared to the more simplistic CVSS model. 
• Integrate with all internal and external sources of vulnerability management: Using the SSVC model effectively requires total support within the environment. It doesn’t work well if the team responsible for actually patching systems is using the SSVC model while the team responsible for tracking vulnerability management efforts is still prioritized under CVSS. Ensure that your internal teams and any external contractors are synced on the SSVC model. 
• Scan all of your environment’s software and hardware assets for vulnerabilities: You can’t prioritize vulnerability remediation if you don’t know what vulnerabilities exist within your environment. Start scanning for vulnerabilities, or continue doing so if you already are.
• Coordinate collaboration to remedy the vulnerabilities: Once you know what vulnerabilities exist within your environment, the next step is to assign responsibility. The proper teams should be aware of their role in remediation as well as relevant deadlines.‍
• Report on the lifecycle of the vulnerabilities: Vulnerability management is an ongoing process. Tracking vulnerabilities is an important part of the vulnerability lifecycle to ensure that high-priority vulnerabilities are handled within an acceptable time frame—whether that means patching, removing, or accepting risk—and lower-priority vulnerabilities are monitored appropriately.

{{banner4="/banners"}}

Conclusion

In 2019, the Cybersecurity Infrastructure Security Agency (CISA) and Carnegie Mellon University created a solution to a problem that previous vulnerability and risk-scoring systems weren’t addressing. Applying a one-size-fits-all approach to vulnerability scoring is inadequate since vulnerabilities pose varying levels of risk to each organization based on a number of factors. The new Stakeholder-Specific Vulnerability Categorization system (SSVC) was created to help identify appropriate responses based on the level of risk that vulnerabilities pose to each specific organization. 

SSVC assigns one of four categorizations to a vulnerability by evaluating five factors, some of which are relevant to the environment, as opposed to assigning a numeric score based on three factors specific to the vulnerability itself, like the previous method, CVSS. 

The newer SSVC is quickly becoming the industry standard because it helps organizations categorize risk more efficiently and allows teams responsible for remediation to properly allocate their time and effort toward the true risks within their environments.