In 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 and Los Angeles County area, and possibly the US. Not many firms can deploy vast quantities of patches to valuable high availability servers and PCs with smoke testing quality control, while following the sun globally during selected narrow service windows. So why are patch management and change management so important?

The opening paragraph tells it like it is. Here the author cites the need for good planning, change management, and backout plan.

It’s obvious that patch management is a critical issue. What is also clear is the main objective of a patch management program: to create a consistently configured environment that is secure against known vulnerabilities in operating system and application software. Unfortunately, as with many technology-based problems, good, practical solutions aren’t as apparent. Managing updates for all the applications and operating system versions used in a small company is fairly complicated, and the situation only becomes more complex when additional platforms, availability requirements, and remote offices and workers are factored in.

Just as each organization has unique technology needs, successful patch management programs will vary in design and implementation. However, there are some key issues that should be addressed and included in all patch management efforts….

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 like Alvaka’s 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, or Sarbanes–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.

Software Patching Best Practices