Change Management for Patches and Software Updates
At Shinydocs, customers deploy our solutions on-premises, in their own data centres, rather than in the cloud. As a result, Shinydocs generally adapts to our customers' own internal change management processes when deploying our solutions. This is equally true for the deployment of product patches, security patches and other product updates. That said, Shinydocs does provide strong guidance to our customers regarding change management best practices for applying patches, security patches, and software updates.
Patches vs. Security Patches vs. Software Updates
The terms patch, security patch, and software update may appear interchangeable, but there are distinctions worth noting:
A patch is a discrete package aimed at quickly correcting a product defect associated with a feature.
A security patch is similar to a patch but its purpose is to safeguard the customer's IT infrastructure against potential security vulnerability which may or may not be tied to a product defect in the Shinydocs software itself.
A software update is a new, full version of the Shinydocs solution which provides new features for the customer.
Change Management Best Practices
Whether applying a patch, a security patch or an update, a proper change management process is vital for successful customer deployments. As with all system modifications, Shinydocs recommends that all patches and updates must be performed and tracked through a change management system. In IT Change Management, it is generally accepted that they are three types of change:
Standard Changes
These changes are a part of the regular daily operation of a customer's IT service or infrastructure. The rollout processes are clearly documented and the risks, if any, are both known and deemed to be low. An example of a standard change might be the installation of a new printer or the setup of Shinydrive on a new laptop.
Normal Changes
These changes must go through a formal approval workflow or process before they can be implemented. If they are perceived to be high-risk, a customer's Change Advisory Board (CAB) typically determines whether they will be implemented (at all) and also when they will be scheduled. See below for more information about CABs. An example of a normal change might be upgrading Cognitive Toolkit from version 2.7.0 to 2.8.0 to utilize the new Folder Classification for OpenText Content Server feature added to the 2.8.0 release.
Emergency Changes
These are changes that must be performed as soon as possible. An example of an emergency change would be a security patch associated with a zero day security vulnerability (ie. a vulnerability in a system or device that has been disclosed but has not yet been patched).
Change Advisory Boards
A Change Advisory Board (CAB) is a group of people responsible for the authorization and scheduling of all Normal or Emergency changes. They are responsible for assessing, prioritizing, authorizing and scheduling each change and may be made up from cross-functional stakeholders within the customers organization.
Key Steps to Effective Patch Management
In IT Service Management, managing the deployment of patches and updates is considered to be a subset of an effective Change Management process. While not an exhaustive list, Shinydocs recommends that our customers follow the steps outlined below for effective patch management.
Develop an Inventory
Shinydocs customers are strongly encouraged to develop an up-to-date, documented inventory of their internal systems. In doing so, customers will be able to better monitor the assets in their ecosystem, regardless of whether the monitoring is performed daily, weekly or quarterly. Once established, customers will have an accurate view of their operating systems, version types, IP addresses, patch levels, geographical positions, etc. The more thorough and current the inventory, the more effective and predictable the patch management process.
Standardize Across Environments
Shinydocs customers are strongly encouraged to develop a plan for standardizing computer systems and operating systems to the same version, particularly between TEST and PROD systems. While this can be a complex undertaking, it is essential. Standardizing an asset library will make patching faster and more efficient and will de-risk new deployments and upgrades, saving technical teams time spent on testing, re-testing, and ongoing remediation.
Document Security Controls
Shinydocs customers are strongly encouraged to document and complete a list of existing security controls in place within the organization, including firewalls, proxies, antivirus software, identity management tools, performance management tools, clusters, vulnerability management tools, etc. Customers should know how each is setup and configured, what they are protecting, the names and contact details for the team members responsible for each of the controls, and any hard or soft assets associated with each.
Review Patches
Shinydocs customers are strongly encouraged to evaluate all reported patches, security patches, and updates released by Shinydocs in a timely fashion and compare the descriptions for each of those items against their inventory and list of security controls. This can be done as part of a routine exercise for the Change Advisory Board or as a separate task for IT Team members suited to the role. When this review is performed regularly and reliably, Shinydocs customers will have a clear picture of the advantages and risks associated with each newly-released item and will be able to quickly identify which assets would benefit from changes or improvements, as well as which assets may be susceptible to reported vulnerabilities.
Deploy and Test
Shinydocs customers are strongly encouraged to download and deploy patches, security patches and updates in low level (DEV, SANDBOX, or TEST) environments in their lab at their earliest convenience. As part of this testing, Shinydocs customers can establish the safety and validity of the change, making sure that its deployment would not cause any difficulties for systems, end users or other stakeholders. The data gathered as a result of this testing can be fed to the CAB in order to inform decision-making about the eventual promotion of the change to the production environment.