How SSVC can be used for vulnerability prioritization?
What is SSVC?
Ryan: SSVC stands for stakeholder-specific vulnerability categorization. It’s a framework designed around the idea that the decisions about vulnerabilities, rather than the severity of the vulnerability, are more important when thinking about prioritization in the process of vulnerability management. SSVC as an idea aims to improve the decision making process specifically in vulnerability management. You do this by using decision trees. The framework is designed so that you can inherently have multiple decision trees of different types depending on your role in the process. So, for example, the SSVC framework has the patch applier decision tree, the patch deployer decision tree, and then also with the release of the 2.0 version, they have the patch coordinator decision tree. It’s based on the role, and the framework itself is inherently designed with that idea in mind… that vulnerability management has a lot of different hands in the process, so that’s an advantage that I see with it.
SSVC acknowledges that vulnerability management is a very complex process with a lot of sub-processes and also a lot of people involved, right?
Ryan: Yeah. So, let’s take the patch deployer decision tree, for example. If you were to use the most basic deployer tree given to you by the SSVC framework, there are four different possibilities that can arise when you work your way through the decision tree. There is defer, which means to set aside the vulnerability, or rather set aside the patch for the vulnerability and to not apply it at present time. There is scheduled, which means to apply a fix to the vulnerability, and then apply that update in your environment’s normal patch cycle – whatever that may be. There is out of cycle, which means to apply a fix to the vulnerability and then also apply that update out of your normal patch cycle. And then there’s immediate, which means to apply the security fix as soon as possible, take on all possible resources that you can to do this (even if it hinders production). Get the fix out.
They can certainly differ. The overall idea as you’re going throughout the trees are definitely pretty similar in nature, but the final results can differ depending on what your particular role and the effect of the whole process might be.
Adam: The thing I was going to mention that remind me of, was ancient decision making framework I’ve been using forever to deal with, I’ll just call them inputs. Every day in life and in work we have inputs coming at us, whether it’s a slack message or an email or a meeting request or whatever it is. And I think it actually came from a ancient book about paper filing, how to keep up with when people actually had inboxes on their desk and paper would land in there, but it’s called FAD and it stands for file, act, delete. I can see now where you could maybe make it F-A-D-D, where the second D is maybe defer or something like that so it could improve upon it. But anyway, that was for paper filing a million years ago.
Ryan: There’s certainly merit to that comparison as well, because if you sit there with your piece of paper that you’re going to file and you have two boxes in front of you and sit there for an hour thinking about which box should I put this in, you’re going to spend an hour on each paper that you’re filing, and very slowly the stacks of paper are going to get higher and higher and the backlog is going to get larger and larger. So, that’s definitely a very clear contrast to vulnerability management today and how teams are just suffering from the overload of not only too many vulnerabilities to handle in general, but also too many high and critical vulnerabilities that say, “Hey, your environment is in immediate danger and this is a very large fire.” There’s simply too many of those right now.
SSVC as an idea aims to take a step back and think about the question, “Is the way that we are currently prioritizing things, even the most efficient way that we should do it?” So, it definitely has a good advantage there as well.
Why should SSVC matter to customers who currently run vulnerability management programs? Why implement it in your program?
Ryan: I think it’s biggest advantage is that a lot of organizations might use severity today as their main means of prioritization in general. So usually the way you would go about doing that is using CVSS scores, and that goes into the problem that I spoke about earlier, where you have so many high and critical vulnerabilities, there’s just no actual way to prioritize in reality with actual human hands doing the work.
SSVC aims to take that severity that is the entire scope of prioritization and, instead of leaning on that heavily, only making it one part of the decision tree, but not the whole. So for example, the deployer tree given to you by the framework, it starts specifically with the questions “Is there an exploit available? Is it widely available and widely being exploited, or is there a proof of concept available? And is it even possible to exploit?” And then if it’s not, all of those routes have a different ways down the tree.
If you work for an organization that makes software, it’s highly likely your supplier tree is going to belong to your development teams. They’re the actual patch supplier. They’re the ones changing the code and supplying the patch itself. And then the patch deployer is highly likely something like your IT operations team, the people that actually go about pushing out the update to all of production. So, when thinking about the supplier tree, you think about exploitation. If there’s none, or if there’s proof of concept, or if it’s widely available, and then beyond that you’re thinking about when the attacker is able to exploit it, is it laborious for the attacker, is it efficient, or is it super effective? And that essentially means upon gaining access or upon exploiting the vulnerability, how much of an effort is the attacker now putting in to make a wider impact based on what they’ve already got?
What does SSVC look like implemented within an organization?
Ryan: They have a GitHub available where you can actually apply this to your current processes within your team, but highly likely, it’s definitely a scenario in which if SSVC is something you want to implement, it definitely requires more hands than likely just the small amount of folks purely responsible for vulnerability management. It’s going to require communication with your CIS admin team, it’s going to require communication with your developers, it’s going to require communication with executives and other people responsible for communication that might come about.
When SSVC 2.0 came out, they also released a coordinator tree. That revolves around the person or the stakeholder obviously responsible for coordinating all of this. So, essentially, the processes can all look very different. It’s definitely something that you need to include quite a lot of people in your organization in. I think there’s also another inherent benefit there too, because as we’re slowly learning more and more about vulnerability management itself and trying to improve it, we’re learning and realizing that it has to involve the whole organization. And so that’s the whole rise of DevSecOps and other things like that. That’s along that thought, that vulnerability management itself definitely requires more hands than just the few people assigned to supplying the patches.
Adam: Correct me if I’m wrong, you’re asking disparate teams that maybe haven’t worked together before to work together. Is that right?
Ryan: Yeah, that could be certainly possible, especially if your security shop isn’t very matured and you don’t really have a lot of communication outside of the IT or CIS admin team. If you want something like SSVC to really work and shine, something like that has to change. and you have to learn to have wider communication and wider playbooks around remediating vulnerabilities. Not only can you customize the trees and make your own, but also you can certainly assign different stakeholder-specific decision making to whatever role it might be, or whatever business context you might be considering. So, if it’s something like what is the threat intelligence surrounding the specific vulnerability, you apply that to the supplier and the deployer, but that might not be as important to the coordinator. There are different things to consider depending on what business context is involved in the decisions that relate to each of the stakeholder specific trees.
One of the more neat parts about the framework is the specific idea that you can also customize it and make your own. There is a little bit of a disclaimer within the confines of the decision tree itself. Don’t expect total success if you just make your own willingly, definitely there’s still things to consider when creating your own decision tree. You don’t want the final result to be defer way too often, or something like that. So, it’s important to remember the disclaimer surrounding creating your own tree from the beginning of scope. But it’s also certainly necessary for your own unique environment. There might be some weird use cases that require certain different outcomes that environments might not require. CISA actually greatly explored SSVC and applied their own decision tree process. And then they’re also going to start populating NVD with results from this decision tree. I think that’s something that they’re working on, but I’d have to catch up on that. I’m not entirely sure.
Decisions are not numbers. Decisions are qualitative actions that an organization can take. So, many organizations today still use CVSS as their primary means of prioritization. And as we realize the exponential graph of overall exposed vulnerabilities continues to get higher and higher and higher, something like that is slowly going to become less and less practical. And so I think SSVC, just as a system, tries to just make that one part of decision making about a specific vulnerability, it just tries to make that whole process more efficient so that you can lower the fires a little bit.
