Why Are Patch Management and Change Management Important?

My last blog I wrote about Change Management.  As I wrote that article I pondered a discussion I had with a client about their impending patch project.  I warned him that this patch event would be big and present a lot of risk.  Careful planning and approval of the process should be required.  Then I came across a column linked below.  It is well written and covers the patch management topic well.  It has so many good quotable paragraphs, but here are the gems of the gems.  Alvaka Networks has arguably the best and most sophisticated patch management process in the Orange County, Los Angeles County and possibly the US.  Not many firms can deploy vast quantities of patches to valuable high availability servers and PCs with smoke testing qualify control while following the sun globally during selected narrow service windows.

The opening paragraph tells it like it is.  Like my previous blog the author cites the need for a roll-back or back-out plan.

 Change Management
Change management is vital to every stage of the patch management process. As with all system modifications, patches and updates must be performed and tracked through the change management system. It is highly unlikely that an enterprise-scale patch management program can be successful without proper integration with the change management system and organization.

Like any environmental changes, patch application plans submitted through change management must have associated contingency and backout plans. What are the recovery plans if something goes wrong during or as a result of the application of a patch or update? Also, information on risk mitigation should be included in the change management solution. For example, how are desktop patches going to be phased and scheduled to prevent mass outages and support desk overload? Monitoring and acceptance plans should also be included in the change management process. How will updates be certified as successful? There should be specific milestones and acceptance criteria to guide the verification of the patches’ success and to allow for the closure of the update in the change management system (e.g. no reported issues within a week of patch application).

Here the author cites the need for good planning, change management and the roll-back plan.

Change Management
Change management is vital to every stage of the patch management process. As with all system modifications, patches and updates must be performed and tracked through the change management system. It is highly unlikely that an enterprise-scale patch management program can be successful without proper integration with the change management system and organization.

Like any environmental changes, patch application plans submitted through change management must have associated contingency and backout plans. What are the recovery plans if something goes wrong during or as a result of the application of a patch or update? Also, information on risk mitigation should be included in the change management solution. For example, how are desktop patches going to be phased and scheduled to prevent mass outages and support desk overload? Monitoring and acceptance plans should also be included in the change management process. How will updates be certified as successful? There should be specific milestones and acceptance criteria to guide the verification of the patches’ success and to allow for the closure of the update in the change management system (e.g. no reported issues within a week of patch application).

Here is a well-articulated section about the importance of controls in the patch management process if it is to go smoothly and if security objectives are to be truly achieved.  This whole section makes a strong argument for using good patch management tools and Patch Management as a Service, something likeAlvaka Networks Patchworx service that is used by clients who place a high value on security or who have compliance needs like HIPAA, the Health Insurance Portability and Accountability Act of 1996 (Pub.L. 104–191, 110 Stat. 1936), Gramm-Leach-Bliley ACT 15 U.S.C. §§6801-6809 in financial services orSarbanes–Oxley Act of 2002 (Pub.L. 107–204, 116 Stat. 745, enacted July 30, 2002), also known as the “Corporate and Auditing Accountability and Responsibility Act” for public companies.

While applying patches, and especially security updates, in a timely manner is critical, these updates must be made in a controlled and predictable fashion. Without an organized and controlled patch application process, system state will tend to drift rather quickly from the norm and compliance with mandated patch and update levels will diminish. In general, users and even administrators should not be permitted to apply patches arbitrarily. While this should be addressed initially at a policy and procedure level (e.g. with acceptable use policies, change management, and established maintenance windows), it may also be appropriate to apply additional technical controls to limit when and by whom patches can be applied. The type of controls enforced will vary by organization and requirement, but include items such as restricted user rights (the user does not have sufficient permissions to update the system) and network-based access controls….

If there was ever an argument for Alvaka Networks Patchworx Patch Management as a Service the closing paragraph says it all so well.

Conclusion 
While the issue of patch management has technology at its core, it’s clear that focusing only on technology to solve the problem is not the answer. Installing patch management software or vulnerability assessment tools without supporting guidelines, requirements, and oversight will be a wasted effort that will further complicate the situation. Instead, solid patch management programs will team technological solutions with policy and operationally-based components that work together to address each organization’s unique needs.

The whole article is rich in information.  To read the whole column, click HERE.

2017-07-05T10:20:31+00:00