S 2.421 Planning the patch and change management process

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Change Manager

Every organisation should establish a clearly defined process for patch and change management and should dispose of clear regulations regarding the responsibilities for the different tasks (see S 2.423 Specification of responsibilities for patch and change management). All changes regarding hardware and software versions and configurations should be controlled and monitored using the patch and change management process. In order to be able to record and evaluate all changes, all IT systems supported by patch and change management should be assigned to the Change Manager. This means changes to the configuration and status of these systems should only be possible through the patch and change management system.

The patch and change management process may be represented schematically as follows, based on ITIL:

Figure: Overview of the patch and change management process

Coordination

After a request for change (RfC) has been submitted and accepted, the request must first be categorised and prioritised before the actual implementation planning and coordination is started.

Once a request for change (as described in S 2.422 Handling change requests) has been submitted and accepted, it must first be classified, i.e. categorised, and prioritised before the actual implementation planning and coordination is started. Subsequently, further items should be taken into account before the patch or change can be installed.

• Procurement or development of the patches and changes
  
  Many manufacturers offer the possibility of obtaining the required information regarding the publication of new hardware or software or occurred errors and their remedies via email by subscription.
  
  The updates and patches are normally provided for download on internet servers. Sometimes these sources are only accessible in connection with the valid registration or support agreements. Frequently, the installed software or the installed operating system provides the user with the option of uploading software changes directly using the respective application or system.
  
  Some manufacturers provide their customers with specific applications in order to manage and update the products. Additionally, there is an increasing number of applications which automatically search for updates from their manufacturers via the internet and inform the user as appropriate if this is allowed by the user and the security settings. From a security point of view, automatically installing changes has disadvantages, however. Therefore, it should be carefully considered whether such mechanisms should be used.
  
  Another option for procuring software changes includes an internal software development, if this is required by security gaps which have arisen or other requirements. However, this does not only require the necessary expertise, but the interfaces must be open as well.
• Testing
  
  The functionality of the systems must be confirmed by testing after having installed the change. For this, a representative selection of typical application scenarios must be defined and tested with the specialised department during every change. The results must be documented and compared to the expected results in order to determine possible improper behaviour. Furthermore, all log files created during the test must be checked for indications of malfunctions.
• Integration into the software distribution, integration testing
  
  Often, specific packet and file formats the manufacturers use to provide their updates require adaptation so that these can be used in an automatic software distribution system. This is particularly applicable if active components must be executed, e.g. Shell scripts, during or after the installation. These adaptations must be checked for efficiency on a test system before the changes can be distributed.

Implementation

The employees appointed by the Change Manager are ordered to implement the change. This is monitored by change management. Regarding changes that can only be tested insufficiently, it makes sense in some cases to install these with only a small group of users first. Then, the results are evaluated before the change is implemented on all systems. If this is not possible or reasonable due to the circumstances, e.g. because comparable changes have been performed frequently without any problems or because incompatible software versions render partial distribution impossible, complete distribution may also be performed.

Evaluation

Implemented changes should subsequently be evaluated. Then, the result is evaluated by the change management and/or the CAB (Change Advisory Board) based on the following aspects:

• Did the change and/or patch achieve the objective aimed at?
• Are the customers and users satisfied with the result?
• Did side effects (disturbances regarding applications not affected by the change) occur?
• Were the budgeted costs, the planned effort, and the schedule complied with?

If the change was performed successfully, the request for change and/or the change dataset can be closed. If the change failed, it must be decided whether the implemented changes require adaptations. In some cases, it is recommendable to undo the change and to develop a new or modified request for change. In the event of a failed change, it may also make sense to determine the reasons and to adapt the IT systems and processes based on this. This way, similar problems can be avoided in the future.

Depending on the type and extent of the change, it may make sense to evaluate the change directly upon installation. On the other hand, it may also make sense to wait for a couple of days or weeks until the effects of the change and the achievement of the goals can be foreseen. Implemented changes are only completed successfully if they have been evaluated positively and documented. So that this is not forgotten, the Change Manager should be reminded of this by a timed, automated follow-up.

Withdrawal of changes

The decision as to whether it is necessary to withdraw hardware or software changes must be made based directly on the evaluation. If the changes did not achieve the desired success or if the situation even got worse, the changes should be withdrawn insofar as this is technically feasible and economically acceptable.

This may often be supported technically by the patch and change management software used. If this is not the case, the patches and changes must be undone manually.

Completion and documentation

It is recommendable to document all requests for change, hardware and software changes, test implementations, and test results in a database, regardless of whether or not these were successful (see S 2.34 Documentation on changes made to an existing IT system). The knowledge about errors which occurred while installing the changes and their solutions should be available as organisation-internal knowledge in the event this situation is repeated.

In many organisations, it has become routine to regularly supply operating systems and applications with the available software updates in order to eliminate vulnerabilities and to provide protection against malware. However, this procedure is also required for hardware; a fact commonly forgotten if the hardware works properly. In many IT devices, compact operating systems are used that are often tailored to the respective hardware. For example, these include routers, switches, network printers, and mobile phones. Therefore, it must be ensured that change management also covers such devices and that such devices are also provided with security-relevant updates.

Review questions:

• Is there a defined process for patch and change management?
• Are all changes regarding hardware and software versions and configurations controlled and monitored using the patch and change management process?