The intensifying demands on security teams from major technology shifts like digitalization and cloud adoption necessitate a strategic, sustainable approach to managing - and resolving - a broader range of vulnerabilities. In contrast to legacy frameworks weighted toward technical severity scoring of CVEs only, the Stakeholder-Specific Vulnerability Categorization (SSVC) model is intended to help organizations understand how to apply vulnerability risk to their environment, and what the appropriate remediation decisions are based on that contextualized risk.
SSVC’s expanded scope on how an organization structures and implements its remediation strategy holds promise for a systematic, consistent and scalable risk resolution approach - but is not without its operationalization challenges. This transition, as the name suggests, is driven by interaction, collaboration and transparency across stakeholders, in tandem with more contextual decision criteria.
The SSVC model is also gaining more attention because of a change that’s been building since it was released in 2019 - the volume, diversity, and often duplicative volume of alerts coming from new detection tools and scanners for cloud services, application infrastructure and code that have overwhelmed teams that were already stretched. A vulnerability is now as much a non-CVE exposure such as an exposed AWS S3 bucket, an infrastructure misconfiguration, as the more traditional understanding as a CVE.
Firstly, to operationalize a model that goes beyond (but still incorporates as an input) ranking how “bad” a CVE is based on CVSS scores, security teams need to incorporate multiple factors into a subjective model to assess the relative risk of a detection tool finding.
The factors to reach a subjective decision on how to respond to a risk should encompass technical, environmental, business and organizational context. And, at each phase in the decision making process, teams need to provide transparency into how they reached the output. This is a challenge for most vulnerability management teams.
Secondly, they need to be able to mobilize - as Gartner terms the process in the analyst firm’s Continuous Threat Exposure Management model - the appropriate fix owner with the appropriate information to take an action. And, teams need visibility in the state of the resolution process, including exceptions management.
For many organizations, vulnerability management programs can often devolve to ranking findings on a spreadsheet, and spinning their wheels with remediation request dead ends. The promise that SSVC holds out is not only better prioritization output, but more broadly, a path toward threat prevention and enterprise risk posture management.
New models like the Exploit Prediction Scoring System (EPSS) can play a role here in the prioritization phase, providing input through scoring of the likelihood of an exploit for a specific CVE. But, while the likelihood of an exploit is important for the prioritization piece of the puzzle, SSVC’s scope is the entire puzzle of technology risk resolution.
In this blog - the first in a series - we will cover the principles underlying SSVC, how the model can be operationalized, and how we’ve seen these principles in action at Silk customers looking for more efficient, sensible and stakeholder-driven ways of dealing with multiple types of vulnerability risk.
SSVC - not just another four letter prioritization framework
Developed by Carnegie Mellon University's Software Engineering Institute, SSVC provides a methodology to understand, prioritize, and resolve cybersecurity vulnerabilities based on their technical, business and people impact, exploitation status, potential to be automatable, as well as attacker value density, and system exposure. The decision values for response are Track, Track* (which may require closer monitoring), Attend and Act, with escalating degrees of urgency.
The impetus for the definition of SSVC was the longstanding challenge that vulnerability management teams have faced almost since the establishment of the discipline: how to evaluate, categorize and guide the organizational response to the output of vulnerability scanning tools, with the intent of focusing on the threats that pose the greatest, most immediate risk to the organization.
The SSVC approach draws from several key principles, including:
- Qualitative Assessment: Understand each vulnerability in its unique context, accounting for its potential impact on the system and the broader operational environment
- Decision Focus: Identify which actions to prioritize based on the practical implications of each identified vulnerability, rather than just technical parameters.
- Transparency and Understandability: Maintain high standards of transparency throughout the vulnerability management process and provide clear, justifiable explanations for each decision.
In this blog post, we will focus on qualitative assessment (and the underlying issue of contextualization and automation of prioritization), and follow up with posts that explore decision focus, transparency and reliability, and conclude with how Silk can operationalize SSVC decision trees.
Operationalizing SSVC - Putting Principles into Practice
Let’s take a deeper look at how the qualitative principle can be put into practice.
Qualitative risk assessment: three-dimensional context
SSVC emphasizes understanding each vulnerability in the context of its potential impact on both the system and the broader operational environment. A vulnerability (or groups of vulnerabilities) need to be assessed subjectively in the business, operational and environmental context of the asset, in tandem with threat severity assessment (measured, for example, by an EPSS score). Implied here is also that teams have the capability to automate the assessment.
To facilitate a subjective assessment, security teams need three-dimensional context about the asset where vulnerabilities are discovered. Asset discovery and management is, in of itself, as thorny a challenge for security teams. Still, there are ways to build an asset inventory as the foundation for making decisions about how to respond to what detection tools identify as vulnerabilities or risk exposures on the asset.
Three-dimensional context, in this sense, is the type of asset, the relative business importance of the asset, and how the asset relates to other assets in the context of an application. This context, in turn, helps teams to decide the relative urgency for taking action where for example high-severity CVEs, misconfigurations or host vulnerabilities with a high likelihood of exploit are detected on multiple assets.
Building asset profiles - what can we learn, and what do we know
Security teams at our customers generate an asset inventory by integrating with, and consuming metadata and tags via the Silk platform from existing security detection tools, IT service management platforms like CMDBs, cloud service provider APIs, or even tools for attack surface mapping.
Through Silk’s automated normalization and de-duplication of assets and asset types after ingesting, consolidating and correlating available asset data, security teams can leverage a more structured and systematic asset inventory.
Using what other systems of record and tools can tell us about the assets, The Silk platform allows customers to represent what they know about the assets through attribute labels - augmenting the automated generation of asset profiles.
These labels can represent the business value of an asset, the types of data that they store or process, as well as information that helps elevate or reduce the relative associated risk: such as the asset is internet facing, or is in a test environment with no internet access.
Silk’s combination of consumed asset labels and tags with applied labels allows security teams to maintain asset profiles that are meaningful to inform subjective business impact assessments - and, by extension, incorporate decision criteria to operationalize the SSVC model.
Teams can further leverage these labels that represent the attributes they know about assets to implement rules for automation of prioritization decisions - based on subjective assessments.
Asset Intelligence plus Threat Intelligence
These augmented asset profiles, in tandem with output from existing threat severity frameworks and along with threat intelligence feeds, can be combined to provide a more holistic, meaningful assessment of the threat. If the intent is to reduce and mitigate risk with finite resources and time available, it’s important to be able to guide remediation actions where there is real risk, suppress findings if the risk is minimal, and track those remediation actions where exceptions requests are made.
The Silk platform does incorporate scoring frameworks like Common Vulnerability Scoring System (CVSS), the National Vulnerability Database (NVD) or emerging ones like the CISA Known Exploited Vulnerability (KEV) Catalog, as well as incorporating the EPSS into severity assessments. But, as is the case with the structure of SSVC, EPSS information is an input into the decision making and prioritization process and helps inform the response to the contextualized finding.
Silk’s asset-centric view can also help identify toxic combinations of threats found on the asset posed by multiple CVEs, that in combination pose a higher risk if exploited in a targeted kill chain - as opposed to ranking based on individual CVE severity alone.
Where Silk Fits In
Silk Security takes the decision-focused approach of SSVC and turns it into practical action. To operationalize the qualitative assessment principle, Silk builds an asset-centric view to contextualize de-duped and correlated findings, and evaluates the risk based on severity, likelihood of exploit, as well as the business value of the asset. Silk provides a holistic view of the potential real-world impacts of each vulnerability that guides the decision making process.
In our forthcoming blog post, we will explore how to operationalize the decision focus principle, by consolidating and translating complex vulnerability assessments into clear, actionable recommendations that are tailored to the organization's unique operational workflows and processes- as well as identifying who are the stakeholders involved in remediation processes.
We will follow up in the series with a discussion of the transparency and understandability principle, and conclude with how Silk can operationalize SSVC decision trees.
