8 Common Vulnerability Management Mistakes to Avoid

Oct 25, 2018

Share with Your Network

Vulnerability management is often undersourced and undertooled, and yet stands at the epicenter of protecting the organization from a breach. Bringing to bear best practices can mean the difference between success and failure, but in an industry still attempting to understand effectiveness and unable to learn from near misses, what does “best practices” mean and what evidence exists that supports them? In the trenches as former CISO of Orbitz as well as my work with hundreds of enterprise customers here at Kenna Security, here are eight of the mistakes that I’ve seen the most successful security teams avoid.

1. Remediate All the Things
This may be the hardest thing for security teams to understand: You get no prizes for fixing as many vulnerabilities as possible. In fact, if you do that, you’ll be expending precious energy and resources fixing the wrong things. We did a research study with the Cyentia Institute that found that less than two percent of vulnerabilities are actively exploited in the wild.

Prioritization is key. Which are the vulnerabilities that truly pose a clear and present danger to your infrastructure, based on your assets? Hint: relying on a static CVSS score—which has no relevant context for the actual threats to your specific organization and environment—won’t give you the full picture.

Your development team will thank you for having a clear strategy for knowing what to remediate and when—and then strategically allowing them to ignore the several thousand vulns that won’t actually make a material difference.

2. Rely Too Much on a Single Tool (*cough* Excel *cough*)

If prioritization is the name of the game, Excel can’t be the core of your strategy. Why? Because organizations are expanding the footprint in all directions, which means you won’t be able to keep up with the sheer volume of vulnerabilities and exploits using manual methods. Even if you’re able to wrangle all of this data into a spreadsheet it’s a camera, not an engine. It represents a single point in time whereas both your environment and the threats to it are changing dynamically. Find the right tools and platforms that can help make your prioritization efforts as automated and scalable as the techniques employed by your adversaries.

3. Lack The Correct Data Sources (vulns + threats + business context)

What are the ingredients for automated prioritization? This is another area where Excel fails because Excel will help you crunch the numbers but it won’t get to the heart of the issue, which is the need for context. How do you get context? Using vulnerability data as a base, you’ll need to add threat and exploit intelligence. But be selective about your data sources. When adding threat intelligence to vulnerability and asset data, you want to be heavy on the “how” and light on the “who.” What vulnerabilities are being exploited and how? What can you learn from past exploits? And if you have access to zero-day vulnerabilities, you’ll want a way to correlate that with your assets.

This gets to understanding your assets—where they are located, how they are accessed, what are they running, and how important they are. This is all critical context you need to have when prioritizing issues. Remember—you don’t want to remediate all the things. Just the ones that matter.

4. Ignore Your Risk Landscape

Other teams track their progress on a regular cadence, carefully evaluating where they were last quarter versus this quarter. I’ve seen security teams do this as well, but often only in terms of tracking the sheer quantity of vulnerabilities they’re reducing. This is playing the numbers game (and doing it badly).

What matters is your team’s work set against a larger risk landscape. What is your organization’s risk, where was it two quarters ago, and how has it reduced or increased over time? Which assets are most affected, and how can you minimize that risk with the least amount of effort (meaning, which vulnerabilities can you remediate that will make the most impact?)

Shifting from a vulnerability mindset to a risk-management mindset is absolutely critical.

5. Get Caught Up Reacting to Headlines

Here’s an all-too-familiar scenario: Your CEO comes to you in a panic because the board is breathing down his or her neck to make sure you’re protected from the latest, high-profile breach or vulnerability with a logo that’s hit the headlines. They want your team to drop everything and remediate those vulnerabilities right now.

If your team gets caught up in the hype, you run the very real risk of missing critical vulnerabilities. Sometimes addressing the high-profile vulnerability right away is warranted, like with Heartbleed, which affected the most popular open-source cryptographic protocol relied upon by millions of websites. Often, however, reacting to hype can result in your team hunting down and remediating a vulnerability that doesn’t pose any real danger.

Effective vulnerability management requires a risk-based approach to prioritizing remediation efforts so that the right vulnerabilities are addressed at the right time. Regardless of the headlines.

6. Don’t Use Predictive Models to Your Advantage

Using data science to figure out which vulnerabilities will be weaponized and exploited before they are may still seem like science fiction. It is not. It’s true that we’re still working on and refining these models, but with the vast data sets and the machine learning algorithms we have available to us today, it is a mistake not to take advantage of these technologies now. Just imagine. You can finally understand the likelihood of a vulnerability being exploited the day it goes live. No lag time.

7. Address AppSec the Same as SecOps

Application security. It’s got some distinct headaches not shared by network security. Don’t forget that. For instance, while AppSec may not have to worry about as many vulnerabilities overall, it is a much more involved process to remediate any given vulnerability. Because nearly all applications include custom code and therefore contain vulnerabilities that only exist in that particular app, patches have to be written by the development team (as compared to network vulns that are written by the vendor where IT can move straight to testing). Potentially a very time-consuming endeavor. For this reason, it is even more important to clearly identify and only remediate the vulnerabilities that present the greatest risk to your organization. Be sure to give your AppSec team the tools, technologies, and understanding they need in the workflow they already use.

8. Forget That Your Priority Isn’t Always IT (or Dev)’s Priority

Security is rarely the team actually implementing the patch that fixes a vulnerability. For that, we rely on the IT team, DevOps, or your development team. Don’t forget that. Everyone likes to know the reason behind the decisions that impact their workload, so don’t just send your list of vulnerabilities to patch to IT and consider the job done. You’ll get a much better response if you give them an understanding of why you chose those vulnerabilities, why they are a priority, and why they should spend their time remediating them. Because we’re all human and like to know the “why.” And we’re all part of the same team.

Summary

Avoiding these common mistakes can create great dividends for security teams who have to do a lot with a little. And don’t forget the most important tip—be sure to celebrate your successes. Don’t hold back on the beer.

Note: if you’re a long-time reader of my blog, this post may seem familiar. That’s because I’ve updated the original from July 21, 2015 to add in changes in the space and things I’ve learned in the meantime. Also, if you’ve been reading my blogs since 2015—thank you!