Page312

Patch Management

One of the most basic, yet still rather difficult, tasks associated with maintaining strong system security configuration is patch management, the process of managing software updates. Easily the single most important way to materially improve an organization’s security posture would be to enhance its patch management practices. All software has flaws or shortcomings that are not fully addressed in advance of being released. The common approach to fixing software is by applying patches to address known issues. Not all patches are concerned with security; many are associated with simple non-security-related bug fixes. However, security patches do represent a significant piece of the overall patch ecosystem.

Software vendors announce patches both publicly and directly to their customers. Once notified of a patch, organizations need to evaluate the patch from a risk management perspective to determine how aggressively the patch will need to be deployed. The vast majority of all intrusions involve exploitation of vulnerabilities for which a patch exists yet has not been deployed in a timely manner. What constitutes a timely manner proves challenging to discern and should be informed by an organization’s risk management practices. The US Cybersecurity and Infrastructure Security Agency (CISA) maintains the Known Exploited Vulnerabilities Catalog, which can serve as input to even more strongly justify the rapid deployment of patches to critical systems[^10]. Despite a sense of urgency that might be felt for patch deployment, testing is typically required to determine whether any adverse outcomes are likely to result from the patch installation. From a timeline standpoint, testing often occurs concomitantly with the risk evaluation. Installation is the final phase of the patch management process, assuming adverse effects do not require remediation.

While the process of installing a single patch from a single vendor on a single system might not seem that onerous, managing the identification, testing, and installation of security patches from dozens of vendors across thousands of systems can become extremely cumbersome. Also, the degree to which patch installations can be centrally deployed or automated varies quite a bit among vendors. With attackers' exploitation efforts increasingly focused on client-side applications such as browsers (and their associated plugins, extensions, and frameworks), office suites, and PDF readers, the patch management landscape is rapidly growing in complexity.

Patch Testing and Deployment

While everyone understands the importance of patching, the required downtime for patch installation and also occasional service disruption resulting from issues with patches can impede their deployment. The maintenance window requirements can be frustrating, but ultimately justify requirement planning for routine maintenance as well as an exception process that can allow for an emergency patch window should there be express need for more accelerated patch deployment. To combat the challenge of the patches themselves causing service disruption, the common way forward is to again plan for that eventuality to allow for rapid detection of patch issues and recovery to the unpatched state. Ideally, patch issues would be discovered on non-critical systems so that patch deployment could be halted in advance of critical system impact.

Patch testing could potentially help identify these issues, but the frequency and volume of patches can make robust, and also realistic, patch testing fiendishly difficult. A common middle ground employs phased patch deployment. With this approach groups of systems are defined to have patches deployed along various timeframes such that a representative and yet non-critical subset systems will receive patches first, and patch deployment will only continue more widely if each phased group of systems achieves patch installation without issues.