Windows Patch Management: The Best Practices You Need to Start Today

With today’s security landscape, most IT and security professionals are aware of the importance of Windows patch management. However, many organizations choose to neglect the most important part of patch management—patching Windows applications (i.e. third-party applications) in addition to patching the Windows OS. Based on CVSS scores (i.e. the “risk score” associated with vulnerabilities), the riskiest applications not to patch are third-party applications and not the Windows OS itself.

Analyzing CVSS scores for Windows products (OS and third-party apps) shows that many of the “riskiest” products are third-party apps. This website provides a list of the top 50 products by total number of "distinct" vulnerabilities. Even though the list is ever changing, I can assume that at the time you will be viewing this page, the number of 3^rd party applications in this list will still be significant.

The obvious conclusion? You must implement a Windows patch management process that focuses on third-party application patching as well as Windows OS patching.

In this post I’ll share my experience as a security product manager and offer some Windows patch management best practices.

1) Scan your endpoints and servers for missing patches at least weekly—and for ALL products—even if you don’t intend to patch those products.

Why scan for everything when you only want to patch a smaller set of applications? Simply scanning for everything provides the needed visibility into your environment. Remember, bad guys don’t “care” about your internal Windows patch management processes. They’ll target unpatched applications whether you decide to patch them or not. Understanding your patch state with all applications helps you better understand your security posture and what you can do to improve it. Understanding your “patch” posture also becomes valuable when you get hacked.

2) Define a set of operating systems and third-party applications that you “want” to patch, as many as you can. Every Patch Tuesday, start to roll out those patches to your endpoints and servers.

Most of the customers I speak with use Patch Tuesday as the “launching” date for a new patch “campaign”. This makes sense as many vendors release patches around the Patch Tuesday timeframe. The key here is to keep track of patches that are released after Patch Tuesday, and to make sure that new patches are always added to your Windows patch management queue.  

It’s also very important to patch proactively, on a predefined cadence. Don’t wait for your security team to find vulnerabilities and ask you to patch them. Make sure you patch proactively so your security team doesn’t find un-patched applications in their security scans. Doing so will save time and allow the security team to focus on other security issues that can’t be automated.

Remember, even if you had a bad experience patching third-party applications in the past (Java?) and decided not to patch them, the bad guys most likely already have automated tools that can leverage the vulnerabilities in those applications.

As a guidance we recommend our customers to aim for 14 days SLA – in order 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 that “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 that 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? Consequently, 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 other 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 patches as soon as they go online or turn on. This can be managed and controlled with the right Windows patch management tools.