Best Practices for Windows Patch Management

automated tools that can leverage the vulnerabilities in those applications.

As a guideline, we recommend that our customers aim for 14 days SLA–to get ahead of most exploits. The Verizon DBIR from 2016 states that “Half of all exploitations happen between 10 and 100 days after the vulnerability is published.” The same report from 2019 states, “Every time a vulnerability is disclosed or a system update or patch is released, a hacker sees an opportunity. They research the disclosure or update notes to learn if they can exploit the vulnerability and where, searching for their best opportunity to monetize the vulnerability.”

At Ivanti, we recognize the challenge our customers are facing with the need to patch more in less time. One of our patch product goals is to provide tools that will allow our customers to reduce the operational risk associated with third-party application patching. Utilizing those tools one can predict the impact of deploying a patch before deploying it–minimizing the uncertainty involved in deploying patches.

3. Start by deploying patches to pilot groups and extend your target groups as you get positive feedback about the patch’s quality.

This is the most common way customers patch. Yes, there are highly security-oriented customers that deploy patches to all their endpoints with minimal testing. For these customers, time-to-patch is more important than anything else. But for most of us, we have to balance security risk and operational risk. For example, we need to make sure patches don’t break applications before we deploy them to all our endpoints/servers.

The Windows patch-management best practice here is “simple”–start with a small pilot group of endpoints that represents the full set of applications that might be impacted by the patches. If the relevant users don’t report problems after their machines have been patched, expand the group to more users/application owners. Assuming you don’t receive negative feedback, move forward and deploy the patch to all endpoints and servers.

Please note that there are hidden challenges with this step. Most customers I speak with define their pilot groups based on what I call “friends of IT”–i.e., their friends in IT who are willing to volunteer as “guinea pigs” for testing those new patches. The challenge here is that, in most cases, there is no way of knowing in advance if those “testers” actually cover all the patch dependencies. For example, if you deploy a Java patch, can you tell for sure which applications depend on Java and, as a result, may break because of this Java patch?

Perhaps you had a bad experience with Java before, so you know about Java-dependent applications. But what about .NET dependencies or other low- or high-level technologies? Can you list all applications in your environment that depend on those patches? IT professionals use their experience and try to guess which users/endpoints should be part of the initial or secondary pilot groups. In some cases it works, but in others it doesn’t.

Fortunately, new Windows patch management technologies have been developed to remove the guesswork from this process and find the best candidates for each pilot group automatically. This allows a more accurate testing cycle, which in turn reduces the risk of business applications breaking when a third-party application patch is deployed.

One last tip: Make sure that every machine gets patched, including remote machines and machines that are rarely online.

Not all endpoints are always on—and not all endpoints are connected to the network all the time. An important Windows patch-management best practice is to ensure those devices get patched as soon as they go online or turn on. This can be managed and controlled with the right Windows patch management tools.

This guest blog is part of a Channel Futures sponsorship.