Software is rarely a one-and-done proposition.
In fact, any application available today will likely need to be updated – or patched – to fix bugs, address vulnerabilities, and update key features at multiple points in the future.
With the typical enterprise relying on a multitude of applications, servers, and end-point devices in their day-to-day operations, the acquisition of a robust patch management platform to identify, test, deploy, install, and document all appropriate patches are critical for ensuring systems remain stable and secure.
As with most tech tools, not all patch management solutions are created equal, and what’s seen as robust by one organization may prove inadequate for another. However, an evaluation that begins with a focus on specific key criteria – essential attributes and functionality likely to be offered by many vendors but not all – will allow IT teams to narrow down their options as they work to identify the best solution for their organization’s patch management needs.
Inventory
A patch management tool’s ability to maintain an inventory of all patchable systems is essential for managing patches at every level. Vital information to track includes:
- the operating system and applications
- current and past version
- patch groups
- patch dependencies.
Where the inventory resides—is it part of the patch system, or can it live in an existing configuration system — is also an important consideration.
Life Cycle Management
When combined with continuous integration/continuous delivery (CI/CD) processes in DevOps, the patch lifecycle becomes a part of software development for in-house applications. However, keep in mind that patch lifecycles can exhibit complex dependencies. For instance, in Linux operating systems, the platform must determine whether a patch can be applied or if an existing patch must be removed before the new patch is applied, at which point the original patch can be reinstalled.
Patch Testing
In order to determine the impact of a patch on existing systems, a patch management tool must be capable of deploying a patch for testing in a closed environment. This should include the ability to enable debug-level logging on patch installations to ensure no errors were suppressed or determine what triggered a failure in the event that they were. Decision makers should also determine whether there is support for testing on isolated systems, in a pilot group, or, ideally, in an air-gapped environment to validate patches.
Patch Deployment
A solution must be able to deploy patches to all intended systems, including determining deployment policies, groups, and methods appropriate for the item to be patched. Ideally, a deployment will be able to call pre- and post-scripts during deployment to address services, application shutdown, backup processes, or check-pointing, testing, and restart. There must also be a testing process completed before the node is added back into rotation on the load balancer.
Trusted Sources
A patch management tool should know who trusted uploaders and publishers are, be able to validate the patch and support an on-site repository of validated and trusted patches. While the use of distributed on-site repositories is optimal for both performance and security purposes, the use of both vendor and on-site repositories is the expected condition. Any tool solely relying on a vendor repository offers the least desirable storage situation.
Patch Prioritization
A patch management solution must be able to either automatically or manually prioritize patches for deployment. If setting patch priority involves a manual process, it’s critical to know the data source used. If the vendor provides the priority, it’s essential to understand how the patch system consumes this information. The use of vendor priority, CVEs, and emergency response when necessary (zero-day patches) will provide an enterprise with the most complete patch management solution.
Patching Architecture
Patching can utilize either an agent or agentless method of scanning. Systems with only agentless methods have a negative impact on network and CPU performance and are thus the least desirable. However, while using an agent is expected, solutions utilizing both an agent and an agentless approach provide the most flexibility.
Third-Party Support
An enterprise patching solution must be able to patch third-party applications, especially on desktops and laptops, as these can be a vector for viruses, malware, or ransomware. Obviously, the ability to support all common applications from major players – Adobe, Microsoft, etc. – is non-negotiable. But ideally, third-party support would be extensive and include an ability to support the patching of in-house applications.
Take Away
With businesses and organizations forced to navigate an increasingly treacherous landscape of ransomware and other cyber threats, identifying an effective patch management solution is absolutely critical to ensuring safe and efficient operations. However, as the space has become awash in vendors, determining which solution will best meet the needs of a specific enterprise has only grown more complicated.
There may not be a single patch management solution for every enterprise, making selection more of a process than a simple choice of vendor. However, when the search for a patch management solution begins with an emphasis on key criteria considered to be non-negotiable, decision-makers will be in a better position to formulate a short list of vendors and solutions most likely to meet their organization’s needs.
Looking for more guidance? Be sure to download the latest report from Syxsense and Gigaom: Key Criteria for Evaluating Patch Management.
