This post summarizes a recent webinar “Is Everyone Doing Vulnerability Management Wrong?”, where vulnerability management advisors share common mistakes they’ve seen and offer practical advice for building a risk-based vulnerability management program.

Is everyone doing vulnerability management wrong? For most of the industry, vulnerability management is, and will likely always be, a work in progress. Many of the challenges vulnerability management teams face today are the same as they’ve always been; they’re just getting bigger and more complex. There’s more scan data, more assets, and everything is more connected. The work may be the same, but the scope is much greater.

As the saying goes, “insanity is doing the same thing over and over and expecting different results.” For years, we’ve pulled the scans, consulted the CVSS, and sent patch tickets over the fence. We’ve added a layer of technology to make it all go faster, but are we really making any progress? Vulnerability management still feels a bit reactive, a box that needs to be checked.

In our team’s collective experience advising clients in vulnerability management, we’ve seen some common misconceptions that stand in the way of becoming more proactive and more essential. This post will challenge those misconceptions and offer guidance on how to break some of the patterns we vulnerability management practitioners have fallen into.

Watch the on-demand webinar: Is Everyone Doing Vulnerability Management Wrong?

Misconception 1: Vulnerability management is just vulnerability reporting.

Why do you do vulnerability management? Did a regulatory body mandate it? Did someone in leadership decide it’s important, so it finally got funding? These are very reactive origins for vulnerability management. The truth is vulnerability management has the potential to be the most proactive of all the security disciplines. It should be the foundation of every security program. A good vulnerability management implementation reduces risk and costs across the organization. You’ll have fewer incidents, rely on SIEM less, and have fewer patching fire drills.

When we talk about improving vulnerability management, we need to look beyond vulnerability scanning and reporting. These are not the biggest issues we face. Instead, look at how to improve vulnerability tracking, prioritization, and education to reduce risk across the organization.

Misconception 2: Anyone can do vulnerability management.

As a general rule, vulnerability management has been viewed as an entry-level position. We often hire recent college graduates who get assigned to a vulnerability scanner they pull a report from, a big behemoth of a .csv file, and send out to the appropriate party.

To move beyond vulnerability reporting, a vulnerability management analyst has to be multi-disciplined. They should have experience with pentesting, business leadership, networking, and technology. With this experience, they’ll be able to do more than review a report of vulnerabilities. They can analyze how vulnerabilities can be used in a chain attack to, for example, reach an active directory server. They can tailor their reports and recommendations based on more than a CVSS score, and they can confidently brief business leadership on risks and impacts.

Misconception 3: Vulnerability management analysts are solely responsible for vulnerability management.

Vulnerability management is a collective responsibility that requires top-down leadership and a lot of communication. There are typically four stakeholders in a vulnerability management program – your VM team, the business units, IT, and GRC.

At its core, your VM team should be responsible for 1) identifying vulnerabilities in your environment and 2) educating business units about the risks and impacts. Your IT team is responsible for patching, and your GRC team is responsible for enforcing SLAs.

Vulnerability management analysts make great bridge builders between these functions. They need to understand pain points, priorities, workloads, and release schedules before making recommendations or assigning work. Having that business context helps earn trust. A little charisma doesn’t hurt either.

Misconception 4: The goal is 100% vulnerability remediation.

We see a lot of teams hyper-focused on vulnerability count. It’s an easy metric to report on, but it’s ultimately pretty meaningless. The number of vulnerabilities in your environment can change hourly. New vulnerabilities are released all the time. Spikes and drops will happen just due to the natural flow of business. These counts mean nothing and cause panic, especially when presented in front of an executive and board-level audience.

There are two much better metrics to measure the progress of your vulnerability program — average risk level and percent compliance.

Average risk level will communicate where you are at risk and if that risk is going up or down. If you’re trending up, you can explain why. Perhaps, Microsoft released a big patch Tuesday, so there are temporarily more vulnerabilities. Remediations are in progress, so you expect to see the risk level drop next month. It’s a much smoother conversation.

