Creating a Vulnerability Management Program – Patching: Take the Panic out of Patching by Managing CVE Threat Overload

Imagine a company that started in early 2012 with a half dozen employees — all working in one office — and conducting a portion of its business online. Focused on making a profit, the leadership doesn’t worry excessively about cybersecurity or vulnerability prioritization. One of the employees is assigned to install patches for the limited number of applications that require them. And while cybercrime is ramping up, the number of common vulnerabilities and exposures identified each year has been declining — from 6,610 in 2006 to 4,155 in 2011.

Fast-forward 10 years: The company has grown rapidly, with 2,500 employees in the U.S., an additional 1,000 contractors in various parts of the world and three divisions. Covid has forced most of them to work remotely. And those CVEs that seemed so manageable when the company started have multiplied nearly five-fold, reaching 20,149 in 2021. Instead of one person handling patches, there are now five of them – and they’re pulling their hair out.

“We try to stay on top of the patches, but honestly, we can’t keep up,” the CISO complains. “And every time some celebrity vulnerability makes the news, our board freaks out, so we spend weeks just trying to feel we’re on top of it. And truthfully, I’m not sure we are.”

The recent Costs and Consequences of Gaps in Vulnerability Response Report from Ponemon Institute and ServiceNow revealed that almost half of respondents had their organizations experience one or more data breaches over the past two years — and 60% of those say the breaches could have been prevented by applying available patches.

Understand Patch Management for CVE Threats

Patch Management is the system you use to ensure your networks and the devices connecting to your networks are, and remain, secure by keeping them up to date. While many teams choose to automate this process, patching is not a “set it and forget it” operation. Untested patches run the risk of breaking functions within your current systems and causing business disruption. On the other hand, not patching leaves you exposed to outside actors looking for vulnerabilities. 

Patching serves a number of purposes: 

1. Fixing bugs in the software.
2. Releasing new features.
3. Remediating vulnerabilities in the software.

As such, Patch Management is an integral part of your Vulnerability Management program. How you deploy those patches depends on what type of system you’re patching. How you patch standalone devices will differ from how you patch systems on your network. Add into that the increase in remote work, Vulnerability Management teams now face the challenge of managing patches on a wider range of endpoints. All this to say, teams can easily struggle with patch overload.

How you approach your Patch Management is a strong indicator of how mature your Vulnerability Management — and cybersecurity posture — is as a whole.

The Stages of Cybersecurity Maturity Based on Your Patch Management Approach

If that CISO’s complaint sounds at all like the status of your organization, you’re not alone. Companies of any size and scale have struggled to keep up with cybersecurity threats of all kinds, not just CVEs. Some companies have seen their business side grow far faster than their security departments because their upper management and Boards of Directors didn’t take cybercrime seriously enough. Other organizations provided hefty budgets for cybersecurity tools, but they failed to develop systematic processes for using them.

A brief word of encouragement: there are effective ways to handle patch overload, and we’ll describe them at this article’s conclusion.

IBM has classified five stages of IT maturity, each of which can be thought of as having a corresponding patching approach. The patching responses were described in a recent blog by JetPatch and are consolidated here. 

1. Initial: No standards are in place and inconsistency exists across the organization.
   Patching approach: Low priority by upper management. Not seen as driving business value, but rather interfering with business activities.
2. Managed: A process is in place and activities are managed, but the process is orchestration without insights.
   Patching approach: Seen as necessary, but still a siloed activity with poor communication between departments.
3. Defined: A process is defined as a standard across the organization and is tailored for individual projects.
   Patching approach: Communication between departments is now occurring and patching is a regular activity, but the company still lacks automation and threat intelligence.
4. Quantitatively Managed: The process is measured and any deviation from the standard is addressed.
   Patching approach: Tools are now being used to handle patching as well as other cybersecurity needs, but organization falls short in determining the ROI on those tools or fully anticipating and guarding against future threats.
5. Optimizing: The process is continuously improved.
   Patching approach: With the processes defined, siloes knocked down, appropriate tools in place, and buy-in across the company, the security team can respond quickly and effectively when patching or other measures are required.

 Where does your organization reside on the maturity ladder at the moment? If it’s at the very top, congratulations – you need not read any further. But the odds are overwhelming that your company is at a lower level of maturity; the vast majority of businesses are. It takes time, effort, and a wholesale change in attitude throughout a company to move up the ranks. Given that, how should you approach patching in the meantime?

