Information Security

Defending the digital infrastructure

Nmedia - Fotolia

The vulnerability management process after Equifax

Cataclysmic security incidents highlight the importance of a vulnerability management program versus a patch management system. Here's how to implement a risk-based approach.

Managing software vulnerabilities is a universal problem.

While unknown flaws in code or system design are part of the vulnerability management process, responsible disclosure policies and bug bounties have greatly reduced the prevalence of zero-day attacks. Unknown security holes that attackers exploit are usually at high-value targets, such as Fortune 500 companies, government agencies and critical infrastructures.

NotPetya, WannaCry, Conficker and other well-publicized attacks took advantage of vulnerabilities that were publicly known and had available software patches. The use of known vulnerabilities is especially troubling for security professionals because these attacks can be prevented.

Companies haven't embraced the ever-changing software environments that have become reality. While technology providers have begun configuring their software to perform automatic checks to identify and install patches, IT departments have gone to great lengths to control software patching and releases and disable these automatic updates.

This need for control over the technology environment creates risk by allowing vulnerable software to continue to operate. The Equifax breach, which compromised the personally identifiable information -- including Social Security numbers -- of 145 million consumers, will become a case study for vulnerability and patch management. There's scrutiny around the timeline of events, and the company's vulnerability management process is being questioned by Congress, banks and shareholders.

Different goals

Many companies view vulnerability management and patch management as the same process. While a patch management system is the most common method to resolve software problems, there are other valid approaches to mitigating the risk of exploitation of a vulnerability.

The difference between vulnerability management and patch management lies in the goals of the two processes. The vulnerability management process is about risk management. Patch management is a software deployment process.

The vulnerability management process is about risk management. Patch management is a software deployment process.

In true vulnerability management, the risk mitigation may be the installation of a patch. A mature vulnerability management process evaluates the risks involved with the software flaw and makes risk-based recommendations relative to the potential impacts of resolving the vulnerability. This process helps companies prioritize known vulnerabilities that are released at the same time to determine which one is a higher business priority.

A patch management system, by comparison, evaluates the impact of applying the patch and the resources necessary without much analysis of compensating controls that could reduce or even eliminate the business risk. If vulnerability management is performed properly, a valid mitigation of the risk may not require the application of a software patch.

Vulnerability Management Process Flow and Patch Management Process Flow

The Equifax attack highlights the importance of vulnerability management versus patch management. The company confirmed that an Apache Struts vulnerability was exploited in the breach. If the attack began after the patch for Apache Struts was available, a vulnerability management program could have tracked the vulnerability, evaluated the business risk and recommended various methods to mitigate it. Using this process, a mitigating control -- such as intrusion prevention, web application firewall or system configuration change -- could have been recommended even if a patch for the software was not available.

Unfortunately, if a zero-day exploit was used before a patch was available, even a mature vulnerability management process could leave the company without the ability to defend itself in a timely manner, showing why a layered approach is still necessary.

Critical updates

Companies struggle with updates to business-critical applications, such as enterprise resource planning and manufacturing planning and control systems; specialized equipment that performs a critical business process, such as industrial control systems and supervisory control and data acquisition systems; and large e-commerce infrastructures. Because these systems are critical to keeping the business operational, downtime equates to millions of dollars in lost productivity.

To add to the complexity, many of these systems are either so critical they are not allowed planned outages or the system manufacturer has made it cost-prohibitive to keep them updated on the latest software releases. Usually, this risk is accepted at lower levels of management without the realization of the true impact to the company. And to compound the risk, business-critical systems use some of the most vulnerable software.

Many companies fail to acknowledge the risk they accept by not properly addressing vulnerabilities caused by unplanned outages and breaches. A mature vulnerability management process evaluates the vulnerability, regardless of the availability of a patch, and recommends the appropriate risk-mitigation technique. Risk-based vulnerability management programs help businesses manage not only the risk that application flaws present, but also the risk of software patches. Risk mitigation strategies may recommend deferring patch installation in favor of implementing a compensating control.

A risk-based vulnerability management approach begins with an inventory of business-critical systems. This inventory does not need to be exhaustive of every system on the network, although that would help tremendously. In many companies, a full inventory of all software is unrealistic. Starting with the most critical systems can protect businesses from catastrophic outages and losses.

Vulnerability review process

Security analysts who conduct vulnerability assessments must have accurate information on defenses, such as intrusion prevention systems, application firewalls, antivirus and other anti-exploit capabilities. These controls are inputs to the vulnerability review process. The analysts ultimately evaluate the impact to the business, determine if any preventive countermeasures are in place and then recommend action to remediate the risk using a patch management system, eliminate it through uninstalling the software or reduce it to an acceptable level through a compensating control.

While this process can seem complicated and overwhelming, it can be distilled into a quick reference chart to allow analysts to determine the threat, impact and, ultimately, risk that a vulnerability presents.

Quick Reference to Measure Impact of Threat

Using a chart similar to the one above, a security analyst starts with the impact of an exploit of the vulnerability across the x-axis. Once that is determined -- usually using a vulnerability score from an open or commercial source -- the analyst evaluates the availability of an exploit for the vulnerability along the y-axis. Finally, an analyst reviews the applicable preventive controls. If one or more controls exist, the analyst determines the reduction across the grid as necessary.

The chart can be modified for commercial vulnerability management products or other frameworks. The National Institute of Standards and Technology publishes a National Vulnerability Database (NVD) to track the severity of identified vulnerabilities over time based on open framework using the Common Vulnerability Scoring System. These metrics can help security analysts quantify the impact of vulnerabilities on their systems and applications, and prioritize remediation activities. The database currently tracks the severity of almost all known vulnerabilities as far back as 2001. According to the NVD, the number of software vulnerabilities identified in 2017 already exceeds 10,000.

VD CVSS Severity Distribution Over Time
NVD Dashboard

Vulnerability management requires a lifecycle approach to ensure risk is appropriately addressed. The rating given on the day a vulnerability is announced may change over time. For example, if exploit code becomes available, or is adopted into an automated exploit framework or malware kit, the measure of threat would increase. It's not sufficient to only review vulnerabilities at a point in time unless patching, uninstalling the software or network isolation solves the problem.

Keeping up with updates to operating systems and software installed on hundreds, or thousands, of company computers is daunting. Commercial software and open source projects all have vulnerabilities that can result in the compromise of the confidentiality, integrity or availability of a computer or data. Large enterprises, small businesses and even employees who bring their own devices must continually address this challenge.

The impact of attacks can be reduced by using vulnerability management to identify the business risk present in the software and systems in use. If an audit is going on and systems can't be updated for compliance reasons, the vulnerability management process may offer alternative solutions. Lack of awareness of the threats and countermeasures to vulnerabilities leaves systems, data and companies at risk. Just ask Equifax.

Article 3 of 5

Next Steps

Get started with vulnerability management products

Patch management tools that fit your business model

Seven steps to evaluate vulnerability management

This was last published in November 2017

Dig Deeper on Risk management

Get More Information Security

Access to all of our back issues View All