The topic of vulnerability prioritization and vulnerability handling may be one of the most charged issues within SBOM and application security communities. Vulnerability management has quickly become the most talked about use case for SBOMs, with incidents like log4shell cementing the need for rapid identification of vulnerabilities in our software. But actioning this intelligence continues to be a hot topic. And the problem is getting worse. How do we manage all these vulnerabilities at scale?
CVSS (Common Vulnerability Scoring System) has long been seen as the de facto mechanism for vulnerability prioritization, but industry focus in recent years has shifted to exploitation as an indicator for vulnerability risk. Projects such as EPSS and CISA Known Exploited Vulnerabilities (KEV) have emerged, providing visibility into this data for the entire security community. But these models are somewhat rigid and may suffer from a lack of context when decisioning vulnerabilities.
Thankfully, we have a few options to pick from. OWASP Risk Rating and even the CVSS model provide opportunities for additional context, though most choose not to use it in this way. We do think CVSS 4.0 has drastically improved these capabilities over 3.0, but today we want to discuss the CISA Stakeholder-Specific Vulnerability Categorization (SSVC) model.
This method promises to streamline and prioritize vulnerability management for diverse organizations, enhancing their overall security posture.
A Note on Prioritization
A key point about prioritization methodologies in general — that applies to SSVC, KEV, EPSS, and others — is this: As an industry, we look to these approaches to help us understand how to reduce the chaos of vulnerability response. It’s a huge distraction and the scale of the problem is unmanageable and getting worse. So, we are eager for ways to reduce the pain.
The first thing we need to understand is what to work on first, and this is where these approaches can help. But I see many people in industry instead look at prioritization models as ways to reduce the workload altogether. After all, if a vulnerability is not being exploited, do I really need to patch it?
I wish it were that simple, and unfortunately, this creates an incredible amount of dependency on accurate threat intelligence. What if the threat intelligence that implies exploitability is wrong? Or maybe you become the first target? Or maybe exploitation is difficult to identify, or we just have not seen it yet? Threat intelligence is a lagging indicator, and while it’s a very important signal to use in your program, it may be unwise to build your entire program around it. Can you really afford to be wrong?
Instead, we should consider prioritization models as a means to accelerate urgency above and beyond normal vulnerability handling processes, not as a way to decelerate or eliminate the need to resolve issues. The exception of course is when we can validate that a vulnerability is truly a false positive and produces zero risk. SSVC does not eliminate the need for normal vulnerability handling, as you will see in the very first “Track” decision point.
What is SSVC?
The SSVC is a decision-making framework designed to help organizations categorize and prioritize vulnerabilities based on their unique circumstances and risk profiles. Unlike traditional vulnerability scoring systems like CVSS that produce a score to quantify severity, SSVC utilizes a decision tree to arrive at a decision-based outcome such as Track or Act.
If you look behind the scenes at how this decision is calculated though, it too utilizes a vector-based model very similar to a CVSS score which we will get into below. In fact, the team at Carnegie Mellon University who initially conceptualized this approach, built their vector strings on the CVSS model. But ultimately, SSVC uses a set of questions to advance through the tree and determine a suggested outcome based on the answers to those questions, not a 1 to 10 score.
Key Components of SSVC
1. SSVC utilizes decision trees to guide organizations through a structured process of evaluating vulnerabilities. These trees help determine the appropriate actions based on various factors, including exploitability and technical and mission impacts.
2. The framework acknowledges that different organizations have different priorities and risk tolerances. By incorporating stakeholder-specific inputs, SSVC ensures that the categorization process aligns with the unique requirements of each organization.
3. The ultimate goal of SSVC is to produce clear, actionable outcomes. These outcomes help organizations decide whether to prioritize patching, apply mitigations, or monitor the vulnerability based on its potential impact and the organization's capacity to address it.
SSVC Model, Explained
There are four distinct ending states in a default SSVC tree: Track, Track*, Attend, and Act. The idea is to create a branching tree that forks along the way to arrive at an outcome that has clear actions associated with it. The great thing about this approach is it removes the ambiguity about what to do about the vulnerability if you align your vulnerability processes to these actions. It’s not perfect, and we will get into some of the nuances around the SSVC approach, but let’s first look at what these four decisions entail. The table below has a high-level overview of each stage, and we’ll go into more detail in the paragraphs that follow.
Track: This is the least critical state. A decision to track just means you should pay attention to information from industry as well as maintain awareness that the vulnerability exists from an incident response and security monitoring standpoint, but the vulnerability does not require unusual action at this time. It does not mean that it does not need to be mitigated, but it should follow standard timelines. If you would normally patch this vulnerability based on documented procedures in 30 days, apply the patch in 30 days. No change in timeline is required, but you still need to address the issue.
Track*: Very similar to Track, no change in timeline is required, but it essentially means pay more attention. These should definitely be elevated from a security monitoring standpoint, meaning you will want to continue to monitor for new exploits or threat vectors but note we still have not decided to do anything unusual about them yet.
Attend: This is the first time where we are recommending accelerated timelines for action. Note in Track*, this did get raised with the security monitoring teams, but at the Attend decision, we notify management of this high-profile issue as well. We need to look at accelerated timelines for patching, as well as coordination with external and internal stakeholders. This may be the point at which you engage with PSIRT contacts at your vendor, especially if a patch does not yet exist. If you do not have a clear plan of action for these vulnerabilities, you should be feeling some anxiety.
Act: This is the most urgent of all decisions. It should probably say “Act Now,” or at least as quickly as you can. In the standard SSVC model, vulnerabilities do not reach the Act stage until there is a high degree of exploitability. A very small number of vulnerabilities will ever reach this decision, based on research from Patrick Garrity, somewhere in the neighborhood of .06%. This would include vulnerabilities that may also necessitate a communications plan to let internal and external stakeholders understand what you are doing about it.
While these are the standard decisions in the SSVC, the model is intended to be customizable. These customizations may include if the difference between Track and Track* is not obvious and you want to call the decisions something else. You may want to change SLAs based on each category; for example, you may separate “Attend” into “Attend within next sprint” vs “Attend in the next quarter." Or if you want fewer decisions or more decisions, it’s your model. And as we get into the next stage of this, you will see why this customization is so important.
A standard SSVC model only has 36 possible branches in the tree. Getting the very first question wrong would mean you can never get to an “Act” decision.
The SSVC Decision Tree
Below you will see a visual representation of the CISA SSVC model as extracted from the CISA SSVC paper. If you make adjustments to the model, yours may look very different. For instance, here are typescript implementations of both the FIRST (first.org) SSVC and the CISA SSVC models, and you will note that decision points and even the ending state of the trees look very different.
SSVC also considers mitigation factors to understand if mitigations are available, how difficult they are to implement, and what type of mitigation it is, such as a fix or a workaround. But this is not factored into the decision, it’s just there to help mitigation efforts. As SSVC is customizable, you could certainly add branches to the tree that consider mitigation or even other prioritization factors that are important to you and your organization.
SSVC Criteria
By default, SSVC uses five criteria to walk the tree: exploitation status, technical impact, automatable, mission prevalence, and public well-being impact.
Exploitation status: Unlike EPSS, this is not a prediction of exploitability. It is based on current threat intelligence and derives decision points such as:
- None: No known exploitation.
- PoC: There is known exploitation proof of concept code available, but it may not be mature.
- Active exploitation: There is verifiable evidence of exploitation, not conjecture; if you were to see a CVE on the CISA KEV list, this would also be an indicator of active exploitation.
As this is the first of the criteria, it is also the first place we will start to see a branching of decisions. In a default SSVC tree, the only way to reach an “Act” decision is if the vulnerability has an exploitation status of “Active.” That means just having PoC code on GitHub or in Metasploit is not sufficient to drive this level of urgency.
You will need to decide for yourself if this is acceptable for your organization, and this is commonly the first place organizations tweak the SSVC. You should keep in mind that it sometimes takes CISA 30 days or more before an exploit achieves this status, and in some cases, a year or more. That’s a really long time to wait, and by then you would have already addressed the issue in most reasonable patching programs.
Technical impact: This criterion may be the easiest of all to automate and capture when done generically without additional context, yet at the same time, potentially low confidence. Every CVE scored by CVSS gets a string that describes metadata associated with the vulnerability, specifically the Confidentiality, Integrity, and Availability (CIA) impact of the vulnerability. This is captured as High, Low, or None. In SSVC, technical impact is captured as Partial or Total. While the SSVC description from CISA does not speak in terms of CIA, it does call back to CVSS as a means to measure this decision. So, it stands to reason that a “High” impact to Confidentiality might suffice to consider a technical impact of “Total” for SSVC.
CVSS typically does not understand your security requirements without capturing things like CIA requirements in Environmental Metrics, something that only very mature organizations generally do, and is certainly specific to your organization. One serious point of consideration with technical impact is that it's often a decision that requires both CVSS input and a deep understanding of the asset at risk. For example, a “High” impact to Confidentiality on an asset with non-sensitive or publicly available data is no longer a “High” impact. Attack vector, such as requiring network access, is another common CVSS attribute that must be accounted for in the context of the affected asset.
Automatable: CISA bases the yes/no decision on whether an exploit is automatable partially based on an understanding of Lockheed Martin's Cyber Kill-Chain. More specifically, the decision is based on phases 1-4: Reconnaissance, Weaponization, Delivery, and Exploitation.
The idea is that there are not sufficient barriers in place to prevent automation of these phases. This could include chaining multiple vulnerabilities together or vulnerabilities with specific configuration or environmental characteristics. It is important to note that the answer to automatable may be different in one environment from another. For instance, if you had an intrusion protection system (IPS) rule that mitigated one of the phases, it might not be automatable in the environment protected by that IPS rule only. As such, you may want to make your own determination of this.
I have seen some organizations use concepts like “Attack Path” to understand their own network exposure, such as having the vulnerable service exposed to specific threat sources, as one way to answer this question. But this too should be combined with an understanding of how the exploit works. For instance, the Microsoft BlueKeep Vulnerability (CVE-2019-0708) was considered wormable and automatable, but if you were blocking RDP, it might not merit the same level of urgency in your environment.
Mission prevalence: This vulnerability creates impact to a Mission Essential Function (MEF), or what is often referred to as a critical function. This is very similar to the concept in business continuity or continuity of operations, in that these risk management processes identify an organization’s core reason for existence. The risk approach is not focused on assets or products. It is focused on the mission the organization is tasked with carrying out. But that mission has dependencies, including assets and products that serve a purpose in carrying out that critical function.
SSVC captures this as Minimal, Support, or Essential. Which is to say that it minimally impacts the MEF, or only impacts supporting aspects of the MEF but not the essential function itself. Or, at the most extreme, it does create essential function impacts.
This would be impossible for the NVD or external threat intel to measure. It requires contextual understanding of both what you do as well as what dependencies exist in your environment. You would need a way to decompose your critical functions through a business impact analysis, or critical function assurance-oriented processes, to understand this level of impact.
Public well-being impact: This is probably the most abstract criterion within the model and is very difficult for external parties without context to evaluate. Broken up across physical harm, environmental, financial, and psychological, this is largely about external impacts. Evaluating public impact well-being requires context about how the MEF is used by external stakeholders, including other downstream dependencies.
For instance, you might not create an outage for a customer and think everything is OK. But if service is degraded to a point that a downstream application fails to deliver value to its stakeholders — and this in turn causes psychological harm — this would be important to understand.
Another possible scenario is that of cascading failures. While not CVE-related, the recent global outage caused by issues with a Crowdstrike update that caused millions of Windows computers to “blue screen” highlighted concerns with understanding of dependency relationships. It also led to questions about Crowdstrike's software assurance practices and the model where Microsoft exposes sensitive kernel operations to security software. This directly led to public well-being impact since healthcare, transportation, and other critical infrastructure sectors were affected by outages. It touched almost everyone’s lives in some meaningful way.
It might be difficult to understand the level of impact here for an issue with this software if we had not already lived through it. Now we know, but what about the next event?
For customers with robust business continuity or supply chain risk management programs, the answers may be a bit clearer, since they have a better understanding of third and fourth parties and their dependencies. But without some form of context here, or experiential learning such as the Crowdstrike scenario, it may be challenging to understand this through purely data-driven means.
Lastly, the SSVC combines mission prevalence and public well-being impact into a single criterion. That means in the larger decision tree there are four inputs, not five, because the fourth is derived from two inputs. This is why it’s important that we get this right.
The table below shows how to combine the mission prevalence and public well-being impact inputs into a single decision value that represents both:
The end result of this is that we essentially have a decision tree inside a decision tree as you will see later as we explore SSVC vector strings.
Ultimately: Exploitation > Technical Impact > Automatable > [MEF + Well-being] = Decision
CISA Vulnrichment and SSVC
It’s important to note that you may arrive at different answers depending on your perspective. Constructing a generic SSVC decision tree such as what we normally see in the form of CVSS scores or other publicly reported vulnerability severity scales may be challenging. Recently enacted in response to lagging vulnerability enrichment from the National Vulnerability Database (NVD, the CISA Vulnrichment project aims to utilize their status as the industry’s first Authorized Data Publisher (ADP) to enrich CVE data.
As part of Vulnrichment, CISA is producing data useful for SSVC decisions (and more, such as CPE and other data), but you may note that some of the factors in the model are not captured. This is largely because it can be challenging to produce information about downstream impacts without context, but organizations that are adopting this model will be much closer to this information. Vulnrichment stands to provide a good starting point for programs seeking to adopt SSVC.
For instance, in the CVE record below extracted from the Vulrichment project, you can see that CISA has provided Exploitation, Automation, and Technical Impact factors, but Mission Prevalence and Public Well-Being Impact are not captured. As such, it may not be sufficient to arrive at a decision, and it does not include an ultimate decision such as Track or Act, but it does help point organizations in the right direction. But keep in mind that Exploitation and Automatable can change rapidly as the threat landscape evolves, so keep an eye out for updates from Vulnrichment or external threat indicators.
SSVC Vectors
While the vector concept utilized by SSVC is not talked about much in the CISA documentation, we went deeper to the source of these concepts, to this paper drafted in 2021 by researchers from Carnegie Mellon.
In Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization, the authors identified three primary stakeholders in the process:
Suppliers - Responsible for developing, maintaining, and providing patches or other remediation for vulnerabilities in their products.
Coordinators - Manage the overall process of vulnerability response, acting as intermediaries between suppliers and deployers. It is common that suppliers also function as coordinators, especially for large critical infrastructure OEMs.
Deployers - Implement the patches or remediation provided by suppliers within their own systems and environments. Deployers prioritize and manage vulnerabilities based on how they impact their specific infrastructure and operations.
As such, there are separate decision trees used by different groups. CISA decided to streamline this process a bit using the decision tree we have described here. You may see some slight differences in the trees in the CMU paper and the CISA process, but that is the point of this — they can be modified!
Part of this work lies in defining the vector strings that are useful for computers to parse and manage for automation purposes. The string below captures the general syntax of SSVC vectors, again very similar to CVSS vectors.
SSVC/(version)/(decision point):(value)[/decision point:value[/decision point:value[...]]][/time]/
Now let’s look at an example vector string along with a description below.
SSVCv2/E:N/A:N/T:P/P:E/B:I/M:H/D:T/2024-07-08T17:45:28Z
You can find the schema for these decision points at the CMU page for CISA Coordinator.
- SSVCv2: Indicates version 2 of the SSVC framework.
- E - (Exploitation: None): No evidence of active exploitation or public proof of concept.
- A - (Automatable: No): Exploitation cannot be reliably automated.
- T - (Technical Impact: Partial): Limited control or information exposure due to the exploit.
- P - (Mission Prevalence: Essential): The component is widely used in mission-critical functions.
- B - (Public Well-being Impact: Irreversible): The vulnerable component is tied to public well-being, and its failure could lead to catastrophic harm.
- M - (Mission and Well-being): This is a complex decision that combines P and B in a final decision of Low, Medium or High
- D - (Decision: Track): The vulnerability will be monitored rather than acted upon immediately.
- 2024-07-08T17:45:28Z: Timestamp of the assessment.
Let’s run through an example of what all of this might look like.
A water utility has discovered a vulnerability related to a disinfection process as part of its Mission Essential Function (MEF) to supply clean drinking water to the local community. An industrial control system (ICS) that is responsible for the disinfection process ensures that the chemicals used are in proper balance. No exploitation has yet been identified, and without evidence of exploitation and insufficient details about the vulnerability, it has been classified as not automatable. These decisions could of course change over time as threat intelligence is uncovered and exploit code is made available. The vulnerability, if exploited, could create system instability which may impact operating parameters, but does not create a total loss of availability, so this has been marked “partial” for technical impact.
A vulnerability of this system could clearly impact a MEF, and has been deemed Mission Prevalence of Essential. The potential for physical harm and psychological impacts would be Irreversible if the population could be harmed.
Using the decision matrix above, since it is a MEF, this remains a High, and along with the exploitation and technical impact factors, evaluates to a decision of Track. While this might be a very worrisome vulnerability, the lack of exploitability and automatable exploits ensure we will need to address this on a normal patching cycle, but do not require immediate action. Entities should continue watching threat intelligence, and if the situation changes they should accelerate remediation timelines immediately.
SSVCv2/E:N/A:N/T:P/P:E/B:I/M:H/D:T/2024-08-04T12:43:19Z
Take a look at the schema linked above, as not all keys in the schema are intuitive: for instance, the following decision labels and their respective keys. The “D:*” section of the vector string is ultimately what constitutes the decision, so if this is the only section you remember, pay attention to this:
Implementing SSVC
- Organizations should begin by familiarizing themselves with the SSVC methodology, including the decision trees and stakeholder-specific inputs. The SSVC document at the CISA site is a great place to start. This should include open and realistic conversations with leadership around what you are trying to accomplish with SSVC.
- Evaluate existing vulnerability management practices and identify areas where SSVC can enhance decision-making and prioritization. Existing tools and data sources including the FOSSA SBOM platform, NVD, CISA KEV, and even internal business risk and business continuity data sources should be considered as inputs into the process.
- Adapt the SSVC decision trees to reflect the organization's specific context and risk profile. This customization ensures that the framework aligns with the organization's unique needs. The decisions you make in customizing SSVC may be equally influenced by what your program needs to accomplish as well as the veracity of data sources you have available for automation. If you are trying to process all vulnerabilities this way, automation will be very important. As you are just getting started, there is nothing wrong with the default implementation of SSVC, but most organizations evolve past this very quickly, or find that it does not quite meet their needs without fine-tuning.
- Integrate SSVC into existing vulnerability management workflows and tools. This may involve training security teams on the new approach and updating policies and procedures to incorporate SSVC guidelines. Be mindful that some compliance requirements may still specify CVSS-based decision points, so there may be situations where you bifurcate your process along compliance-based and risk-based decision trees. For example, Nuclear NRC regulations and PCI DSS both utilize CVSS, among others. That does not mean you cannot use SSVC, but you may still need to demonstrate evidence to your auditor that you use CVSS in the ways the regulations require as well.
- Continuously monitor the effectiveness of SSVC in managing vulnerabilities and make adjustments as needed. As noted in this article, getting even a single decision wrong can result in the incorrect outcome. As your program matures, you are likely to add additional decision points, more data sources, and more automation.
A Final Word
I hope you found this article informative as you begin (or progress in) your SSVC journey. If you did, consider checking out these other SBOM- and vulnerability-management blogs I’ve written for FOSSA:
