In the security industry, we consistently hear the same mantra: “keep your software patched.” It is absolutely an essential part of securing an enterprise, and it is a clear enough goal, but when you dive deeper, most find it is just not that simple. Caveats, exceptions, and conflicts plague the patching process. Vendor and legacy software dependencies do not get patched. The difficulty of vulnerability management scales with the size and complexity of your environment. What is the best way to navigate these challenges and build an effective program? There is no single, “silver-bullet” answer, but let us go through some talking points on what makes a good vulnerability management program.

One mistake that some make is confusing the terms “patch management” and “vulnerability management”. Many people tend to use these terms interchangeably, and while they are closely related, they are not the same discipline. These terms represent separate processes. The patch management process involves updating software applications and operating systems in a procedural way. This results in indexed information on how many patches and updates are missing on the assets in the environment and where these updates are missing. Patches and updates are not always associated with vulnerabilities, and that is why patch management is only half of the picture.

Vulnerability management, on the other hand, is a process that deals with both the discovery and classification of assets and vulnerabilities throughout the environment, irrespective of any available patches. Vulnerability tools may include remediation recommendations that suggest a patch, but many vulnerabilities may not involve patches at all. Some may require configuration changes or turning certain services off entirely. Nonetheless, these processes do work together and rely on one another, since the vulnerability scanning process provides assurance of the patch management process. The key here is making sure to focus on these differences by ensuring the quality of both processes separately.

So, what should a vulnerability management program consist of? Just conducting vulnerability scans and getting data on the vulnerabilities in your environment is not equivalent to having a vulnerability management program. A scanning tool is essential, but it’s only one piece of the puzzle. To build an effective and comprehensive vulnerability management program, you need:

  • A way to discover and inventory assets on the network
  • Data classification and criticality classification in place for assets
  • A policy or approach in prioritizing vulnerability remediation
  • A vulnerability scanning tool or suite commensurate with the size of your organization
  • A process and workflow to report and remediate discovered vulnerabilities
  • Leadership to carry out and enforce the initiatives in the program

Discovering and inventorying what is in your environment is a crucial first step. The saying goes: “you cannot protect what you do not know about.” This is even more important now since modern networks contain much more than just computers and network equipment. All IoT devices, software, and hardware should be discovered and inventoried. Do you know how many versions of Java or Adobe Reader are installed in your environment? How about any legacy operating systems? Your discovery and inventory process should also be able to actively detect new devices that appear in your environment. This could be through periodic discovery scans or other integrated discovery methods.

Determining the criticality of assets is another critical step in building the program. The idea here is to understand what is most critical in the environment. These could be systems that have the most exposure, contain the most sensitive data, or they could be systems that are just crucial to the business mission. You should understand the risk level of your assets while documenting the system or data owners for those assets along the way. The riskiest assets should be labeled or formally classified as such. Doing this will help prioritize the actions within your program.

Next, you need to define how you will prioritize remediation based on the severity of the vulnerability combined with the criticality of the asset. There is a lot of grey area here, and I think it is the most neglected part of vulnerability management. The wrong way to go about it is to always prioritize your CVSS 10’s and neglect your CVSS 5’s. It’s not that simple. Here are some questions to ask:

  • Is a medium severity vulnerability on a critical asset more important than a critical vulnerability on a non-critical asset?
  • Is there a compliance objective, such as PCI, that dictates the vulnerability must be patched?
  • What is the likelihood of difficulty in exploiting the vulnerability?
  • How quickly should we remediate the different severities on critical and non-critical assets?
  • Can we make exceptions for some vulnerabilities? Who approves them? Do they expire?

Factors like these should be considered and formalized in a vulnerability management policy and/or guidelines document that clearly defines the goals of the program. Context can be everything in many of these scenarios, so there is no clear rule here other than it pays to analyze the situation holistically.

You then want to perform periodic vulnerability scans on your assets, both internal and external, at a frequency defined within your created vulnerability management guidelines. This could be daily, weekly, monthly, or quarterly, depending on your resources and abilities. Performing credentialed scans where possible is key since this will allow the tool to reach inside the asset and look at both configuration settings and software versions.

Once this scanning cadence is possible, then reporting and remediation (patching) workflows can take place. Having a standardized way to report on vulnerabilities and distribute the reports will keep things consistent and all stakeholders informed. Your patch management team and vulnerability management team should work together and keep the process moving while leadership should champion and enforce the process by attempting to reduce the overall risk scores. Having periodic meetings or discussions on what to prioritize based on the guidelines is helpful. Vulnerability remediation items should be assigned to the most appropriate team for remediation and have due dates, a way to notate issues and progress, and a method to communicate when the remediation is complete.

Quarterly and annual reports should be produced and given to executive management that shows remediation and risk reduction progress and also includes descriptions of any accepted risks or outliers that threaten the organization. With a comprehensive vulnerability management program in place, it’s common to see a continual reduction in risk scores and a major reduction in the vulnerabilities throughout the organization.

Originally published here.