Episode 2: Update Deferral Windows
In this latest in our blog series, we look at a particularly frustrating and common patch failure culprit: deferral windows in endpoint management tools.
Just about every IT operation leverages some kind of tool to deploy software to its endpoints. Intune, RMM (remote management and monitoring) products (e.g. Atera, Datto, Connectwise, NinjaOne, Kaseya), and Windows Update Agent (WUA) are all used to deploy endpoint software, and more importantly for this discussion, patches as well.
The good news is that all these endpoint management products are configurable.
The bad news is that all these endpoint management products are configurable.
For example, WUA is part of the Windows Operating System, is responsible for checking for Windows updates, pulling them from the Microsoft Update website or WSUS (Windows Server Update Service), and installing them. As mentioned, WUA is configurable, so, for example, it can be set to install updates automatically, or to prompt the user to do so manually. Although largely helpful, the WUA configuration options – and those for just about all other endpoint management tools – can be the source of patch failures.
Here’s how.
Fearing that new patches may cause disruption, many organizations configure their endpoint tools to postpone the installation of patches in a clumsy attempt to reduce patch disruption risk. If the deployment of an available patch is delayed, the thinking goes, those that cause disruption will break someone else’s network first, will be fixed by the vendor, and it will then be safe to deploy the fixed version. Those that aren’t disruptive will simply be installed x days later than they could have been, and the risk of a compromise of those unpatched systems during the period of delay is simply accepted.
The risk of disruption is feared more than the risk of a cyber breach. (A statement that encapsulates the governing ethos of vulnerability remediation for the past 3 decades.)
Thus, in the event an organization is deploying a third party patching product, endpoint management tool configurations can – and often do – result in patch failures. At trackd, for example, we’ve observed that upwards of 10% of patch failures by our users are the result of these deferral windows, as we don’t override existing operational or security configurations by default.
Mechanically, the deferral window setting isn’t complicated. Let’s say a new patch is released on June 11th (an actual Patch Tuesday date). The endpoint management product is configured to defer all patches by 30 days for the reason discussed previously. A patching solution like trackd attempts to install the patch on June 11th, but the endpoint management system won’t allow that patch to be applied until July 11th, so the patch attempt will fail.
The psychological source of the failure, of course, is the omnipresent fear that applying patches will result in a service disruption that will, at a minimum, make for a miserable few hours for IT practitioners, and could result in more serious repercussions. trackd was founded to counter exactly this rational, but largely anachronistic, fear. Although a very small percentage of patches ever cause disruption, practitioners have previously had no tools to help identify the few that are, prompting behavior that reflects an assumption that all patches are considered disruptive until proven otherwise. trackd’s unique vulnerability management and patching platform provides intelligence on how disruptive patches have been on other networks before practitioners apply them to production, giving them the confidence to patch aggressively, closing the window available to bad actors to exploit them, and ultimately obviating the need for deferral windows.
To learn more, visit trackd.
