Vulnerability management programs are the meat and potatoes of every comprehensive information security program. It’s not optional anymore; in fact many information security compliance, audit and risk management frameworks require organizations to maintain a vulnerability management program.
If you don’t have a formal vulnerability program, or if your program is ad hoc, there’s no time like the present. In fact, SANS Critical Security Controls #4 calls out continuous vulnerability assessment and remediation as an integral part of risk and governance programs.
If you’re still thinking about vulnerability management as a tactical operations tool to use occasionally there are a lot of good reasons to reconsider. It should be one of the cornerstones of your security program.
I’ve put together a series of blog posts designed to answer all the questions you might have about vulnerability management.
What is Vulnerability Management Anyway?
Let’s start by making sure we’re all talking about the same thing. Vulnerability management is a continuous information security risk process that requires management oversight. There are four high level processes that encompass vulnerability management – Discovery, Reporting, Prioritization and Response. Each process and sub processes within it need to be part of a continuous cycle focused on improving security and reducing the risk profile of network assets.
Discovery and Rediscovery
Discovery is the process by which network assets are found, categorized and assessed. Information about assets should be categorized into data classes such as vulnerability, configuration, patch state, compliance state, or just inventory.
The discovery phase should find every computing asset (yes, every single one) on your network and build a database of knowledge other VM processes can use. Since your network is in a constant state of change, the information about your assets needs to be continually refreshed.
Reports, Reports, Reports
Reporting of the data found during discovery generally provides a number of different outcomes appropriate for different audiences. Reports should create a prioritization matrix that feeds into processes. After all, the raw data on every vulnerability on an enterprise isn’t terribly useful.
Ideally, these reports can also be used for tactical operations tasks and, at a higher level, to provide visibility and business-oriented risk metrics to upper management.
Priorities Are (Almost) Everything
Prioritization is a critical risk management process that ranks known risks according to a predefined set of characteristics. For example, prioritization should spark a thought process something like this:
Given the current state of the asset from the discovery process, the value of that specific asset and any known threats, how important is it that we spend resources to remediate or mitigate these risks? Alternately, are the known risks on this specific asset at this time acceptable to our business?
The goal of prioritization is to create a customized list of what to tackle first, second, third and so on. Ideally, this prioritized list of actions is used to feed into ticketing systems for IT ops and/or drive specific tasks for system operators.
Risk response is the second half of the prioritization process. Essentially, risk response is the approach an organization chooses to address the known risks (note: ignoring risk is a not a response).
Addressing risk falls into three categories – remediate, mitigate or accept. Remediation can be thought as the act of correcting a discovered flaw. For example, if vulnerability is caused by a missing patch, one option is to remediate the problem by installing the patch.
On the other hand, mitigation is the act of reducing risk by taking some other action generally outside the immediate realm of the affected system. For example, instead of fixing a discovered web application flaw on your system, you could choose to install a web application firewall. The vulnerability is still there, but with the web application firewall in place the risk is diminished.
Risk acceptance is making a choice to accept the risk without remediation or mitigation. As an example, the security operations team may recommend that lab equipment run antivirus software. However, business stakeholders agree to not use AV software because it would affect engineering test cases. In this case, the business has selected to accept the known risk.
In Scope, Out of Scope
Now that we all agree on what vulnerability management includes, we should also discuss things that it doesn’t include, because it seems like a lot of people are confused about this.
Pen Testing Not Included
Vulnerability management is not a penetration test. Just because a product scans your systems doesn’t mean you have a pen test tool. In fact, the reality is quite the opposite. A vulnerability management scanner is often checking for the presence or absence of a specific condition such as the installation of a specific patch.
A pen test tool, on the other hand, will actually attempt to break into the system using predefined exploits. While both types of tests might ultimately deliver the same recommendation, the methods used to arrive at these conclusions are wildly different.
If you’re looking for a good pen test odds are good that you need more than a tool. A pen test should be exhaustive and include physical testing and in-person interviews as well as many other things.
While many vulnerability management systems work in conjunction with configuration management systems, there is an important distinction between the two. In fact, SANS has a lot to say about this in critical controls #3 and #10.
Vulnerability management may uncover problems related to system configuration and flag them as risks. However, the operations and management of system configurations are distinctively part of the configuration management program.
Your vulnerability management data in is only as good as the last time it was updated. Just like an audit, the data reported is only relevant to the last time an asset was assessed. The key to creating the most relevant data set is to run your vulnerability management program frequently.
For some companies this means daily or weekly. I don’t think you can call your program continuous if you update it once a quarter, and let’s not even talk about annual assessments because we all know the rate of change on networks means annual data is pretty useless eleven months of the year.
The Alpha and the Omega (NOT)
Vulnerability management is only one piece of a security program. It’s not going to solve the entire risk management challenge. Vulnerability management is the foundation of a security program. You have to start with a comprehensive understanding of what’s on your network. If you don’t know it’s there, there’s no way you can protect it. You also have to understand the risks for every asset on your network in order to effectively prioritize and remediate.
In future articles, we will dig deeper into the parameters of a good vulnerability management program including prioritization, coverage and agent vs. agentless.
For a more complete understanding of what a comprehensive risk management program requires, refer to the SANS Critical Security Controls.
Image courtesy of ShutterStock