So you know what vulnerability management is all about.
You’ve had the introduction and seen the research. You know what (and who) should be involved.
Now you’re ready to get started.
Well lucky for you, we’ve put together this ten-point checklist detailing exactly what you need to tick off if you want to get (and stay) ahead of your vulnerabilities.
1) Know Your Assets
I’ve said it before, and I’ll say it again.
Before you can do anything else, you have to know what you’re dealing with. You need a detailed and complete knowledge (most likely in database format) of what assets you have, their configuration details, and who is responsible for them.
If you’re starting from scratch, most good vulnerability scanners do include a discovery function, and that can be extremely useful.
It is, however, nowhere near enough.
Every other step of your vulnerability management process is going to depend on this one, so take it seriously, and give it the time and resource it deserves.
2) Decide Who’s Who
In the last article, we covered the various roles and responsibilities you’ll need to fill in order to build a viable vulnerability management process.
Whether those roles are filled by full-time members of staff or condensed with the help of an information security and compliance tool such as TraceCSO, now is the time to decide who will be doing what.
It is vitally important that everybody involved in your vulnerability management process knows what is expected of them. It’s also vitally important that everybody else knows who to contact about each function.
There’s a temptation to generalize and say ‘the IT department’ is responsible for scanning and remediation.
Without a clear and agreed upon set of responsibilities, vital (but difficult) tasks will be passed around, and your organization will be left vulnerable.
3) Invest in Training
Vulnerability management is complex, and non-technical members of your organization won’t ‘get it’ as easily as you expect.
It should go without saying that the people directly involved with the scanning, evaluation and remediation processes should receive training… but it shouldn’t stop there.
At the very least, your executive team should receive some informational training so they understand the need for vulnerability management. This is not ‘just an IT thing’, and it shouldn’t be treated that way.
Beyond this, you’ll also want to brief your asset owners. Business critical vulnerabilities should not stay open because an asset owner doesn’t want their system to be unavailable for a few hours.
If you invest the time and resources necessary to conduct a proper training program in advance, you’ll find life much easier in the long run.
4) Install and Configure a Vulnerability Scanner
I’m not going to dwell on this because it’s easily the most well-known element of vulnerability management.
What I will say is it’s not a decision to be taken lightly.
There are all sorts of integration and infrastructure considerations, so make sure the scanner you choose will perform exactly as needed. If you have particularly unusual or unique requirements, you may even need to develop a proprietary system.
Whatever you do, you’ll need to spend some time configuring your scanner to account for your organization’s unique infrastructure. Don’t skimp on this step, as all your remediation efforts will depend on the accurate and timely identification of serious vulnerabilities.
5) Agree (and Stick To) a Scanning Schedule
Now you might think it’s time to start scanning for (and remediating) vulnerabilities, but you’d be wrong.
Before we get to that, you need to set a sensible scanning schedule.
We’ve discussed this before, and it’s important to remember that ‘sensible’ can mean a whole range of things depending on the size of your organization, availability of resources, and so on.
What’s important here is that whatever frequency of scanning you decide on, you stick to it. It’s no good saying ‘we’ll start the next cycle when this one is finished’ because inevitably that results in fewer and fewer scans taking place each year.
My suggestion would be to select a frequency that seems to be well within the scope of your available resources. You can always increase the frequency later, and starting out slowly helps everyone involved get used to their new responsibilities.
6) Determine Business Risk
There’s just one more thing to do before you start scanning.
Go through your list or database of assets, and categorize them based on their criticality to your overall organizational health. You would, for instance, usually conclude that systems containing your financial data are some of the most important.
The purpose of this exercise is to rank groups of assets by importance, so that when your scan results come in you can easily decide which vulnerabilities to address first.
You will want to involve asset owners and potentially even your executive team in this exercise, but don’t forget there are some purely technical considerations. For instance, vulnerabilities in certain assets might be particularly concerning because they would place other assets in harms way.
Systems housing non-personally identifiable information would generally be considered less critical than those holding names and addresses unless that non-personally identifiable information includes login credentials.
Then it’s a whole other ball game.
7) Choose Risk-Based Remediation
Finally. You’ve conducted your first scan.
If this was your first scan ever, you likely have a huge list of vulnerabilities. You’re right to be concerned, but don’t beat yourself up too much.
By getting started with vulnerability management you’ve pulled your collective head firmly out of the sand, which puts you well ahead of a disturbingly large proportion of organizations worldwide.
With that said, you’re no doubt keen to start remediating vulnerabilities as quickly as possible.
Well, this is where you’ll be glad of the work you put in before you started scanning. Since you have a list of assets organized by business risk, you can simply use it to prioritize your remediation efforts.
If you can’t see any way of remediating all your vulnerabilities in this cycle, don’t panic. That almost always happens with the first scan and will happen periodically over the years. Simply get as far down your prioritized list as possible, and then conduct the next scan as planned.
Why not put the next scan off until everything is complete? Because you’re remediating based on business risk, and there’s every chance the next scan will discover a new vulnerability in one of your critical systems.
8) Synchronize Remediation with Scheduled Maintenance
This might seem obvious, but don’t pass it over.
Where possible, it’s always desirable to complete remediation work (if it requires downtime) during your regularly scheduled maintenance periods.
Of course, this isn’t a cut and dried imperative. If serious vulnerabilities are identified that warrant immediate intervention, by all means schedule an emergency maintenance window. It might not be ideal, but it’s a lot better than suffering a costly and embarrassing breach.
On the other hand, if remediation can wait until your next scheduled maintenance window, it’s best not to rock the boat. It’s easy to forget that even short interruptions in service can be extremely inconvenient for colleagues and clients, so try not to be overzealous.
9) Don’t Hoard Information
Of all the maladies that affect IT departments, information hoarding is the most insidious.
It’s easy to assume that nobody is interested in what you’re doing, or they won’t understand, or they don’t need to know… but this is a dangerous way of thinking.
The more you keep important information purely within the teams immediately dealing with it, the worse life will be for you in the long run.
When it comes to vulnerability management, you’ll quickly find your budget is squeezed, asset owners are uncooperative, and complaints roll in every time you schedule emergency maintenance.
It’s as if nobody understands that what you’re doing is for the good of the organization… because they don’t.
If your executive team understands there are serious outstanding vulnerabilities, it’s likely you’ll receive additional resources. If asset owners understand that their system currently poses a significant security risk to the organization, they’ll likely cooperate with your remediation efforts.
If colleagues throughout the organization understand why you’re scheduling emergency maintenance periods… well. You’ll probably receive complaints anyway, but at least you tried, right?
10) Document Everything
I know, I know. Everybody hates documenting processes.
It’s painful, it’s difficult, and it always takes longer than you expect.
The thing is, it really makes a difference in the long run. Colleagues involved with your vulnerability management process will leave, others will join, and various members of the executive team will take an interest at one time or another.
Your vulnerability management should be able to continue unabated throughout these changes, and having a documented process will make that much easier to achieve.
More important still, having a documented series of processes will ensure you don’t need to reinvent the wheel when something unusual comes up.
If it’s happened before, a process will already have been developed and documented. If it hasn’t, now is the time to develop (and document) a new process.
It might seem time-consuming, but in the long run, it’s just the opposite.
Ultimately, despite what you might think after reading this, the vulnerability management process you follow will be unique to your organization. It will most likely follow the format set out here, but there is a lot of wiggle room for customization to suit your specific needs.
So now that we’ve been through the essential elements of vulnerability management, it’s time for you to seriously consider how it might fit into your organizational structure.
It doesn’t have to be pretty and at the start it probably won’t be, but we’re well past the point where vulnerability management should be a no-brainer for every organization.
Check out other posts in this series: