In this third installment of our Stakeholder-Specific Vulnerability Categorization (SSVC) blog series, we focus on the transparency and understandability principle. In practical terms, this principle involves delivering clear and accessible communications on how and why fixers should take remediation action for a security finding.
This aspect of the ‘last mile’ of the fix is often the toughest to operationalize, since it’s where the inefficiencies of the prioritization process, lack of clarity on fix ownership, and hurdles to effective stakeholder communication become the most painfully apparent. It’s also the stage at which many organizations struggle with a consistent approach to exception request management.
In our first blog post, we laid out Silk’s capabilities to scale and automate an integrated approach to qualitative and quantitative risk assessment incorporating business context for SSVC decision trees that can be extended across CVEs and non-CVE exposures and vulnerabilities. In our second post, we dug deeper on identifying and assigning ownership for the output of SSVC decision trees.
In the post we discuss how to operationalize remediation for the right owners for the right priorities through relevant, actionable and succinct communications - as well as how exceptions management can be incorporated as part of a broader risk resolution strategy.
Too Much of the Wrong Information
Taking a step back in order to understand why relevance is a building block for this principle, it’s important to understand the current state of play.
Evaluating known vulnerabilities using existing tools to reach a prioritization outcome is often a complex mathematical exercise, involving manual manipulation of spreadsheets. Alternatively, fixers might receive output directly from a vulnerability prioritization tool that uses an opaque, black box approach.
In both cases, fixers face the same scenario: they have no context on how security teams reached a prioritization decision; and, have to decide how to take action based on output designed for security teams, most notably technical severity ranking.
Along with providing evidence on where and when an issue was detected for evidence, sustainable risk resolution strategies require consistent production of information that’s relevant to stakeholders to bridge the remediation gap.
As security teams interact with other stakeholders in the process of resolution of findings, working from spreadsheets or simply sending off a ticket with detection tool output doesn’t provide a foundation for collaboration.
How Silk helps
Maintaining a feedback loop for the risk resolution ‘last mile’
Silk provides clarity in how it collects data, conducts risk evaluations, and formulates recommendations. This helps build trust, and it also makes it easier for organizations to understand and justify their decisions about managing vulnerabilities, threats and non-CVE exposures, such as cloud security misconfigurations.
Communications are ‘relevant’ in the sense that the fix guidance incorporates business context, is specific to the assets owned by the fixer (or the fixer team), and is delivered as part of their daily workflow through ticketing integration. ‘Actionable’ points to recommendations for practical steps to implement fix, and the relative urgency based on the SSVC decision value - in contrast to a technical severity ranking.
As an integrated element of ticketing and workflows, providing a succinct rationale for an applied SSVC decision value facilitates collaboration between stakeholders.
To make it easier for organizations to understand and justify their remediation decisions, security teams can incorporate technical information on how the program collects data, using which tools, conducts risk evaluations, and then formulate recommendations that are accessible and clear.
With bidirectional integration into the ticketing and workflow tools used by the remediation fix owner, Silk can help not just with the initial communication, but also with maintaining ongoing communication between the security team and the fix owner. If the fixer requires more information, or wants to provide feedback on remediation guidance, the interaction is managed through a consolidated, centralized console - without the security team having to log in to ticketing or workflow tools.
Building on the feedback loop, Silk also records and keeps track of exception requests made by fixers, and facilitates follow up once the request has been accepted. Silk enables security teams to maintain a centralized view of exception requests, with the ability to track when the time period granted for an accepted exception request is drawing to a close.
In our final SSVC blog post, we will cover how Silk can enable security teams to construct and maintain SSVC decision trees, bringing together the three guiding principles underlying the model.