There’s an old saying that pops up on my radar every few months. I’ll usually see it while scrolling through my feed on Linkedin or occasionally, I’ll see it framed on someone’s office wall.
If you don’t prioritize your life, someone else will.
This statement is especially true when it comes to an infrastructure risk-based vulnerability. If you don’t prioritize them right, an attacker will prioritize them for you. Don’t take my word for it, all you really need to do is simply turn on the news. Every few days there’s a sad story about a company that has just been hacked. Sometimes the damage is minimal but even minor vulnerability exploits are extremely costly both in terms of hard costs and credibility.
Every day, we face the constant challenge of choosing from things that need our urgent attention and ones that are just important. If we fail to distinguish urgent items from the important, it will eventually lead to catastrophic failure; It’s not a matter of if but when. In short, identifying our priorities and executing them in our daily workflow is the key to success in any walk of life.
The Vulnerability Prioritization Problem
Identifying and prioritizing the right set of vulnerabilities to patch is easier said than done. It’s a difficult problem to solve and it’s only going to get worse. To understand why we need to go back in time to a pre-CVSS era.
Not too long ago (before 2003), security researchers didn’t have a common method to rate the severity of infrastructure vulnerabilities. Two researchers could rate the same exact vulnerability in completely different ways based on their subjective understanding of the vulnerability. This created confusion for responders because they couldn’t accurately determine the actual severity of vulnerabilities. As time went on and technology evolved, a new open industry standard was created called the Common Vulnerability Scoring System (CVSS). It was developed for the uniform severity assessment of vulnerabilities. The new standard calculated the severity based on several factors.
A key factor to keep in mind is that it calculated the severity of the vulnerability–only; not the risk it posed to an organization. For example, there could be a remote code execution vulnerability that granted root privileges to the attacker but posed no real risk to the organization; either because the system was not remotely accessible or maybe it was a low-value asset, completely isolated from the rest of the organization. CVSS would still view that vulnerability as a critical vulnerability that needed to be patched.
Since there were no readily available mechanisms to determine the risk of the vulnerability, CVSS scores over time started getting used as a proxy for determining the risk it posed to the organization. Which lead to a few unintended consequences. Countless patching cycles were spent fixing vulnerabilities with a score of 7.5 or higher, and ones with medium severity were deprioritized even if they posed a greater risk. Security researchers prioritized finding vulnerabilities with a higher CVSS score which lead to a high number of vulnerabilities with a CVSS severity of High. According to the latest data from the National Vulnerability Database over a third of the vulnerabilities had a severity of High.
As I’m sure you can imagine, the end result was many vulnerabilities were patched, but it didn’t bring down the risk in a meaningful way, at least in a way that could be effectively communicated back to the management.
In later years CVSS version 3 was introduced to fix some of these issues, but it still fell short of expectations.
To address these issues software vendors in recent years have introduced new solutions to the market which add additional context and determine the true risk from the vulnerability.
These solutions take into account not only the CVSS score but additional factors such as whether the vulnerability is actively exploited in the wild based on information from real-time threat intelligence feeds. The ease of exploitability, vulnerability age, coverage in news media are a few of the key factors. It also takes into account the value of the asset, whether its internal or external-facing and applies state of the art machine learning algorithms to determine true risk.
Two vendors KennaSecurity, and Tenable have addressed this problem really well with their respective risk-based vulnerability management solutions.
SaltStack Has the Answer
In our latest release, SaltStack added support for both KennaSecurity and Tenable.io. SaltStack Protect can import vulnerability data from both vendors and provide a prioritized view of vulnerabilities with Kenna Risk Score, and Tenable Vulnerability Priority Rating.
Once imported, SaltStack Protect provides fast, automated remediation for critical vulnerabilities in the infrastructure prioritized based on risk, not just severity of the vulnerability.
Here’s a video demonstration of our integrations with Risk-Based Vulnerability Management solutions.
We are excited to have this functionality in the hands of our customers, and can’t wait to hear back from you.
SaltStack and KennaSecurity will discuss risk-based vulnerability management with KennaSecurity and fast, automated remediation with SaltStack Protect.