If you’re trying to patch every high and critical severity vulnerability, you’re probably about as effective as patching none of them while spending a lot more time on it. While a handful of sage (or, perhaps, wild-eyed) readers are nodding in agreement, many more are starting to panic that I would suggest “not patching” as a strategy for vulnerability management.
Don’t worry – that’s not where we’re headed. We’re finding zen in the chaos of vulnerability overload.
Still, vulnerability management is, unquestionably, one of the hardest problems that is facing security teams today. It was also one of the hardest problems last year. And the year before. Year before that, too.
Challenges in prioritizing vulnerabilities
Without trying to enumerate all the problems in the vulnerability management space (I still routinely talk to orgs that are exporting CSV files of vulnerabilities and emailing them to developers), let’s talk about a few specific things:
- Research from Cyentia Institute shows that, on average, organizations can address about 10% of vulnerabilities in their environment every month. This remains pretty constant no matter how many vulnerabilities the org has.
- Exploit Prediction Scoring System (EPSS) is an approach to estimating the likelihood of a particular vulnerability being exploited in the next 30 days. While the numbers vary from day to day, only about 10% of vulnerabilities are more than 2% likely to be exploited in the next 30 days. About 5% of vulnerabilities are more than 10% likely to be exploited.
- In Orca’s 2024 State of Cloud Security report, we found that nearly 40% of organizations have public-facing assets that are vulnerable to Log4Shell with 0.6% of all public-facing assets being vulnerable. Log4Shell was first discovered in late 2021 and has been persistently exploited since with EPSS estimating that it’s ~97% likely to be exploited now.
These numbers tell us that, if orgs can only patch about 10% of their vulnerabilities and only 10% of vulnerabilities are even remotely likely to be exploited, it’s important that these two circles of 10% are closely aligned. If you’re patching primarily based on the severity of the vulnerability itself, it’s quite likely that they’re not…and that you’re patching a lot of vulnerabilities that are unlikely to be a problem while missing the ones that are.
How Orca prioritizes vulnerabilities
I typically break it down to a focus on three things to help organizations effectively prioritize vulnerabilities and focus on the right ones:
1. Severity
This focuses on how bad the vulnerability itself is, starting with the CVSS score that’s assigned to the vulnerability. CVSS scores range from 0.0 (which has no real impact) to 10.0 (which is as bad as it can be) as well as the information that the CVSS metrics tell us such as what could an attacker do (does it allow for remote code execution?) and whether it requires interactivity – as, in the cloud, we’re primarily worried about vulnerabilities that can be exploited without interaction.
As we saw above, though, focusing solely on the severity of the vulnerability is unlikely to enable an organization to efficiently patch what’s really important.
2. Exploitability
As we’ve already established, it’s important that we take into account not just how severe the vulnerability potentially is but, also, how likely it is to actually be exploited. For Orca customers, this starts with information about the likelihood of exploitation – EPSS, as we already discussed, along with other data such as CISA’s Known Exploited Vulnerability (KEV) list that collects vulnerabilities that CISA has observed being exploited and, more generally, the presence of exploit code publicly available. These factors are automatically included in Orca’s risk prioritization.
This still only tells us, generally, that the vulnerability is exploitable. The other factor that Orca considers is the actual availability of the resource where the vulnerable code is present. For example, if we have two virtual machines that both have the same CVSS 9.8 vulnerability that’s currently being exploited but one of those VMs is accessible from the entire Internet via a load-balancer and the other is not, we can say it’s more likely for the publicly accessible VM to be compromised.
3. Asset context
Severity and exploitability help to prioritize but there’s another factor that organizations should consider. Some assets are critical to the business while others are less critical. The context of the asset is an important consideration in prioritizing where to focus remediation efforts.
Orca has a lot of visibility into where critical assets are located and this visibility is included in risk prioritization. A simple example is that, if compromised, a VM that stores sensitive data such as credit cards or healthcare data would have a higher impact than a VM that doesn’t. Of course, even if the VM doesn’t directly store sensitive information, it may be part of an attack path that combines the particular vulnerability with other configurations (and misconfigurations) that would allow an attacker to use exploitation of the VM as part of a larger kill chain – Orca’s risk prioritization factors this larger picture in, as well.
Orca’s granular risk scoring system
The Orca Security Platform combines all of these dimensions into an Alert Score that lets organizations quickly understand where to focus their efforts. For example, even though there are a number of assets vulnerable to Apache Log4J Remote Code Execution vulnerabilities, they have a wide range of scores based on the severity of the specific vulnerability, the exploitability, and the asset context.
Other approaches to vulnerability prioritization
Some organizations have already built custom approaches, using their own code and platforms, for sifting through vulnerability data, exploitability, and asset context and built their own tools for prioritizing based on similar approaches. When those organizations are also Orca Security customers, they can use our robust APIs and data to easily integrate into their own framework.
CISA has also introduced Stakeholder-Specific Vulnerability Categorization, or SSVC, which is a different, standardized approach to prioritizing vulnerability remediation using similar inputs. SSVC weights active prioritization more than likely exploitation but solves a very similar set of problems to help organizations address the vulnerabilities with the most significant impact.
Ready to find your vulnerability management zen? Sign up for a personalized demo and discover how the Orca Cloud Security Platform can help you intelligently prioritize and address your most critical cloud vulnerabilities.