NIST’s Latest Patching Management Guide

 In November 2021, NIST published the fourth revision of its “Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology.” The 27-page guide is well worth the time of everyone with cybersecurity patching responsibilities, and we cannot adequately detail all of its points here. The report details the phases of what NIST calls a “software vulnerability management life cycle.” That cycle consists of:

 1)    Knowing when new software vulnerabilities affect your organization’s assets
2)    Planning the risk response
3)    Executing the risk response, including:

•     Preparing it
•     Implementing it
•     Verifying it
•     Continuously monitoring it

 All those phases cover the broad outlines of what it takes to properly deploy a patch, with subsequent descriptions of the patch deployment considerations as well. Suffice to say there’s much to be mindful of.

The Shortcut Guides for Smart Patching

 So, at long last, what’s the trick to patching effectively and efficiently? Simply this: Don’t just jump every time a new CVE is announced, no matter how serious a risk it is described on the Common Vulnerability Scoring System. A study by the data-science group Cyentia Institute showed that patching based on the CVSS score only improved an organization’s patching effectiveness by two- to six-times more than a random patching strategy. 

 For significant gains on the order of 22 to 29 times more effective, a company should patch based on the existence of exploit codes associated with the vulnerability. In other words, concentrate more on known dangers rather than potential dangers. Cyentia recommends combining the CVSS information with the number of Twitter mentions regarding an exploit code. Also recommended is focusing on the vulnerabilities that are most observed in a particular environment.

 Another shortcut guide was provided by Roger Grimes of the cybersecurity training firm KnowBe4 in a LinkedIn article he titled “Patch Like a CISA Pro!”. Grimes, too, focuses on vulnerabilities with known exploits but he refines it further, taking into account information available from the U.S. Cybersecurity & Infrastructure Security Agency. He ranks patching as follows:

 1)    Patch ASAP: Known exploited vulnerabilities as on the CISA catalog list

2)    Patch fairly quickly: Publicly available exploit codes that involve popular remotely exploitable services and products

3)    Prepare to patch quickly: Exploit codes that are publicly available

4)    Within 1 month: Exploit code not yet publicly available, but vulnerability involves popularly exploited apps or services

5)    Patch when you can: Everything else

But the Maturity Levels Still Matter

Sounds a lot more manageable and logical than running helter-skelter after every new vulnerability and patch, doesn’t it? Of course, there are several assumptions that need to be made before these shortcuts can be successfully implemented. 

You can’t do so effectively if your organization is siloed and not communicating with one another. Nor can you jump and respond to the biggest threats if others in your organization see patching as interfering with business functions. And even if you have cooperation, you won’t necessarily be able to implement the patches effectively if you’re not fully aware of all elements in your attack surface. 

But there are steps to take, methods to embrace and tools that can assist. We’re here to help you understand all of them and how NopSec can be part of the answer to your cybersecurity needs. Contact us for a demo. 

FAQs

Question: What is the difference between Vulnerability and Patch Management?

Answer: Vulnerability management is identifying and properly responding to vulnerabilities in an organization’s internal structure and involves the internal policies, measures, safeguards and vulnerability remediation efforts needed to prevent threat actors from exploiting those identified weaknesses in a company’s infrastructure. Patch management is determining the vulnerabilities that need to be patched, when those patches should be installed, and how to install them without disrupting other functionalities or operations. 

Question: Is Patch Management part of Vulnerability Management?

Answer: Patch management is an integral part of vulnerability management.

Question: How do you implement a Patch Management process?

Answer: Patch management must be driven by the risks that the organization faces if the patch is not applied. Often a patch is not essential because the vulnerability has not been exploited and is not likely to be exploited. Once prioritized, the patching must be done in a thoughtful, deliberate manner.

If you haven’t read the previous installments of this series you can do so here:

• Why You Need a Vulnerability Management Program – Starting Now
• What is Vulnerability Management and the VM Lifecycle Stages?
• Creating a Vulnerability Management Program – The People, Process, and Technology
• Creating a Vulnerability Management Program – Discovering Your Vulnerabilities: The First Foray

Next: Creating a Vulnerability Management Program – Vulnerability Scanners: How They Help Cybersecurity Readiness