4 Steps to Building a Vulnerability Management Program

Day after day we hear stories of companies being breached because of vulnerabilities in their systems. While some of these vulnerabilities may be new, the majority of breaches are caused by vulnerabilities that have had a patch available for weeks, months, even years but are left unpatched. If you know that there are vulnerabilities on your network, why wouldn’t you patch them immediately? Simply put, there are too many vulnerabilities and not enough time. So the question becomes not “how can I patch all of my vulnerabilities” but “how can I know which vulnerabilities to patch first?”

This is why you need a vulnerability management program.

A good vulnerability management program will help you not only identify but prioritize your vulnerabilities based on historical data and likely threat scenarios. While instituting a program of this size can seem daunting, I’ve broken it down for you in just four steps:

Step 1: Consolidate and Prioritize Vulnerabilities

Do you have a scanner? Ok, that’s a silly question. I guess I should ask how many scanners you have. Just one scanner can produce thousands of vulnerabilities in your network both on software and firmware and most organizations have more than one which results in the infamous 300-page document to sift through. 

For example, did you know that there are over 93,000 known, high-risk vulnerabilities in the world based on a list by the National Vulnerability Database (NVB)? With 250 working days in the year, your team would have to fix 372 vulnerabilities a day or 1,860 a week. If you’re like most teams, that wouldn’t even be possible if your entire team dedicated itself to only fixing vulnerabilities which you can’t do because there is too much else to do.

We are overwhelmed by data and bad actors are taking advantage of our limitations.

When looking at a vulnerability management program, your first step should be to take all of the vulnerabilities in your network and be able to consolidate and prioritize them. As I said before, there are 93,000 known, high-risk vulnerabilities. How many of these are in your network? Wouldn’t you think that these needed to be fixed before lower level ones?

With vulnerability management, you will have a single occurrence with fast data imports from your scanner(s) and the ability to analyze and prioritize your vulnerabilities based on your organization’s unique needs. 

Step 2: Model Threat Scenarios Using Configurable Risk Criteria

Knowing what vulnerabilities lie on your network and how much of a risk they pose based on historic data is a great start to your program. However, what if you could go one level deeper and find out how those vulnerabilities would impact your organization? For example, a vulnerability that may risk high on paper but can only access one application would not be as risky as a vulnerability that is rated as a medium risk but that opens the door for attackers to pivot throughout your network gaining access to consumer credit card data.

By modeling threat scenarios, not just relying on the NVB risk level, you can demonstrate how attackers can chain vulnerabilities across vectors to move through your environment and consider all possible exploits, including “in-the-wild,” private, theoretical, wormified, virus, and malware. Take your prioritization a step further here and it can save you from a catastrophic breach later on.

Step 3: Identify and Eliminate Attack Paths to Critical Assets 

While this step sounds very technical it all boils down to two things, patch and pen-test.

Once you have your list of prioritized vulnerabilities you can look for patches and start applying them, in order of importance, to your software and firmware. By following through with step 2, you may be able to implement patches for several links of the attack path that you wouldn’t have known about before. By both identifying and eliminating the attack paths to your critical assets, you will add an extra layer of security to your weakest points.

So now we have scanned, prioritized, researched, reprioritized, and patched our vulnerabilities. While that seems like a done deal, do you really want to put that much work into something without verifying that it works? Of course not!

Now is the time to run a penetration test on your network, specifically trying to exploit the recently patched vulnerabilities, in order to make sure that your hard work paid off.

Step 4: Leverage Flexible Reporting Options

I like to call this step the “shampoo step” because this is the time you rinse and repeat. Like we said earlier, there are most likely thousands, if not hundreds of thousands, of vulnerabilities in your network. While patching the highest risk vulnerabilities are a great start, you’re not finished. You may never be finished. However, at least you can justify your resources and plan of attack.

Another way to justify your program? Reporting.

Let’s be honest, we all report to someone, and in order to continue funding for your program, you need to be able to produce results. Make sure your solution can customize your reports with templates and share granular filtering, grouping, and configuration of large amounts of data that measure the effectiveness of remediation efforts, compare, and track results over time.

There you have it! Four, pretty simple, steps to building your vulnerability management program. However, in case these aren’t enough, we have more! 

Learn more about Vulnerability Management Programs