S 2.425 Selection of suitable tools for patch and change management
Initiation responsibility: Head of IT, IT Security Officer, Change Manager
Implementation responsibility: Change Manager, Head of IT
The patch and change management process can be supported using several products or combinations of products. There are various reasons for using a tool for implementing and carrying out the patch and change process. Heterogeneous IT infrastructures and the more effective use of resources are often decisive factors.
The requirements and general conditions should be determined first before purchasing a patch and change management tool so that a tool suitable for use in the corresponding organisation can be found. The procedure for the evaluation of a product is always similar and is based on the applicable patch strategy of the organisation, regardless of whether a patch and change management us required as tool for an operating system, for the range of products of a manufacturer or for a large heterogeneous IT scenario.
In the following, a selection of the most important features can be found, which should be taken into account when choosing products and are the basis for the specification of the requirements to be met by the software tool.
- Platform support:
In general, this term refers to two aspects. On the one hand, it is considered which platforms are supported regarding the implementation of the patch and change process and, on the other, on which platform the tool can be run. The first aspect in particular should be taken into consideration in great detail, as, for example in the server-client area, most tool manufacturers support change processes for Microsoft products. However, this does not mean that the entire range of IT products of desktop and server operating systems existing in the organisation, ranging from application servers to individual products, is also covered. - Patch analysis:
Some manufacturers focus on the amount of updates associated with the distribution process and their quick distribution as well as the reporting of the "delivery status". Some manufacturers provide more information on the backgrounds and/or reasons of a patch, sometimes with lists of affected files, detailed description of the vulnerabilities and their own test reports. Particularly for the use of security patches, which should generally be distributed quickly, the detailed information can include indispensable references for the internal classification of the hardware or software change. - Patch verification:
Most manufacturers supply hash sums, fingerprints or signatures with the patches and changes to confirm their authenticity and integrity; however, only a few of these tools also check such verifications. For this reason, there is the risk that undesired software is distributed in large quantities in the organisation and significant damage is caused. For security reasons, change tools that are not equipped with these functions should thus not be used. - Patch strategy:
The tool must allow flexible configuration so as to be able to automate as many steps of the selected patch strategy as possible. This strategy can differ greatly due to different platforms. The processes steps of the change process should be documented by the tool in an understandable manner, if necessary, even in an audit-proof manner. It must be possible that subsequent changes to the process can be incorporated in the tool. - Distribution:
Not every patch should be brought onto every system. The tool should allow the grouping of systems and applications according to freely definable attributes such as protection requirements, location and organisational unit. These attributes can become IT system profiles in accordance with the standardised system types in the organisation. - Rollback:
No software is perfect. Therefore, despite all preliminary tests, the need to reverse a patch process might arise. In case of an error, the automation of this process saves time and money! If faulty changes cannot be reverse promptly and with little effort, this can result in significant damage to the organisation. - Status evaluation:
There must be an automatism to properly distribute the changed hardware or software on all systems. As with software distribution in general, problems with the connection or availability of a system might occur. A patch can then be denied by the system because of other system states. Therefore, it is important that the change tool can collect information on the patch status of all systems. Depending on the strategy, the tool should continue the technical patch process for the remaining IT systems or skip certain system groups or terminate the patch process if problems have occurred.