Regardless of how good you are at vulnerability management, there is always a looming sense in this field that you missed something or could have remediated something faster. But on the other end of the spectrum, there’s only so much you can do when you’re handling vulnerability management the traditional legacy way, as the numbers are just too overwhelming for tackle on your own.
That’s why it’s important to layer in threat intelligence to help whittle down the vulnerabilities that are stacked up in front of you and find your urgent needle in the vulnerability haystack. From there, you can use methods like SSVC decision trees to help prioritize your vuln stack even further.
The Importance of Threat Intelligence in Vulnerability Management
Vulnerability intelligence promises to solve the overwhelming stack of vulnerabilities by reducing your focus down to the number of vulnerabilities that need urgent action. Under legacy CVSS, somewhere between 51 and 71% of your vulnerabilities rate critical or high. In 2022, the CVSS score of the average new vulnerability disclosed was 7.2, which is high criticality. Under most information security policies, that means the average vulnerability needs to be fixed in 30 days.
However, when you layer in vulnerability intelligence, you can reduce the number of vulnerabilities that need to be fixed on a short timeframe like seven or 30 days to somewhere between 5 and 12%, depending on the product.
But unfortunately, this method too can be problematic. No two feeds agree 100% of the time on which vulnerabilities matter most. In fact, we have published some advice on evaluating the quality of a vulnerability intelligence feed. However, no matter which one you pick, there is always the fear that next year’s auditor is going to hassle you on your decision, or that some future personnel change will result in questioning the decision and requiring a complete rebuild of your vulnerability management program.
The usual objection that we’ve grown used to hearing is, “What if I miss a critical?” But the true problem is that, since every organization wants to define criticality levels differently, you are going to miss a critical. That is, unless you use SSVC to catch those exceptions.
Using SSVC For Prioritized Threat Intelligence
SSVC isn’t just CVSS spelled backward. It is a framework for using available information to make sensible and defensible decisions about what to do with a vulnerability. Simply implementing your existing security policy in a tool that automates it isn’t enough. You simply find out that what you are doing isn’t working, just faster and with less analysis than before.
The CISA Stakeholder-Specific Vulnerability Categorization (SSVC) is a customized decision tree model that assists in prioritizing vulnerability response for the United States government (USG), state, local, tribal, and territorial (SLTT) governments; and critical infrastructure (CI) entities. – CISA.gov
While SSVC was initially defined at Carnegie Mellon University where they produce a 70-page whitepaper explaining the concept, CISA shortly followed suit with a 10-page whitepaper that was much less about theory and more about implementing a decision tree. An organization could easily print out the CISA white paper, add some notes about where to find the criteria CISA defines, and have what they need to start analyzing vulnerabilities.
This method of prioritizing vulns solves the problem for numerous organizations, whether they are government or private sector. Every month, there is a new high publicity vulnerability that everybody is worried about — we know, because we get questions from reporters and customers alike — and people scramble to determine if they’re affected by it and whether or not they should fix it right in this moment before their executives or board come asking those same questions.
Thankfully, SSVC provides a framework to tell you when you are going to fix it.
The Use Case for SSVC
Let’s go back in time to when Log4Shell hit last year… that was fun, wasn’t it? Some organizations were so frantic in trying to determine what they needed to do regarding the vulnerability that they made the decision to work around the clock to remediate throughout the month of December. It didn’t matter which of the 14 holidays in December it was, you were working.
The reason for this came down to organizations not knowing what to do. However, in the absence of any good answer, no one could fault them for working as hard as they could. Every manager involved could say they did everything that they could, including cancelling holidays.
If they would have used SSVC, based on the information they had about each available system, and based on what Mandiant was saying about the available mitigations and the exploit consequence, they could have automatically triaged not just every vulnerability in their network, but every instance of that vulnerability.
Using SSVC With Nucleus Security
Implementing SSVC in Nucleus takes some work, but for most organizations, the payoff is worth it. Plus, the beauty of the decision tree is that once you have it built, you can implement finding processing rules in Nucleus to evaluate every instance of every vulnerability in your environment.
It starts with defining a policy based on risk rating and due dates. The most common we see is seven or 14 days for critical, 30 days for high, 60 days for medium, and 90 days for low. That defines a reasonable baseline.
From there, you just need to handle your exceptions. This involves making a decision tree and translating it into rules that factor in exploit consequence, the quality of the exploit, asset criticality, and data sensitivity. The number of rules that you need depends on how granular you want to be. For a low degree of granularity, you may be able to get it done with as few as 16 rules. A high degree of granularity may require closer to 100 rules. Once you have the rules built, they operate every time you import a new scan, and they handle any changes in the threat intelligence for you.