OPS.1.1.3 Patch and Change Management

If IT components, software, or configuration data are changed, there MUST be specifications that also consider security aspects. These MUST be defined in a concept for patch and change management and followed accordingly. All patches and changes MUST be suitably planned, approved, and documented. Patches and changes SHOULD be suitably tested in advance (see also OPS.1.1.6 Software Tests and Approvals in this regard). If patches are installed and changes carried out, fallback solutions MUST be available. If there are major changes, the Chief Information Security Officer MUST also be involved. Overall, it MUST be ensured that the desired security level is maintained during and after the implementation of changes. In particular, the desired security settings SHOULD also be maintained.

Persons in charge of patch and change management MUST be specified for all organisational areas. The defined responsibilities MUST also be reflected in an organisation's access control policy.

The handling of integrated auto-update mechanisms of the software used MUST be defined within a strategy for patch and change management. In particular, it MUST be specified how these mechanisms are to be safeguarded and appropriately configured. Moreover, the type of update mechanisms of new components SHOULD be checked.

IT systems and software SHOULD be updated regularly.

In principle, patches SHOULD be applied promptly after release. Based on the patch and change management concept at hand, patches must be assessed promptly after release and prioritised accordingly. Decisions MUST be taken as to whether patches should be applied. When a patch is applied, it SHOULD be checked whether it has been successfully applied on all relevant systems in a timely manner. If a patch is not applied, this decision and the reasons for it MUST be documented.

The IT Operation Department MUST ensure it is regularly informed about vulnerabilities which become known in the firmware, operating systems, applications, and services used. The identified vulnerabilities MUST be rectified as soon as possible.

As long as no appropriate patches are available, other appropriate safeguards to protect the systems affected MUST be implemented depending on the severity of the vulnerabilities and basic threats. If this is not possible, it SHOULD be ensured that the corresponding hardware, relevant operating systems, and applications and services are no longer used.

All requests for changes SHOULD be recorded and documented. Change requests SHOULD be checked by the person responsible for patch and change management to ensure that the information security aspects have been sufficiently taken into account.

The coordination process associated with a change SHOULD take into account all the relevant target groups and the impact on information security. The target groups affected by the change SHOULD be able to comment on the change in a verifiable manner. There SHOULD be a defined procedure to speed up the handling of important requests for changes.

The change management process SHOULD be integrated into business processes or specialised tasks. In cases involving planned changes, the current situation of the affected business processes SHOULD be considered. All relevant departments SHOULD be informed of upcoming changes. There SHOULD also be an escalation level that includes members of the corresponding organisation's Top Management. In case of doubt, these members SHOULD decide on the priority and scheduling of a given hardware or software change.

Requirements and framework conditions SHOULD be defined for selecting tools for patch and change management. Furthermore, a specific security policy SHOULD be drawn up for the tools used.

When new hardware is selected, it SHOULD be checked that the software used, and in particular the relevant operating systems, are compatible with the hardware and its driver software. New hardware SHOULD be tested before it is used. It SHOULD be tested exclusively in an isolated environment.

There SHOULD be an acceptance procedure and a declaration of release for IT systems. The person in charge SHOULD file the declaration of release in a suitable place in writing. If errors are detected during live operations despite the acceptance and release procedures, there SHOULD be a procedure for troubleshooting.

The authenticity and integrity of software packages SHOULD be ensured throughout the patch or change process. To this end, it SHOULD be checked whether checksums or digital signatures are available for the software packages used. If there are, these SHOULD be checked before a package is installed. Furthermore, it SHOULD be ensured that the programs required for checking are available.

As a matter of principle, software and updates SHOULD only be obtained from trustworthy sources.

Changes SHOULD be documented in all phases, applications, and systems. Corresponding rules SHOULD be developed for this purpose.

Before using a change management tool, it SHOULD be checked whether it can distribute changes appropriately in the information domain in question. It SHOULD also be possible to define break points for stopping the distribution of incorrect changes.

The Process Owner for patch and change management SHOULD perform follow-up tests to verify that a given change has been successful. For this, the Process Owner SHOULD select suitable reference systems as quality assurance systems. The results of follow-up tests SHOULD be documented within the scope of the change process.

In the change management process, appropriate mechanisms SHOULD ensure that devices that cannot be reached temporarily or for a longer period of time also receive patches and changes.