Vulnerability management (VM) programs are the meat and potatoes of every comprehensive information security program. They are 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 vulnerability management tools, or if your VM program is ad hoc, there’s no time like the present. In fact, The Center for Internet Security’s #3 Critical Security Control calls out continuous vulnerability assessment and remediation as an integral part of risk and governance programs. If you’re still thinking about a vulnerability management policy 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.
A Quick Vulnerability Management Definition
Let’s start by making sure we’re all talking about the same thing. The vulnerability management process is a continuous information security risk undertaking that requires management oversight. There are four high-level processes that encompass vulnerability management: discovery, reporting, prioritization and response. In a strong vulnerability management framework, 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.
Vulnerability Management Best Practices
Managing vulnerabilities with 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 vulnerability management 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.
In VM, Priorities Are (Almost) Everything
Prioritization is a critical vulnerability 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 use a vulnerability management tool 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 drive specific tasks for system operators.
Risk Response
Risk response is the second half of the vulnerability 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 of as the act of correcting a discovered flaw. For example, if a 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 the importance of vulnerability management and what it 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 in vulnerability management
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.
Configure this
While many vulnerability management systems work in conjunction with configuration management systems, there is an important distinction between the two. In fact, CIS has a lot to say about this. 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.
Define Continuous VM
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. Find out about more Tripwire’s vulnerability management solutions by downloading this Vulnerability Management Buyer’s Guide today.
