Jul 19, 2023
When is a Critical Vulnerability not a Critical Vulnerability?
How many security vulnerabilities exist in your organization? Thousands? Hundreds of thousands? Millions? It depends on the size and type of your organization. Whatever the number, how do you prioritize vulnerabilities in terms of their impact on your business? And before we go there, here’s another question: What is a critical vulnerability?
Perhaps you rely on the Common Vulnerability Scoring System (CVSS). But that’s a quantitative measure of the severity of a vulnerability as determined by a third party. It’s not a measure of risk.
Further complicating how to assign the correct risk score to vulnerabilities is determining the risk each vulnerability poses to your organization — not to all organizations in general. Along with classifying a vulnerability as low, critical or somewhere in between comes the corresponding service level agreement (SLA) that defines how long the owner of the affected asset has to remediate it.
When Is a Critical Vulnerability not a Critical Vulnerability?
If the SLA for remediating critical vulnerabilities in your organization is, say, 7 days, and you have a lengthy list of them, then your odds of successfully meeting that SLA are not very good. But before you start trying to tackle all of those apparently critical vulns, ask yourself this question: Are all of those “critical” vulnerabilities really critical to your organization?
Let’s look at that question from a less technical perspective. If your basement suddenly floods, putting some electronic equipment at risk, you might say, “Those devices cost hundreds of dollars. We need to save them immediately.” But on the other side of the basement are boxes full of family photo albums from your parents and grandparents. Which items are more critical to save?
That’s why the level of risk for a particular vulnerability might not be as critical for your team as you initially thought.
With all the security tools organizations have deployed, teams have more vulnerability data than ever. So how do you determine genuine risk? In other words, what really is a critical vulnerability for your organization?
When it comes to the number of vulnerabilities exploited each year, the problem continues to grow.
And if you look at the problem based on the CVSS vulnerability rating, the bad guys are definitely focusing on higher-rated vulnerabilities.
How to Prioritize Risks
There are numerous factors your organization could consider to prioritize risks, and ultimately determining which factors are important should have the blessing of senior leadership. Start by asking:
- Is the affected asset internet-facing?
- Is the system in scope for compliance programs?
- Does the affected asset process sensitive data?
A word of caution: This process is likely to make a significant impact on your organization’s security program. Plan carefully before acting. Applying the risk factors noted here could change the overall count by hundreds of thousands of vulnerabilities.
You can also take these actions to make your vulnerability management process more risk-based:
- Leverage threat intelligence to prioritize actively exploited vulnerabilities.
- Determine whether you can deprioritize any development/sandbox environments.
- Deprioritize vulnerability classes/sources that are more prone to false positives.
- Factor in compensating controls such as firewalls, the existence of endpoint detection and response (EDR), etc.
SLAs Don’t Change, but Vulnerability Risks Often Do
Your organization undoubtedly has standards that say critical vulnerabilities must be addressed quickly, perhaps within 7 days. On the other hand, low-level risks may have an SLA of 365 days for remediation or no SLA deadline at all.
When it comes to identifying and remediating the most critical vulnerabilities, time is increasingly of the essence.
The thought process behind risk-based prioritization is that what’s under the hood — what you call critical, what you call high, medium, etc. — is changeable based on factors that are salient to your business and your environment. So if one of your security tools identifies a vulnerability as critical, the SLA clock starts ticking — fast.
But what if, as the team begins digging into the issue, they realize it really isn’t a critical vulnerability because it’s in a sandbox environment and not internet-facing, or the actual software library is not being used?
The organization’s SLA for critical vulnerability remediation remains 7 days, but this particular vulnerability is now labeled low risk. The SLA policy doesn’t change. What changes is the rating of that specific vulnerability.
Imagine the positive effect on the security team and asset owners if vulnerabilities once labeled critical or high, are correctly reclassified as low risks. Those teams would have more time to focus on what’s really important and spend less time working on less important tasks.
However, that puts the responsibility squarely on the security team to be sure of their findings before they classify vulnerabilities as critical with a 7-day SLA. If the team that owns remediation determines that a “critical” vulnerability was actually less severe, its trust in the security team can erode quickly. Don’t become “the security team that cries wolf.”
Business Context is the Key
When categorizing the severity of vulnerabilities, business context is essential. Let’s look at a specific use case: You have a server with one or more vulnerabilities. Your CMDB indicates the server is internet-facing. Before you conclude that any vulnerability in an internet-facing server is critical, you need to relate that CMDB data with vulnerability data to get the complete picture of the level of risk your organization is facing before work begins to remediate those vulnerabilities. That’s what we mean by applying business context to vulnerability assessment.
Before you panic about having X number of critical vulnerabilities targeted for remediation within 7 days, perform a risk assessment on those vulnerabilities to properly categorize them. You’ll see how many critical vulnerabilities you really have, so you can focus on remediating them within your organization’s SLA instead of spending precious time addressing vulnerabilities that turn out to be less critical to the business.
Automate vulnerability prioritization with Brinqa
The Brinqa Attack Surface Intelligence platform is designed to revolutionize the way organizations manage their cyber risk by automating the correlation of business context and the risk scoring process. Saving organizations from ineffective manual processes, Brinqa’s analytical engine leverages thousands of custom risk factors to produce actionable recommendations that lead to the timely remediation of security flaws.
Oh, and one more bonus to automating this process with Brinqa: no more unwieldy spreadsheets that become too big for any computer to open! Read more about this and related topics in our eBook It’s Time for a New Approach to Vulnerability Management.
Put the Brinqa platform to the test. Request a demo with one of our solution engineers today.
FAQ:
What is the difference between a critical vs. a high priority vulnerability?
In cybersecurity, vulnerabilities are typically categorized according to their severity to help prioritize remediation efforts. Though the specifics can vary between different vulnerability rating systems, only the most severe vulnerabilities are labeled as critical.
Critical vulnerabilities usually have a high likelihood of being exploited and the potential to allow an attacker to cause extensive damage or fully compromise the affected system. They demand immediate attention and come attached with very short SLAs.
High-priority vulnerabilities are still serious security weaknesses but are generally considered somewhat less urgent compared to critical vulnerabilities. Perhaps the potential damage is slightly less, or exploiting the vulnerability might require more complex or specific conditions. While still near the top of the prioritization list, these should usually be addressed after all critical vulnerabilities have been handled.
How can the risk level of a vulnerability change over time?
The risk level of a specific vulnerability might change over time due to various factors:
- Change in environment: If the system or environment where the vulnerability exists changes, the risk posed by the vulnerability might also change. For instance, a system previously not connected to the internet becoming internet-facing can increase the risk level.
- Discovery of exploit: When a vulnerability is first discovered, there may not be any known exploits. However, if an exploit later becomes available or is actively being used in the wild, the risk level can significantly increase.
- Application of patches or fixes: When patches or fixes are applied, the risk level of a vulnerability can decrease. However, it’s also possible that a patch doesn’t fully address the vulnerability or introduce new vulnerabilities, in which case the risk might not decrease as much as expected, or it might increase.
- Change in asset importance: The importance of the asset where the vulnerability is located can also change over time. For instance, a server might start hosting more critical data or services, increasing the potential impact of a vulnerability and, therefore, its risk level.
- Introduction of compensating controls: If new security controls are implemented that help protect against the vulnerability or limit its potential impact, the risk level can decrease. For example, a new firewall rule might limit network access to a vulnerable system, or an intrusion detection system might be set up to detect attempts to exploit the vulnerability.
- False positives/negatives: Upon further investigation, what was initially identified as a vulnerability might turn out to be a false positive, or the severity of the vulnerability might have been over or underestimated. The initial risk assessment could also have missed some vulnerabilities (false negatives), and these could be identified in later assessments.
