Understanding Vulnerability Management

The purpose of this article is to help you understand what a consistent, effective vulnerability management process looks like.

There’s just one problem.

It’s nearly impossible to have a consistent, effective vulnerability management process (in all but the smallest organizations) without some form of automation.

In fact, trying to do the job manually would not only be extremely slow and error-prone, it would also be prohibitively expensive. The manpower alone would be well beyond the means of most IT departments.

In order to implement a truly useful process, you’ll need two things: A vulnerability management solution and a quality workflow system.

Stage One: Identify and Track Your Assets

The idea here is to put together a list of every piece of hardware and software attached to your organization’s networks and split them up into categories. You’ll also need some basic information about each asset, as well as who is responsible for maintaining it.

Sounds easy, doesn’t it.

And, of course, if your organization already has a well-maintained configuration management database (CMDB), this step will be quite simple.

But there’s a problem. Many organizations simply don’t have this information easily accessible.

And that’s a problem, because without a categorized list of assets, you’re not going to be able to implement an effective vulnerability management process.

Of course, most vulnerability scanners will begin by conducting a discovery process, and this can be very helpful. Ultimately, however, there is likely to be a significant manual element to this process the first time around, particularly if you’re starting from scratch.

On the plus side, though, this is a highly valuable business exercise even if you have no interest in vulnerability management.

Stage Two: Scan for Known Vulnerabilities

As you might expect, scanning is the heart of vulnerability management.

If you’ve put in the time and effort to implement a high-quality scanner and identify/track your assets, this step should be a breeze. When all else is said and done, the only real consideration is frequency: How many scans should you run each year?

Of course, there’s no set answer.

Some organizations scan annually, some quarterly, and some monthly… and while there are pros and cons to each approach, one thing is clear: from a security standpoint, more is better.

At its root, this is a case of resource vs. security. Would you prefer to spend more on vulnerability management or accept a great level of business risk?

Ultimately your executive team will have to make a decision about this, but here’s one thing to consider. If you conduct just one scan each year, you’re potentially leaving yourself vulnerable to any single exploit for almost an entire year.

What do I mean by that?

Well, let’s imagine that you complete your scan on January 1st and base your remediation actions on that scan. If a serious new vulnerability is discovered on January 2nd, you won’t pick that up until your next scan a year later.

Imagine, alternatively, that you conduct a scan each month. Your organization will now pick that new vulnerability up in under a month.

Now don’t get me wrong, annual scans are a lot better than no scans at all. Don’t forget that most organizations are still vulnerable to decade-old exploit kits, and, of course, an annual scanning process will help you to mitigate that risk.

But even moving from annual to biannual scanning and remediation will dramatically reduce your level of business risk.

So where do you draw the line?

Ultimately this is going to come down to the level of resources your organization is willing to commit. Quarterly scanning/remediation processes have been found to mitigate the majority of business risk and are a staple for many cyber-savvy organizations.

If, however, you have the resource available to complete the process monthly, I’d highly recommend you make use of it.

Stage Three: Prioritize Vulnerabilities by Business Risk

If you read the last article, you may remember that a small number of vulnerabilities account for the overwhelming majority of exploits each year.

Armed with that knowledge, it only makes sense to remediate certain vulnerabilities ahead of others.

It is, for instance, safe to assume that a Microsoft vulnerability is far more likely to be exploited than a similar vulnerability in a little-known specialist software suite.

But, of course, there’s more to it than that.

In addition to prioritizing vulnerabilities by likelihood of exploitation, you’ll also want to consider the importance of the affected asset to your organization. Not all assets are built equal, and it doesn’t take much to realize that fixing a vulnerability in your web or data servers is going to be top of the list.

Most scanners will help you automatically prioritize your vulnerabilities based on pre-set rules, so investing in a quality solution will save you a lot of time here.

Stage Four: Remediate

Remediation really comes down to two things: configuration and patching.

Once vulnerability and configuration issues are identified, and you’ve prioritized them based on business risk, it’s time to identify your action steps. This will mean applying a range of patches and deciding how assets will be reconfigured during this cycle.

But don’t jump the gun. It’s not time to simply implement your action steps and move on.

A big part of patch management and system hardening is testing to ensure your assets will continue to work as intended after the process is completed.

In order for this to happen, you’ll need a testing environment that is functionally identical to your actual environment. Assuming you have that already, simply complete the intended patching and reconfiguration exercise in your testing environment, and complete a set of predetermined tests to ensure everything still works.

Once you’ve identified that everything is working as intended, you can go ahead and remediate the vulnerabilities in your live environment during your next scheduled maintenance.

You should, of course, have the facility to rollback these changes if necessary. You will miss things from time to time, and when that happens you’ll be very glad you have a backup plan.

Stage Five: Rescan

Be honest, you thought you were done.

Or at least, done for this cycle. After all, vulnerability management never really ends, does it?

But there’s one more thing left to do: Rescan your live environment to ensure your patching and reconfiguration efforts achieved the job they were supposed to. Most of the time this will simply confirm what you expected, but there will be times when vulnerabilities persist.

On these occasions, you simply have to come up with an alternative solution.

If the vulnerability poses a significant risk to your organization, you’ll probably want to schedule an additional maintenance period. If it doesn’t, simply add it to your next remediation cycle.

The Devil is in the Detail

Now that you know what vulnerability management should look like, it’s not difficult to see that doing it manually would be prohibitively labor intensive.

Assuming your organization consists of more than five people, the logistics alone would be insane.

By implementing high-quality scanning and workflow systems, you can develop and maintain an efficient, effective, and consistent vulnerability management process with a relatively small team.

Check out other posts in this series:

Post 1: The Minimalist Guide to Vulnerability Management

Post 2: Vulnerability Management Research: How to Invest Your Resources for Maximum Results

Post 4: How to Start Your Vulnerability Management Off With a Bang: Roles and Responsibilities

Post 5: The 10 Step Checklist for Pain-Free Vulnerability Management

Post 6: 5 Common Vulnerability Management Mistakes... and How to Avoid Them