Log4Shell, EternalBlue, Heartbleed—vulnerabilities played a central role in many severe and dramatic cyberattacks over the last decade. But the alarming nature of these events masks the constant challenges organizations face in effectively prioritizing and resolving the many other less headline-grabbing vulnerabilities they detect throughout the year. It’s in light of these challenges that the Cybersecurity and Infrastructure Security Agency (CISA) has stepped in with a new vulnerability management methodology—here’s the lowdown on it.
It’s no secret that vulnerability management isn’t where it needs to be—flaws and weaknesses in systems and code continue to threaten cybersecurity at organizations of all sizes. A statistic that exemplifies the struggle is that companies take an average of 60 days to patch critical vulnerabilities. This duration is worrying considering that critical vulnerabilities often provide a path to compromise systems or infrastructure at the admin (root) level, and effectively seize control of them.
Large companies struggle with the volume and sophistication of the vulnerabilities they encounter within large, complex, hybrid IT environments. Small and medium organizations face the perennial issue of allocating limited resources to find and fix these weaknesses. The crux of it is that vulnerability management must evolve to become more efficient in today’s cyber risk landscape. And this is where CISA comes in.
In outlining a three-step plan to evolve vulnerability management, Eric Goldstein of CISA listed the third step as “help organizations more effectively prioritize vulnerability management resources.” The other two steps were to introduce greater automation and help organizations more easily identify when a product or system is impacted by a particular vulnerability.
The proposed vulnerability management methodology was originally targeted at United States government and critical infrastructure entities. But it’s clear that CISA’s hope is to improve vulnerability response across private and public sectors with a new customized version of the model. Titled Stakeholder-Specific Vulnerability Categorization (SSVC), the methodology uses a decision tree model based on the following four key decision points to prioritize remediation actions:
State of Exploitation
The decision tree begins with examining the current exploitability of the vulnerability at the time of analysis. By examining sources like the National Vulnerability Database and threat reports, analysts can classify the current state of exploitations as either:
Having assessed the state of exploitation, the next point in the decision tree is to gauge how feasible it is to quickly replicate many exploitation events using the same vulnerability. The recommendation here is to go through the first four steps of the basic cyber kill chain (reconnaissance, weaponization, delivery, exploitation) and answer “yes” or “no” to whether all of those steps can be reliably automated.
This step is ultimately a judgment call, but it’s usually possible to come up with an accurate answer using an analyst’s skills and experience. Any barrier preventing automation at any of the four first kill chain steps suffices to make this point of the decision tree a firm no.
The technical impact is another point in the decision tree with just two possible answers: this time it’s Partial or Total. It’s relatively straightforward to decide between the two options here. Total means that exploiting the vulnerability gives total control over software behavior or total knowledge about the contents of the affected system. Partial technical impact means that exploitation leads to limited control over behavior or limited information disclosure.
Mission Prevalence and Public Well-Being
There are three possible values in this final point of the decision tree: low, medium and high. Getting to any of these decisions though requires first categorizing the Mission Prevalence and Public Well-Being impacts of a vulnerability.
Mission Prevalence essentially measures the vulnerability’s impact on any activities that an organization must perform, even during a disruption to normal operations. For vulnerabilities found in private sector companies, the majority will be counted as Minimal. The other possible categories are Support (for vulnerable components that support mission-essential activities, and Essential (the vulnerable component directly provides mission-essential capabilities).
To get the final low, medium or high value here, you then map the Mission Prevalence to one of three Public Well-Being categories. Assigning a vulnerability to a Public Well-being category factors in its potential physical, environmental, financial and even psychological toll.
In taking each vulnerability through the SSVC decision tree, you arrive at four possible actions to take:
It’s interesting to note that mitigation status does not impact how vulnerabilities are prioritized in CISA’s new methodology. This does not mean that mitigation status isn’t important in vulnerability management, but there’s a clear argument that knowing about available mitigations, workarounds or fixes should not guide prioritization.
With weaknesses emerging regularly in the complex interplay between software, systems, and users, effective vulnerability management is pivotal across all industries. CISA’s methodology provides a useful foundation for prioritization, but the reality is that resource constraints will continue to hamper the necessary evolution of vulnerability management.
Vulnerability management services (VMS) help businesses discover, assess and prioritize vulnerabilities in real time via a service-based model.