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.

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.