Don't Neglect Patch Management Best Practices

Patch management is an essential task that nonetheless is all too easy to neglect. And, even if an organization is diligent about its patch management, there is a big difference between doing patch management and doing it well. This article outlines six patch management best practices.

1. Create a comprehensive (and ongoing) software inventory

The first step in creating a solid patch management process is to create an inventory of all of the systems that you need to manage. This inventory will need to include both operating systems and applications. It’s also important not to neglect systems that may be siloed, as well as IoT devices for which patches may be available. (IoT devices often run Windows or Linux.)

Keep in mind that the inventory collection process is not a one-time task. A software inventory is relevant only if the inventory is current. As such, you should look for an automated tool that can help you to perform my routine inventory collection operations.

2. Determine what patches are available and when

Microsoft has long referred to the second Tuesday of the month as Patch Tuesday. It’s the day when the company rolls out all of its latest security patches. Although Microsoft may have started Patch Tuesday, the practice has spread across the software industry. There are some vendors (such as Adobe) that release their patches on Patch Tuesday in an effort to make things a little bit easier on admins. Other vendors might not release patches on Patch Tuesday, but have developed their own regularly scheduled release cadence. It’s important to be aware of such release cadences so that you can anticipate when new patches will be released.

3. Prioritize patch deployment

Microsoft (and other vendors) rate security patches based on the severity of the vulnerabilities they are designed to address.

Critical patches, for example, usually address vulnerabilities that would allow an attacker to remotely execute code on the system, potentially without end user involvement. In other words, the user does not necessarily have to click on a malicious link or open an infected attachment. Simply visiting a web page or opening an email (without opening an attachment) could be enough to allow the machine to be compromised. A vulnerability that has been categorized as important, on the other hand, might still allow an attacker to take over a system, but a user would first receive a warning message or prompt letting them know that something bad could happen if they chose to continue.

Moderate risk vulnerabilities are those that are relatively easy to avoid by taking advantage of existing security features. If, for example, a particular exploit is found to be ineffective on a system that has multi-factor authentication enabled, Microsoft will still typically patch the vulnerability, but will give it a moderate rating since the vulnerability should be a non-issue on systems that are following security best practices.

Low risk vulnerabilities are at the bottom end of the scale. This rating is used for vulnerabilities that exist, but are considered almost impossible to exploit.

4. Test patches before deployment

Any newly released patch should be tested prior to installing it on a production system. In the case of critical vulnerabilities, that testing should be minimal. The need for quickly addressing the vulnerability often outweighs the chances that the patch will break something, especially if you have done at least some level of testing before applying the patch.

Patches with less urgent ratings can be tested for longer periods of time. Even so, it is important to have a policy in place that requires a patch to be either approved for use or rejected within a specific length of time. This will help to prevent systems from remaining vulnerable for an extended period of time.

5. Audit patch deployments on a regular basis

As important as it may be to apply security patches in a timely manner, it is equally important to perform frequent audits to ensure that the approved patches have actually been installed. Patch deployments can fail for any number of reasons. Likewise, an audit may reveal that some systems have been patched, but remain unprotected because they have not yet been rebooted.

6. Treat your patch management system as a critical asset

Enterprise patch management almost always uses automated tools such as Microsoft’s WSUS or one of the many third-party patch management tools. Whatever tool you happen to be using, you should secure your patch management server to the same degree that you would secure other critical assets, such as domain controllers or DNS servers. Remember, if an attacker were to somehow compromise your patch management system, they could conceivably use it to remove critical security patches from other systems, thus making those systems easier to attack.