Common Vulnerability Management Mistakes

So you’ve finally done it.

You’ve been thinking about it for a while, and now you’ve taken the plunge.

Your organization finally has a vulnerability management process.

Feels good, doesn’t it?

No more nagging doubts about possible vulnerabilities: You’ve seen the scan results, and your remediation plan is in full swing.

But before you pat yourself on the back, you’d do well to consider some of the big mistakes organizations make when they first approach vulnerability management.

It’ll be much easier to correct your course now than it will be if these mistakes are identified a year down the line.

1) You’re Reacting to the Latest Headlines

Many organizations set out with the best of intentions but get waylaid by the ‘latest and greatest’ vulnerabilities.

Heartbleed. Poodle. Shellshock.

These ‘headliners’ might seem like your biggest concern, but ultimately you’re far more likely to be breached as a result of unpatched software or an outdated operating system.

To put this in perspective, think about human illnesses.

Swine flu and Ebola might seem like a huge issue, but you’re still far more likely to come down with a common cold.

Ultimately, by over-focusing on these headline vulnerabilities and committing too many resources to resolving them, you’ll leave your organization severely vulnerable to much more commonly abused threats.

Avoid this by: Sticking to your process.

Run your vulnerability scans on a regular schedule, and remediate those vulnerabilities that pose the greatest risk to your organization first.

By doing this, you’ll remediate far more vulnerabilities (and in a more sensible order) than you will by focusing on specific, high profile cases.

The result: Reduced business risk.

And isn’t that what you’re really looking for?

2) You’re Dependent on Old Technology

This is a serious issue, and one that can completely derail your vulnerability management process.

If you have bespoke systems (usually proprietary ones) that rely on old versions of common software, you’ll be tempted to avoid updating or patching that software. This can lead to serious vulnerabilities remaining open for long periods of time and dramatically increased levels of business risk.

I understand the mentality here.

Updating bespoke systems is time consuming and often costly.

Not only that, in many cases organizations simply don’t have a detailed understanding of what dependencies they actually have.

It’s important to realize that ultimately, no matter what the cost, you’re going to need to update or patch the software your systems are dependent on. It can only be put off for so long before the level of business risk posed is no longer acceptable.

Avoid this by: Tracking your dependencies.

When you created your asset register (you do have one, right?) you probably kept the detail to a minimum.

In many ways that’s understandable. Some information is absolutely necessary to the vulnerability management process, and some is simply ‘nice to have’. What we’d recommend is that instead of setting for the bare minimum, you go a bit deeper and include the dependencies for each asset.

This is probably not going to be a quick solution.

You will, for instance, probably find dependencies you weren’t aware of and others that make you realize just how fragile some of your systems really are.

And that’s precisely the point.

If you know in advance that certain systems are heavily dependent on the specific environment they currently sit inside, you’ll have the opportunity to invest in further development ahead of time.

As a result, when a vulnerability turns up in that environment, you won’t have to put off remediating it while you frantically redevelop a critical system.

3) You Treat Vulnerability Management as a Numbers Game

When you’re routinely reporting on your vulnerability management efforts, it’s easy to get sucked into playing the numbers game.

This month we remediated 10% more vulnerabilities than last month, go us!

Clearly this sort of thinking is better than nothing, but it’s really not a sensible approach. If you’ve remediated 99.9% of detected vulnerabilities but missed the one most likely to be exploited, you haven’t spent your time and resources effectively.

And again, I understand why this happens.

Executive teams all over the world have suddenly started taking an interest in security, and there’s a good chance you’ve been asked to provide regular vulnerability management reports. It’s natural to want to ensure your hard work is being recognized, and higher numbers help to achieve that.

Ultimately, though, this is harmful to your organization and will lead to increased business risk.

Avoid this by: Remediating based on business risk and producing qualitative reports.

OK, the first part makes sense.

We’ve talked over and over in this series about ranking vulnerabilities in terms of business risk, and hopefully you’ve got the message.

Working in risk order may mean fewer remediated vulnerabilities overall, but it definitely means less residual risk.

But how do you ensure your hard work is recognized and the board understands why the numbers don’t always go up?

That’s where qualitative reporting comes in.

Rather than simply adding stats to a template, try to provide some context. Board members are typically smart people (if a little technically challenged), and it isn’t that hard to explain things in a way that non-techies can understand.

At the start of each report, include a short paragraph outlining your prioritization process.

By all means include some stats, but highlight the top two or three most important vulnerabilities addressed in this cycle, and explain why they were prioritized.

If your board understands the need for (and process of) remediating vulnerabilities, they’re far less likely to focus on the bare numbers, and that’s good news for everyone.

4) Nobody is Taking Responsibility

In a recent article we covered the basic roles required for effective vulnerability management.

We also explained why it’s important for specific staff to take ultimate responsibility for the completion of certain tasks.

The thing is, many organizations completely ignore this advice. And that’s a problem, because without firm responsibilities the whole vulnerability management process will start to slip.

When serious vulnerabilities have been identified, you don’t want remediation duties to be passed around because “I don’t have time this week” or “that’s not my job”.

Avoid this by: Having a clearly delineated set of responsibilities.

OK, so in large organizations there are going to be multiple people involved in certain stages of the process. One person simply cannot remediate hundreds of vulnerabilities on their own.

And in small organizations, as a result of resource issues, individuals may take on more than one role.

Either way, ultimate responsibility for each stage of the process must fall to an individual. Not a department, not a team, not even two halves of a job-share.

One person.

And this person must have the authority to ensure their part of the process is completed in a timely manner, whether or not they do it personally.

In this way, your vulnerability management process can run smoothly and effectively, even when difficulties arise.

5) You Aren’t Committing Enough Resources

Yes, there are tools out there that will help to simplify and automate the vulnerability management process.

No, that isn’t an excuse to under-commit on resources.

In the vast majority of cases, vulnerability management processes are not something that can simply be ‘tacked on’ to an existing employee’s responsibilities. You can’t simply identify a few security professionals within your organization and assign them ownership of the whole process.

We’re talking about a complex, constantly evolving, business critical process, so let’s start treating it like one.

Avoid this by: Properly scoping your vulnerability management process in advance and recruiting additional staff where necessary.

It’s fashionable, especially since the most recent recession, to expect more for less: More output, less cost.

But that’s simply not going to cut it, especially when the cost of under-resourcing could be a hugely expensive (not to mention embarrassing) breach.

If you want to do vulnerability management right, you must be willing to commit the necessary resources. That means carefully designing your process, identifying the major players and ensuring each aspect of the process can be properly resourced.

Think of it as a spend-to-save initiative, and you won’t go too far wrong.

It’s All in the Plan

In the end, avoiding these vulnerability management mistakes comes down to planning.

If your process is well planned, well resourced, and well documented, you’ll find problems are kept to a minimum. Sure, things will go wrong now and again, but you’ll be in a very strong position to deal with them.

If, as things stand, one or more of these elements is missing from your process, we’d strongly recommend you go back and deal with that.

In the long run, it’s much easier to fix your process now than it will be to continually fight the fires caused by lack of planning, resources, or documentation.

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 3: How to Approach Vulnerability Management: The View from 10,000 Feet

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