Software is rarely a one-and-done proposition.
In fact, any app currently available may need to be updated – or patched – to fix bugs, overcome vulnerabilitiesand update key features at some point in the future.
With a typical enterprise relying on multiple applications, servers, and endpoint devices in their day-to-day operations, the acquisition was strong patch management platform to identify, test, deploy, install, and document all appropriate patches is essential to ensure the system remains stable and secure.
As with most technology tools, not all patch management solutions are created equal, and what is considered powerful by one organization may prove inadequate for another. However, an evaluation that starts with a focus on certain key criteria – the essential attributes and functionality that many vendors may offer but not all of them – will allow IT teams to narrow their options as they work to identify the best solution for their organizational patch. management needs.
The patch management tool’s ability to maintain an inventory of all patchable systems is essential for managing patches at every level. Important information to track includes:
- operating system and applications
- current and previous versions
- patch group
- patch dependencies.
Where the inventory resides—whether it’s part of a patch system, or can it be stored in an existing system configuration—is also an important consideration.
When coupled with the continuous integration/continuous delivery (CI/CD) process in DevOps, the patch lifecycle becomes part of software development for internal applications. However, keep in mind that the patch lifecycle can represent complex dependencies. For example, in the Linux operating system, the platform must determine whether a patch can be applied or if an existing patch must be removed before a new patch is applied, in which case the original patch can be reinstalled.
In order to determine the impact of patches on existing systems, the patch management tool must be capable of deploying patches for testing in a closed environment. This should include the ability to enable debug-level logging on patch installations to ensure no errors are suppressed or determine what triggered the failure if one occurred. The decision maker should also determine whether there is support for testing on isolated systems, in pilot groups, or, ideally, in an air gap environment to validate patches.
Solutions must be able to apply patches to all intended systems, including specifying the appropriate deployment policies, groups, and methods for the items to be patched. Ideally, deployments will be able to call pre- and post-scripts during deployment to handle service, app termination, backup runs, or checkpoints, tests, and restarts. There must also be a testing process completed before the nodes are added back into rotation on the load balancer.
A patch management tool should know who the trusted uploaders and publishers are, be able to validate patches, and support an on-site repository of validated and trusted patches. While the use of distributed on-site repositories is optimal for performance and security purposes, use of vendor and on-site repositories is to be expected. Any tool that relies solely on vendor repositories offers the most undesirable storage situations.
The patch management solution must be able to automatically or manually prioritize patches for deployment. If setting patch priorities involves a manual process, it is very important to know the data source used. If the vendor gives priority, it’s important to understand how the patch system uses this information. Using vendor priority, CVE, and on-demand emergency response (zero-day patches) will provide enterprises with the most complete patch management solution.
Patching can use agent or agentless scanning methods. Systems with only agentless methods have a negative impact on network and CPU performance and are therefore the least desirable. However, when using agents is desirable, solutions using agent and agentless approaches provide the most flexibility.
Third Party Support
Enterprise patching solutions should be able to patch third-party applications, especially on desktops and laptops, as these can be vectors for viruses, malware or ransomware. Obviously, the ability to support all the common applications of the major players – Adobe, Microsoft, etc. – non-negotiable. Ideally, however, third-party support will be extensive and include the ability to support internal application patching.
With businesses and organizations forced to navigate an increasingly insidious landscape of ransomware and other cyberthreats, identifying an effective patch management solution is critical to ensuring safe and efficient operations. However, as the space has been flooded with vendors, determining which solution best suits the needs of a particular company has become more and more complicated.
There may not be a single patch management solution for every company, 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 deemed non-negotiable, decision makers will be in a better position to formulate a short list of vendors and solutions that are most likely to meet their organization’s needs.
Looking for further guidance? Be sure to download the latest reports from Syxsense and Gigaom: Key Criteria for Evaluating Patch Management.