A SANS Whitepaper Why Your Vulnerability Management Strategy Is Not Working—and What to Do About It Written by Jake Williams Sponsored by: April 2019 LookingGlass Cyber Solutions Introduction Vulnerability management is a critical component of a holistic information security program, but it has become so commonplace that most organizations barely pay attention to it anymore. Yet unpatched vulnerabilities continue to plague organizations. Every year, the headlines are full of breach examples that resulted from unpatched systems. Much of the problem involves the maturity of vulnerability management programs. It’s 2019, and yet organizations are still trying to apply 2005’s state-of-the-art technology to their cybersecurity programs. The state of attacks is changing, and vulnerability management must change with it. While many organizations understand that annual scans aren’t enough, they still struggle with prioritizing resources to address vulnerabilities. If there’s one takeaway from this paper, it’s that “scanning and patching” isn’t the same as “robust vulnerability management.” The state of attacks is changing, and vulnerability management In this paper, we look at why vulnerability management solutions have not met expectations and how IT and security teams can better implement those must change with it. solutions to maximize value. We then discuss how to deal with the resourcing constraints that all vulnerability management programs encounter. Lastly, we discuss how cyber threat intelligence enables teams to make data-driven decisions about prioritizing limited resources. ©2019 SANS™ Institute The State of Vulnerability Management A few short years ago, just running a vulnerability scanner that touched every machine and produced a thousand-page report was considered state of the art. While the vulnerability scan report enabled IT and security teams to identify (and hopefully correct) missing patches and insecure configurations, the same teams quickly discovered they were drowning in data. Often, the reports were simply too large to be actionable. Teams didn’t know where to start and frequently found themselves dedicating their limited resources to less important vulnerabilities—instead of the most critical vulnerabilities. In 2017, WannaCry1 and NotPetya2 wreaked havoc on some of the biggest organizations in the world. Both attacks were fueled by the leaked exploit EternalBlue3—a vulnerability for which patches had been available for months. And yet both events made front-page news, even outside the cyber industry. That NotPetya was still able to exploit targets using EternalBlue more than a month after WannaCry highlights the challenges inherent in vulnerability management. Patching, even for critical vulnerabilities known to be exploited in the wild, remains a significant issue in many enterprises. Then came the Equifax breach.4 Equifax suffered a highly publicized breach when attackers compromised a Struts vulnerability on a public-facing web server—a vulnerability that had been identified years earlier. How did Equifax miss patching this important vulnerability? In its own reports to the government, Equifax made it clear there were many independent issues with their vulnerability management program. Nevertheless, a vulnerability known to be exploited in the wild went unpatched on a critical server. Nobody accepted the risk of not patching the vulnerability—the state of the vulnerability management program saw to that. Obviously, running a vulnerability management program is hard, even for an organization with the resources of Equifax. Some teams try to act on data by sorting vulnerabilities identified by the scanner ratings of high, medium, low and informational. But oftentimes this method still leaves them wanting more. A medium vulnerability on a system that processes protected health information (PHI) is probably more important than a critical vulnerability on a system responsible for printing shipping labels. Most vulnerability scanners, and in some cases even the people overseeing the scans, lack context about the business roles and particulars of the systems they are scanning, so effective prioritization remains difficult. Today, it’s clear that vulnerability scan reports alone aren’t enough. Security teams need more context to act on this data appropriately. Key performance indicators (KPIs) such as “the percentage of critical vulnerabilities patched within 60 days,” while relatively easy to quantify, say little about the security of the organization. Senior management 1 WannaCry ransomware attack, https://en.wikipedia.org/wiki/WannaCry_ransomware_attack 2 “The Untold Story of NotPetya, the Most Devastating Cyberattack in History,” www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world 3 EternalBlue, https://en.wikipedia.org/wiki/EternalBlue 4 “Equifax Officially Has No Excuse,” www.wired.com/story/equifax-breach-no-excuse Why Your Vulnerability Management Strategy Is Not Working—and What to Do About It 2 is also waking up to these inappropriate metrics. In breach after breach, vulnerability management teams have reported compliance with all program goals. Unfortunately, vulnerability management can’t be both working and not working at the same time. This is a classic case of “what gets measured gets managed,” but if you’re measuring the wrong things, you can be compliant without actually addressing the underlying problem the program was intended to solve. Organizations need to find KPIs that actually align to organizational risk. One example of such a KPI might be the mean time to patch a vulnerability being actively exploited by an adversary known to target the organization or ones like it. The scan data presented today leaves organizations ill-equipped to even understand their vulnerability landscape. It is extremely difficult for an organization to just “patch everything”—but should that even be the goal? Vulnerability Management Program Goals When discussing vulnerability management programs, it helps to consider the goal of any such program. All too often, organizations say that the goal of their program is to ensure that patches are applied. But that’s not really accurate. The real goal of any vulnerability management program should be to minimize risks to the organization introduced by vulnerabilities. While applying patches is one component of any such program, the patching activity is simply a means to the end of minimizing risk. It is through this understanding of vulnerability management programs that the rest of the paper is framed. We discuss patching, but we must acknowledge that many organizations simply lack the capability to apply all applicable patches in a timely manner (whatever that means for the organization). Instead, this paper discusses vulnerability management as a holistic program designed to reduce overall risk. Default Scanner Priorities Aren’t Enough Most vulnerability scanners simply report the priority of vulnerabilities INFORMATIONAL on a scale of ratings including informational, low, medium, high and critical (see Figure 1). LOW Organizations are largely left to prioritize their patching according MEDIUM to these seemingly arbitrary ratings. Unfortunately, these ratings are not appropriate for all (or even most) HIGH organizations. The default ratings that vulnerability scanners assign assume no compensating controls CRITICAL and are not informed by context. Figure 1. Vageries of Risks at Each Vulnerability State Why Your Vulnerability Management Strategy Is Not Working—and What to Do About It 3 Remember, the goal of a vulnerability management program is not to patch vulnerabilities (though that is an important component of any program). Because the vulnerability scanner does not contextualize the criticality of the asset or the data potentially at risk, the threat model of the organization or compensating controls, these ratings are often woefully inaccurate at predicting actual risk. Chained vulnerabilities are another potential issue. The default ratings The default ratings that vulnerability that vulnerability scanners assign consider each vulnerability in scanners assign consider each isolation. But attackers don’t target assets this way. They will use any vulnerability in isolation. But combination of vulnerabilities present to accomplish their attack. attackers don’t target assets this way. Consider an asset that has multiple low vulnerabilities: one that allows directory traversal on a trivial file transfer protocol (TFTP) server and another that allows an attacker to list filesystem contents remotely. Each of these considered independently is probably a low vulnerability. In order to request a file through TFTP, the attacker must know a valid filename. Listing filesystem contents by itself will not lead to successful exploitation either. However, if the attacker can use the filesystem vulnerability to enumerate filenames and then use the TFTP vulnerability to obtain their contents, this combination of vulnerabilities could result in total system compromise. But what if the system in the previous example also has an unpatched Two low vulnerabilities combined critical vulnerability? In most vulnerability management programs, the may represent a greater risk to the critical vulnerability would be assigned a higher priority for patching. organization than a single critical What if the critical vulnerability requires authenticated access to the vulnerability. system to be exploited? Or what if the configuration of the system prevents reliable