Patch/Configuration Management, Vulnerability Management

Set up a solid patching program, or face the consequences

Microsoft recently released what many hope will be the final patch for the PrintNightmare vulnerabilities, but today’s columnist, Jane Adams, points out that some organizations may not have the staff or can’t afford the downtime to patch. Still, as a general rule, Adams says companies should develop a solid patching program. (Stephen Brashear/Getty...

I was tempted to call this article about patching: “Threat actors hate this one easy trick.” Unfortunately, it’s only half true. Patching isn’t easy.

A solid patching program also stands as one of the most important moves an organization can make to protect itself.

I am not trying for a nuanced message here. We know that. It’s also one that can attract the criticism that companies like ours maybe don’t understand the hard time more mainstream companies have putting a patching program together.  

As threat intelligence vendors, we see threat actors exploiting vulnerabilities all the time. Some of those vulnerabilities are brand new, some years old. Most have patches available. The consequences of successful exploitation are often catastrophic: Mass data theft, cyber-espionage, and ransomware. Successful ransomware attacks can cripple organizations.

We know that “patch all the things” is demonstrably hard to do. Otherwise, organizations would just do it. Here are some reasons why organizations don’t “just patch” – and some of their consequences.

  • Patches are discontinued.

A system may have reached end-of-life and no longer receives patches. In late September 2021, an attacker exploited an 11-year-old vulnerability in a system that had reached end-of-life in 2016 to drop Cring ransomware. Of course, that doesn’t explain why the victim didn’t apply the patch in 2010 when it was released. In another example, many small online stores still use Magento version 1 as their e-commerce platform when Magento now runs on version 2.4. Magento 1 stopped receiving support (and patches) in June 2020. The consequences are that users are no longer PCI-DSS compliant, opening them up to hefty fines and higher transaction fees. They are also prime targets for Magecart skimming attacks.

  • The patches may only target specific releases of an application.

A patch may address a specific release of a software package and not the one the organization uses. If the software itself isn’t up to date, it may have to get updated before the security team applies a patch. That may not be feasible or affordable.  However, occasionally, vendors are forced to release security updates for unsupported product versions. For example Microsoft retro-patched unsupported Exchange Server versions against ProxyLogon vulnerabilities in March.

  • Production facilities can’t afford the downtime to patch.

Security teams may also find it unclear whether patches are fully effective or the effect of deploying the patch in a production environment. There undoubtedly has been uncertainty about some of the patches released for the PrintNightmare vulnerabilities after proof-of-concept exploit code was published in June 2021. Ransomware groups like Magniber and Vice Society have taken advantage of unpatched PrintNightmare vulnerabilities. Many companies can’t afford the system downtime required to patch, particularly in industrial control systems, where availability requirements can outweigh security considerations. Organizations may not know the extent of their IT estate. Devices are often not accessible.

  • Organizations may not have the resources available.

Some organizations may question the cost-effectiveness of allocating those resources. Patch management can impose a considerable burden on organizations, financially and otherwise. Every month, as many as 2,000 new vulnerabilities are notified to the National Vulnerability Database. Most are addressed by security updates. Of course, every vulnerability does not affect the average organization every month, but with major vendors often each releasing more than 100 patches a month, it’s clearly an undeniable drain on resources.

Those are just some of the reasons why an organization might decide not to patch against a particular vulnerability. We understand that it isn’t easy. Nonetheless, every decision not to patch has consequences. The big question: Can the company accept the consequences.

Ultimately, organizations have three options to choose from. They can treat the risk, they can transfer the risk, or they can tolerate the risk. Treating means patching or other compensatory controls. But with so many patches being issued, how do organizations know where to start?

To make patching more manageable, organizations should prioritize vulnerabilities. This requires a risk-based approach, evaluating both the likelihood of exploitation and the consequences within the organization’s own particular business context. A vulnerability might be highly exploitable, but if it’s on an asset deep inside the network, or isolated, or otherwise inaccessible, the risk may be acceptable. Alternatively, with and old and obscure vulnerability, if it’s on an internet-facing system, the company could face severe consequences.

On the other hand, many vendors publish workarounds when they release a patch. Organizations can reduce their attack surface by system minimization and hardening. They can also transfer the risk by switching their systems to cloud-based infrastructure-as-a-service.

In contrast, tolerating the risk means not patching, hoping for the best, and accepting the consequences. Ultimately, it’s up to each organization to make that call. But we will unapologetically continue to advise patching, because from where we sit, it’s a when not if situation. Given the consequences, it would be a disservice to our customers if we recommended anything else.

Jane Adams, information security research consultant, Secureworks 

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.