Most IT admins will agree that patching systems such as Windows clients and especially Windows servers involve some degree of risk. If you’re not convinced of this, take a look at my earlier article titled Have Microsoft patches reached a painful tipping point? here on our TechGenix site. In that article. I shared some stories that demonstrated that the pain of keeping up with the sheer number Microsoft patches has become unbearable for many admins, and I concluded that something has to change, and soon. Then in a follow-up article titled I described a bunch of mitigating steps we can all take as patch management admins to stave off impending doom. These steps were basically practical tips such as waiting a week before applying any software updates and using several reliable sources to review all the known issues concerning the updates you are going to deploy.
While the steps I outlined can be of practical help for patch management admins, they don’t deal directly with the core issue of risk. What I mean is that each time you apply a newly released update to an operating system or application to address some security or reliability issue with the software, you risk having something unexpected happen. Like breaking the application you’re trying to patch. Or breaking the networking capabilities of your platform. Or breaking a workflow between several applications and services. Or breaking some legacy code or script your business relies upon. Or possibly even ending up with a dreaded blue screen stop error on one or more of your patched systems.
The list of risks you might be exposed to when it comes to patch management is endless. And I don’t say this idly as we all as admins have had major snafus happen to us in the past where something went fubar because of applying a patch a vendor released for some application or operating system. What this means, of course, is that fundamental to the whole process of patch management is the concept of managing risk. But given the wide range of possible negative outcomes that might occur each time you apply a patch released by a vendor — and especially patches released by Microsoft for its Windows operating systems if your applications and services all run and rely upon Windows client and server systems — where should one start when it comes to managing the risks involved in patch management?
Classifying the risks associated with different vulnerabilities
I recently had a discussion about this with Emin Atac, a certified Digital Forensics and Incident Response (DFIR) professional and a Cloud and Datacenter Management (CDM) Microsoft Most Valuable Professional (MVP) award recipient. Emin blogs about his Information Security (InfoSec) and Automation journeys on his WordPress site, and he shares his projects on his GitHub page. In a nutshell, Emin’s approach to this matter is simple and clear: “My strategy has always been a risk-based approach. If there is a vulnerability, something needs to be done about the risk. But the risk needs first to be identified and assessed.” In other words, the key first step in managing risk for patching systems is to identify what kind of vulnerability a patch is designed to fix. Then based on the degree of seriousness of the identified vulnerability, you can then decide upon what level of risk is involved in applying (or not applying) the patch, and also how and when you should apply the patch.
What this boils down to in Emin’s estimation is that there are basically four different ways you can deal with a vulnerability when it has been identified for an operating system or application. First, you can accept the risk as being slight at present and just file the information away for a future time when the vulnerability becomes a zero-day exploit should that ever occur. I asked Emin for an example of this type of vulnerability and he mentioned Matt Nelson’s blog where he described a remote code execution vulnerability he had identified back in February 2018 whereby the Windows Shell didn’t properly validate file paths. This meant that an attacker who managed to successfully exploit the vulnerability could run arbitrary code in the context of the current user. Matt reported the vulnerability to the Microsoft Security Response Center (MSRC) and the end result was that the MSRC released a fix for the issue in August which by then had by then been designated by MITRE as vulnerability CVE-2018-8414. Although Matt had proposed some ways of monitoring one’s exposure to the vulnerability and had also suggested an (untested) workaround for reducing your possible exposure to it, most admins probably dealt with the matter by accepting the risk of doing nothing until a patch was released as being sufficiently small to warrant such a decision.
A second way of handling a newly discovered vulnerability involves what you can do when both a patch and a workaround have been released for dealing with it. Emin calls this the “reduced/mitigated” approach where you “apply the workaround instead of patching first as this gives you more time, and you can patch later.” As an example, Emin mentions that “Whenever there’s a zero-day in Flash, you can apply the workaround and set a kill-bit in the registry.” The “kill bit” he is referring to is a registry setting that disables attempts to instantiate Adobe Flash Player in Internet Explorer and other applications that honor the kill bit feature. You can find more information about this in MSCR Security Advisory ADV180014. Emin also relates that another recent example of this involved the IE11 security update of August 14, 2018 that broke ADFS, SSO, and redirects. Administrators who experienced such problems after installing the update had several choices of how to continue. “You could uninstall the security update,” says Emin, “or fortunately you could apply the workaround (add the website to the trusted site zone) and wait for the hotfix released on August 30, 2018, which was afterward included in the next CU of September 2018.”
‘Shared/transferred’ approach to patch management
A third approach to managing the risks associated with a vulnerability is what Emin calls the “shared/transferred: approach. Or as Emin puts it, “get more budget and buy a more expensive insurance” that can transfer the risk involved from your organization to an insurance company. This is actually a quite common approach to risk management followed by large enterprises for certain types of new and highly disruptive vulnerabilities. Emin says for example that “many Fortune 500 bought bitcoins before they were hit by ransomware so that they can follow the FBI notice and pay the ransom when they have an incident.”
The fourth and final approach to patching vulnerabilities that Emin identifies is to simply avoid the risk associated with the vulnerability by either patching it immediately or — as a drastic resort — by removing the offending software or Windows component from the exposed systems. For example, if a serious zero-day vulnerability was identified in Adobe Acrobat for which Adobe has not yet released a patch, you could decide to simply uninstall Acrobat from all client systems and install a different PDF reader program instead in its place. As an example involving a Windows component, Emin mentions that he “removed SMB v1 six months before there was Wannacry (see here for how to do this) and immediately applied MS17-010 to fix the Ethernalblue vulnerability CVE-2017-0144.”
Patch management: 4 different approaches
To recap then, there are four different approaches you can choose from to deal with the risk associated with a newly discovered vulnerability in Windows or an application:
- Accept the risk for now and wait for Microsoft to release a patch for it.
- Reduce/mitigate the risk by applying the workaround (if any) that Microsoft recommends until you have time to fully evaluate the risk associated with applying the patch itself.
- Share/transfer the risk by pulling out your wallet and calling your insurance company.
- Just apply the patch to avoid getting nailed by the exploit identified by the MSRC advisory.
Naturally, each vulnerability, workaround, and patch has to be dealt with separately to determine which approach is best in terms of its risk for your environment.
