Why Managing Low-Severity Vulnerabilities Can’t Be Just a Pipe Dream

“Managing” vulnerabilities is an endless effort that is only truly noticed when it fails. More often than not, the constant debate over which vulnerabilities get prioritized for remediation is decided based on likelihood of exploit, followed by impact, and level of effort to fix. The typical result is that low- and medium-grade vulnerabilities get de-prioritized—in other words, not fixed—until there is no choice.

Vulnerabilities, no matter what they’re rated, do not exist in a vacuum. Consider Courtney's first law which states, “You cannot say anything interesting (i.e., significant) about the security of a system except in the context of a particular application and environment.”¹  So, what is that context?

For argument’s sake, let’s call out the typical situations when vulnerabilities must be fixed. This will help illustrate to all concerned parties, within security and beyond, that lower grade vulnerabilities should be fixed before they are exploited. Contrary to popular belief, low- and medium-rated vulnerabilities can get your apps and identities pwned.

In some cases, a vulnerability that was once rated low priority is now an elevated threat. There is a common lifecycle of vulnerabilities in which they evolve in threat level from theoretical concept, to proof-of-concept script, to point-and-click exploit tool.

In addition to reasons that include actual threats to your systems, there are ancillary reasons why a low-priority patch might be forced out. Such non-threat ancillary reasons can include the following:

1. A high-priority patch needs to be applied that requires the previous low-priority patch you didn’t apply yet (“queue chain”).
2. A researcher is publically calling you out and your execs want it fixed ASAP to avoid further embarrassment.
3. An auditor is demanding you do it for “compliance” reasons.

Active threat or not, an external push to patch something when the team isn’t ready is never ideal. People “under the gun” are prone to mistakes, and the scenario typically plays out with not enough time or capability to adequately test. Let’s face it, when forced to do out-of-band patching, everyone is frustrated, security team or not. These under-the-gun scenarios have a high likelihood of system outages or unintended application impacts that could negatively affect revenue. So why not avoid them? Although everything has a cost, no remediation effort is more expensive than fixing after a breach.

Vulnerabilities that are rated low can be combined with other attacks to increase their potential impact. F5 recently published two pieces about lower grade vulnerabilities that could, relatively trivially, escalate to a high, in which you would be dealing with a compromise situation. The F5 Labs article² about “three lows making a high” is particularly interesting, given the result is compromised Microsoft Exchange credentials. An F5 security operations engineer—in the trenches mitigating web application exploits on a daily basis—recently wrote a piece on combining cross-site scripting (XSS)³  with a little social engineering (zero security operators are surprised about how easy that is), to ultimately get admin credentials to a web app. Yet, XSS is commonly classified as medium risk and is still one of the most prevalent web application vulnerabilities.⁴ Developers often argue that XSS is “a customer browser issue” and “not a high risk,” concluding that “we don’t have cycles to fix low-risk technical debt.”

Bottom line is, if you are serious about not being hacked, you must understand the potential impact of all vulnerabilities, regardless of severity classification. You never know when three lows will make a high. You don’t want to be doing incident response trying to figure out how you were compromised, going through CVEs to determine if some low-grade vulnerability provided privilege escalation to another, defending why you weren’t fully patched, or arguing your case for not fixing known vulnerabilities because they were considered low risk. We all know this is much easier said than done, but it’s still worth fighting the good fight.

Here are some actions you can take within your organization to enhance your vulnerability management program:

1. Share relevant threat write-ups with business counterparts and DevOps management.
2. Implement a WAF. It’s your best bet for timely remediation of web application vulnerabilities.
   • Think of a WAF as a temporary patch. You still need to have a robust software development lifecycle (SDLC) where developers are focused on secure coding, QA is trained to run security testing tools and understand the results, and also to run continual dynamic scans and a static scan of each release.
3. Schedule quarterly vulnerability remediation days where your security engineering team is sitting in a war room with developers who are coding, and everyone is testing, and testing again. (Call it a Hackathon and sponsor some t-shirts if you have to!)
4. Scan for network and OS vulnerabilities at a minimum of monthly, and give IT the reports. Reports give you peace of mind, and are valuable for them during performance reviews.
5. If you run into a scenario where an OS patch was missed, make sure it’s included in the following month (and remind IT of a time when they had to scramble testing a really old patch that was missed and how much of a mess it was!).

I hope this gives you more insight into looking deeper at your vulnerabilities—all your vulnerabilities. Here’s hoping you don’t have any more patching fire drills or breaches.