How to Fix Your Broken Vulnerability Management

OK hear me out, I know vulnerability management is an old practice. Why are we even talking about it, it’s not broken, right?

For most companies, it is very broken even if it appears to be working.

These broken vulnerability management programs are so similar that I bet I can describe YOUR broken vulnerability management program, without ever talking to you about it. I bet it contains some of the following elements:

• 11 GB of excel spreadsheets (x10 if you are a larger enterprise)
• Massive email footprint, eating up about 1/3 of your inbox storage
• 3 truly critical vulnerabilities that you can’t get anyone to take seriously
• Tenable/Rapid7/Qualys/Green Bone/et al producing weekly or monthly scan reports
• A feeling of total despair….

I have lived and breathed vulnerability management for most of my career. At times, it was the majority of my work. Other times, it’s just a small part. But the thread remains, it feels like I am always talking about CVSS scores and trying (usually failing) to relay to anyone who will listen how these are just starting points for assessing vulnerabilities. In reality, CVSS scores can often be so blind to architectures, security controls, and business practices that they do more harm than good!

Luckily for you, I am not the type of person to raise my hand and call out a broken process without also bringing a good solution to the table.

I present to you, SSVC or Stakeholder-Specific Vulnerability Categorization.

A primer on SSVC

Carnegie Mellon University's Software Engineering Institute (SEI) and the CISA have collaborated to create the Stakeholder-Specific Vulnerability Categorization (SSVC) system. This system is built to provide the cyber community with a vulnerability analysis methodology that takes into account the exploitation status, safety impacts, and prevalence of the affected product for each vulnerability. Later on, in 2020, the CISA collaborated with SEl to develop its own distinct SSVC decision tree for analyzing vulnerabilities affecting the US government, state, local, tribal & territories (SLTT), and critical infrastructure organizations.

That is the definition provided by SEI & CISA. What this means in practical terms is, we now have a way of adding valuable context to the vulnerability assessment process. This is so critical to the improvement of vulnerability management, it can not be overstated. This isn’t an evolution of a broken system, this is a revolution!

SSVC in a nutshell

CISA uses stakeholder-specific vulnerability information to identify, assess, and organize the cybersecurity risks faced by the country's critical infrastructure. To assist them in better understanding and managing the cybersecurity threats faced by the US government, CISA provides stakeholder-specific vulnerability information to other federal agencies, state and local governments, the corporate sector, and foreign partners. CISA uses a slightly different model than that developed originally in conjunction with SEI. This model sorts vulnerabilities into four potential “states”.

You can use this same model in your organization, with no additional work needed. To get started, you must first spend a few minutes understanding that vulnerabilities are sorted into “states”, each state has a descriptive set of actions that must be taken on the vulnerabilities in this state.

States

The vulnerability states can be thought of as general descriptions of how to treat a vulnerability. It’s important to note that we don’t see any number systems like the CVSS 0-10. Numbers poorly describe the nuanced qualities of a vulnerability, these states however do a much better job. When a vulnerability lands in one of these states, you simply read the language of the state and then apply that to the identified vulnerability. No interpretation, no additional consideration, just take action!

The following four states are sorted from what is essentially “Informational” to “Critical” (top to bottom).

• Track: At this time, no action is necessary to respond to the vulnerability. The company would keep an eye on the vulnerability and reevaluate it if new information surfaces. CISA advises addressing “Track” vulnerabilities during routine meetings to verify the state is still applicable.

• Track*: The vulnerability has unique properties that may call for closer observation of any changes. CISA suggests that security patches should be applied to “Track***”** vulnerabilities during the next patching or outage window.

• Attend: The organization's internal supervisory level personnel must pay attention to the vulnerability. The activities that must be undertaken include asking for help or gathering additional details regarding the vulnerability, and they may include publishing a notification internally or internationally. The CISA advises addressing “Attend” vulnerabilities with some urgency, earlier than the normal patching window.

• Act: Internal, supervisory, and leadership-level members of the organization must pay attention to the vulnerability. Requesting assistance or details about the vulnerability, as well as disseminating a notification internally and/or externally, are required. Internal groups would often gather to decide on the overall reaction before carrying out the decisions made. “Act” vulnerabilities should be fixed as soon as feasible.

  Applying SSVC in your organization?

  While CISA and CMU SEI have developed this framework, they are still working out exactly how it should be used. Currently, they suggest using a decision tree workflow, which they call the SSVC Calculator.

  
  

  

  The SSVC calculator is a simple, intuitive graphical way to answer yes-no questions using easily obtained data. This is what enables a more thorough analysis of vulnerabilities, with less incumbent skill (i.e. you don’t need a ton of experience to correctly assess a vulnerabilities severity). To use the calculator, you hover over the blue dots (decision points) to get information that will help make a decision. Once a decision has been made, clicking the appropriate blue dot enters an answer and a new series of decisions (dots) will show up.

  
  

In this example, you can see that by answering just four questions:

1. No exploitation exists

2. yes it’s Automatable

3. it has a partial technical impact

4. the assets involved are a medium level of importance

   
   

   We are able to determine this (made-up) vulnerability arrives at a “Track” state. With the “Track” state vulnerability, we would keep an eye on it and update the calculation should new info come out otherwise no actions would be taken.

Wrapping this up

SSVC is a step forward, as noted it is not the evolution of the vulnerability management space but instead a revolution of vulnerability management. CVSS scores were a good starting point, but as we have seen time and time again, they are a poor indicator of true criticality. Using the SSVC decision tree model, consistent, accurate vulnerability assessment can be achieved with less expertise!

Also published here.