The enemy of vulnerability management? Unrealistic expectations

Organizations vary by size, industry, level of maturity, but one thing that they all have in common is needing to know how to quickly remediate security vulnerabilities.

As an experienced vulnerability management professional and a former system administrator who specialized in patching and remediated 800,000 vulnerabilities over the course of my career, I can offer some realistic perspective on this topic.

One reoccurring discussion I’ve had is how long it takes for a new vulnerability to get exploited. The answer to that question is that it depends. And unfortunately, by the time you know about it, you’re already behind the curve. In some cases, active exploits exist before the vulnerability becomes public knowledge. On the other extreme, some vulnerabilities from the turn of the century still don’t have reliable active exploits.

The danger of unrealistic expectations and unfulfilled promises

Much of this is like asking how long it takes to produce a new piece of software. Some software arrives ahead of schedule. Some software arrives so late that it becomes a joke. For example, the words Duke Nukem Forever still mean something to people of a certain age range. It was once an eagerly anticipated installment of a hugely popular video game franchise, but it took forever to produce and release, so the game was woefully obsolete when it finally hit the market.

And some software, or at least hotly anticipated features, never arrives. Microsoft once announced an advanced file system based on a relational database as part of its Longhorn project, which became Windows Vista. It was complete enough to demonstrate in 2003, but it never matured enough to ship. So here we are, 19 years later, still using NTFS.

There is no reliable data based on which to determine within how many days you should remediate certain vulnerabilities. But by relying on the intelligence and data you do have, and based on what other companies have implemented successfully, there are some good places to start.

How to get away from “whack-a-mole” patching

While predicting how long it will be before a vulnerability will be exploited is not practical at the present time, the EPSS (Exploit Predictive Scoring System) model can help to predict the likelihood of a vulnerability being exploited within the next 12 months. So, while you cannot tell if a vulnerability will be exploited in 30 days versus 180 days, it does stand to reason that a vulnerability with an EPSS score of 99 out of 100 will probably be exploited sooner than a vulnerability with an EPSS score of 11 out of 100.

When it comes to how quickly to patch, I can talk about what the rest of the industry does, what the US government recommends, and what works from a system administrator perspective.

First and most importantly, you need to be realistic. Many organizations want critical vulnerabilities fixed within seven days. That is not realistic if you only have one maintenance window per month. Additionally, if you do not have the ability to reboot all your systems every weekend, you are setting yourself up for failure. If you only have one maintenance window per month, there is no reason to set a due date on critical vulnerabilities any less than 30 days.

For obvious reasons, organizations are nervous about speaking publicly about how quickly they remediate vulnerabilities. One estimate states that the mean time to remediate for private sector organizations is between 60 and 150 days. You can get into that range by setting due dates of 30, 60, 90, and 180 days for severities of critical, high, medium, and low, respectively. Better yet, this is achievable with a single maintenance window each month.

As someone who has worked on both sides of this problem, getting it fixed eventually is more important than taking a hard line on getting it fixed lightning fast, and then having it sit there partially fixed indefinitely. Setting an aggressive policy that your team cannot deliver on looks tough. But attackers don’t care how tough you look. It’s better to take a softer approach that your teams can deliver on, and then figure out how they can step it up.

I would also argue that most of the time, 30 days is more than fast enough. For instance, when it comes to protecting critical infrastructure, CISA gives six months. It’s a tradeoff. In an ideal world, you would get it done much faster than that; realistically, however, six months is a challenge for many organizations. I’ll also refer to a policy document from the Internal Revenue Service, which gives 30 days to patch critical and high vulnerabilities, with the difference being how quickly you have to start. For medium and low vulnerabilities, the window is longer.

What does success look like in vulnerability patching?

The main enemy of vulnerability management is not attackers, but unrealistic expectations. Most people I talk to assume they are unique (or nearly so) in their struggles to patch faster and more effectively, and that everyone else gets their vulnerabilities fixed faster. While there’s not a lot of data available publicly, the data that we do have suggests otherwise.

Remediating vulnerabilities takes more than enacting a policy. It also requires skills and tools, and there aren’t a lot of options outside of doing it on the job to learn those skills. Anyone can blast out updates to your network, but if you want a success rate higher than 70%, you at least must know where your operating system stores the logs related to the application of those updates, and how to use the information in those logs to figure out what went wrong when they fail. It’s an ongoing process of working smarter to hit realistic SLAs, and measuring improvements in your program, to track performance and impact.