Level of compliance looks at the percentage of vulnerabilities where 1) the SLA has been met or 2) there is a documented exception to the SLA and that exception has a review date that meets compliance. Enforcing compliance is up to your GRC team. Instead of 100% remediation, aim for 100% compliance.

Misconception 5: CVSS ratings are all you need for vulnerability prioritization.

You can’t throw every vulnerability over the fence. Well, you could, but it wouldn’t make you very many friends. So how do you determine priority? What is actually critical?

Most vulnerability management teams rely solely on the CVSS score or whatever score is provided by their scanning tool (which is likely based in some part on CVSS). The big issue with the base level CVSS is that it lacks both internal and external context.

You can get some of that context from the additional levels of the CVSS. The base level that we’re all familiar with is based on the potential damage of an exploitation. The other levels take into account how long the vulnerability has been out and whether there is an active exploit.

You can add that context to factors in your own environment to get a more targeted score, factors like:

• Criticality of the asset
• Dependencies and associated risk
• Maturity of the response program
• Ability to patch
• Threat intelligence
• Additional business context

This is where your highly educated and connected analysts come in, because 90% of the investigation will happen automatically based on the parameters you’ve set up in your scanners. The other 10% is your analyst understanding your environment, the business needs, the potential impact and pulling vulnerabilities out of the automated process for further analysis and discussion. As a result, an analyst may end up changing a criticality from medium to critical or vice versa.

Look for tools or features within your existing tools that can aggregate all this data — your threat intelligence, your asset criticality ratings, etc. — and push out prioritizations in a clean, easy-to-use format.

Misconception 6: Automating vulnerability management is too risky.

Even with good prioritization, moving the needle with vulnerability management will be impossible without automation. Automation frees up your analysts to perform more complex analysis and partner with stakeholders to make sure the important things are getting done. So, what do you automate?

Vulnerability scans. Stop running ad hoc scans. Setting up a 24/7 scan for your external perimeter has minimal impact and will give you constant, up-to-date information. Your internal environment should be scanned no less than once a week. And have systems in place to alert you if any of these scans are failing in some way. 

Patch tickets. Define your organization’s thresholds for risk and automate ticket creation for any vulnerabilities that meet the threshold. When defining your thresholds, consider:

• Criticality rating – Do you only care about criticals? Criticals and highs?
• Business priorities – What is most important right now?
• Level of maturity and capability – How equipped are you to analyze, remediate and respond?
• Active exploits – Do you only want tickets for vulnerabilities with active exploits?

Every scanning tool out there can integrate with a ticketing system and assign tickets based on these criteria. So, for example, if a vulnerability comes in that has 1) a critical rating, 2) an available exploit, and 3) an available patch, then automate the ticket.

Patches. A lot of patching work falls under the 80/20 rule. 80% of patching is relatively low impact. If it’s something you’re doing over and over, and all the boxes are checked, then there’s no reason not to automate. The 20% is what you have to watch out for. A blind .net patch? No, that shouldn’t be automated. But your standard low Patch Tuesday patches? Absolutely. The key is to push these patches in a dev environment first. Use an automated patching tool that takes reliability into account. If nothing breaks, push it to production.

One final note on automation — you do not have to automate everything beginning to end. You can automate what you feel comfortable with. At a minimum, automate your vulnerability scans. Then take it step by step. If there’s a patch, you’re not confident in, have an analyst re-assess the criticality, and then automate a ticket to investigate further.

Building a Risk-Based Vulnerability Management Program

In this post, we’ve shared strategies for navigating some of the common blockers that put vulnerability management teams in a reactive position. Each of these strategies makes up a pillar of a risk-based vulnerability management program.

Ultimately, the goal of your vulnerability management program is to prioritize and remediate vulnerabilities within defined SLAs. Everyone — business units, IT, GRC, VM — must be aligned to this goal. It’s up to your vulnerability management team to build those bridges and ensure cross-functional communication is happening. It cannot be overstated — without this communication, your vulnerability management program will fail.

Get in Touch

If you’re ready to build a risk-based vulnerability management program, our advisory team can help you assess your current capabilities and develop identification, remediation, and communication strategies to help your organization achieve their risk reduction goals.

Get in touch with our team here.