OPS.1.1.3 Patch and Change Management

Description

Introduction

It is a major challenge to update the IT components deployed in an institution correctly and in a timely manner. In practice, it is evident that existing security vulnerabilities or operational disruptions are frequently attributable to missing or inadequate patches and changes. A missing or neglected patch and change management process can therefore quickly lead to potential attack vectors.

The general task of patch and change management is to make modifying interventions in applications, infrastructure, documentation, processes, and procedures manageable and controllable.

Objective

This building block describes how a functioning patch management system can be established in an institution and how the corresponding process can be controlled and optimized.

Beyond patch management, however, the building block also contains some core aspects of change management that are relevant to information security. Change management refers to the task of planning and controlling changes.

Scope and Modeling

The building block OPS.1.1.3 Patch and Change Management is to be applied to the entire information domain.

The descriptions in this building block focus on IT Operations, and in particular on patch management, through which software is updated (e.g. through security fixes, service packs, and hot fixes). In the individual building blocks of the SYS IT Systems and APP Applications layers, more specific requirements regarding patch and change management may be found.

This building block does not contain a complete change management system, but only the core aspects related to information security. In larger institutions it makes sense to structure change management systematically beyond this. Standard works such as the change management process of the “IT Infrastructure Library” (ITIL) can be consulted for this purpose. Such change management does not have to be limited to IT, but can also encompass business processes and specialist tasks themselves. In this building block, “change” encompasses everything involved in adapting IT components, such as “changes,” “patches,” “updates,” “upgrades,” “installation,” “removal,” etc. Software development, on the other hand, is addressed in building block CON.8 Software Development.

Requirements for testing and approving patches and software are not addressed in detail in this building block. They can be found in building block OPS.1.1.6 Software Testing and Approvals.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to illustrate the threat landscape. The following specific threats and vulnerabilities are of particular importance for the building block OPS.1.1.3 Patch and Change Management.

Poorly Defined Responsibilities

Poorly defined, overlapping, or unresolved responsibilities can, for example, cause change requests to be categorized and prioritized more slowly. This can delay the overall distribution of patches and changes. Even if patches and changes are approved too quickly without a test run and without taking all (specialist) aspects into account, this can have a serious impact on security.

In extreme cases, poorly defined responsibilities can affect the entire institution completely or to a large extent. Operational disruptions have a negative impact on availability. If security-relevant patches are not distributed or distributed late, confidentiality and integrity may be jeopardized.

Poor Communication in Change Management

If patch and change management receives little acceptance within the institution or the persons involved communicate poorly, this can lead to change requests being processed late or incorrect decisions being made about a change request. This can reduce the overall security level and seriously disrupt IT Operations. In any case, poor communication makes the change process inefficient, as too much time and resources must be invested. This has a negative impact on the institution’s responsiveness and can in extreme cases lead to security vulnerabilities being created or important institutional objectives not being achieved.

Poor Consideration of Business Processes and Specialist Tasks

Inappropriate changes can, among other things, impair the smooth running of business processes or specialist tasks or even lead to the complete failure of the IT systems involved. Even the most extensive test procedure cannot completely rule out that a change will prove to be faulty in subsequent productive operation.

If the impact, category, or priority of a submitted change request is incorrectly assessed with regard to business processes or specialist tasks in the change process, the target security level can decrease. Such misassessments predominantly occur when the persons responsible for IT and the responsible specialist departments do not coordinate sufficiently.

Insufficient Resources in Patch and Change Management

Adequate personnel, time, and financial resources are required for effective patch and change management. If these are not available, for example, the necessary roles could be filled with unsuitable persons. Interfaces for certain information — for example, between IT and the corresponding contact persons in the specialist departments — cannot then be created either. The required capacities for the infrastructure of test and distribution environments could also not be provided. While the personnel, time, and financial shortcomings in regular operations can often still be compensated, they become all the more apparent under high time pressure — for example, when emergency patches must be applied.

Problems with Automated Distribution of Patches and Changes

Patches and changes are often distributed not manually but centrally with software support. If such software is used, faulty patches and changes can be distributed automatically throughout the entire information domain, which can create major security problems. It is particularly serious when software containing security vulnerabilities is installed simultaneously on many IT systems.

If only isolated errors occur, they can often be corrected manually. It becomes problematic, however, when IT systems are unreachable for longer periods. One example is employees in the field who connect their IT systems to the institution’s LAN only rarely and irregularly. If the tool is configured such that updates are only distributed within a certain time period, and not all IT systems are reachable during that time, these IT systems cannot be updated.

Poor Recovery Options in Patch and Change Management

If patches or changes are distributed without a recovery option being provided, or if the recovery routines of the software used do not work or do not work appropriately, faulty updated software cannot be corrected in a timely manner. As a result, important IT systems can fail and high consequential damage can occur. Beyond the loss of data, the availability and integrity of the data and the affected IT systems are particularly at risk.

Misjudgment of the Relevance of Patches and Changes

If changes are incorrectly prioritized, less important patches could, for example, be installed first. Important patches are then installed too late. Security vulnerabilities therefore persist for longer. Patch and change management is often supported by software-based tools. These tools can also contain software errors and thus provide insufficient or incorrect information about a change. If the information that such a tool provides about a change is not verified and tested for plausibility, the actual implementation of changes can deviate from the assumed implementation.

Manipulation of Data and Tools in Change Management

Patch and change management often operates from a central location. Due to its exposed position, it is particularly at risk. If an attack succeeds in taking over the servers involved, manipulated software versions could be distributed simultaneously to a large number of IT systems via this central point. Further attack vectors often arise because these IT systems are operated by external partner institutions (outsourcing). There may also be maintenance access points that allow access to the central server for distributing changes. These could also be used for attacks.

Requirements

The following are the specific requirements of building block OPS.1.1.3 Patch and Change Management. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.

The IT-Grundschutz Compendium additionally defines further roles. They should be staffed insofar as this is reasonable and appropriate.

Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, this role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

OPS.1.1.3.A1 Concept for Patch and Change Management (B) [Specialist Responsible Persons]

When IT components, software, or configuration data are changed, there MUST be requirements that also take security aspects into account. These MUST be documented and followed in a concept for patch and change management. All patches and changes MUST be appropriately planned, approved, and documented. Patches and changes SHOULD be appropriately tested in advance (see also OPS.1.1.6 Software Testing and Approvals Software Testing and Approvals). When patches are installed and changes are made, fallback solutions MUST be available. For larger changes, the ISO MUST also be involved. Overall, it MUST be ensured that the target security level is maintained during and after the changes. In particular, the desired security settings SHOULD also be maintained.

OPS.1.1.3.A2 Definition of Responsibilities (B)

Persons responsible for patch and change management MUST be defined for all organizational areas. The defined responsibilities MUST also be reflected in the authorization concept.

OPS.1.1.3.A3 Configuration of Auto-Update Mechanisms (B)

Within the patch and change management strategy, it MUST be defined how integrated update mechanisms (auto-update) of the software used are to be handled. In particular, it MUST be defined how these mechanisms are secured and appropriately configured. Furthermore, new components SHOULD be checked to determine what update mechanisms they have.

OPS.1.1.3.A15 Regular Updating of IT Systems and Software (B)

IT systems and software SHOULD be regularly updated.

In principle, patches SHOULD be applied promptly after publication. Based on the patch and change management concept, patches MUST be evaluated and prioritized promptly after publication. For the evaluation, it SHOULD be checked whether there are known vulnerabilities related to this patch. A decision MUST be made as to whether the patch should be applied. If a patch is applied, it SHOULD be checked whether it was successfully applied to all relevant systems in a timely manner. If a patch is not applied, the decision and the reasons for it MUST be documented.

If hardware or software products are to be used that are no longer supported by the manufacturer or for which no support is available, it MUST be checked whether these can still be operated securely. If this is not the case, these hardware or software products MUST NOT be used any further.

OPS.1.1.3.A16 DISCONTINUED (B)

This requirement has been discontinued.

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be fulfilled.

OPS.1.1.3.A4 DISCONTINUED (S)

This requirement has been discontinued.

OPS.1.1.3.A5 Handling of Change Requests (S) [Specialist Responsible Persons]

All change requests (Requests for Change, RfCs) SHOULD be captured and documented. The change requests SHOULD be checked by the respective specialist responsible persons for patch and change management to determine whether information security aspects have been sufficiently taken into account.

OPS.1.1.3.A6 Coordination of Change Requests (S)

The coordination process associated with a change SHOULD take into account all relevant target groups and the impact on information security. The target groups affected by the change SHOULD be able to provide verifiable input. There SHOULD also be a defined procedure by which important change requests can be accelerated.

OPS.1.1.3.A7 Integration of Change Management into Business Processes (S)

The change management process SHOULD be integrated into the business processes or specialist tasks. For planned changes, the current state of the affected business processes SHOULD be taken into account. All relevant specialist departments SHOULD be informed about upcoming changes. There SHOULD also be an escalation level whose members belong to the institution’s management level. The members of this escalation level SHOULD decide in cases of doubt on the priority and scheduling of a hardware or software change.

OPS.1.1.3.A8 Secure Use of Tools for Patch and Change Management (S)

Requirements and framework conditions SHOULD be defined by which tools for patch and change management are selected. Furthermore, a specific security policy SHOULD be created for the tools used.

OPS.1.1.3.A9 Testing and Acceptance Procedures for New Hardware (S)

When new hardware is selected, it SHOULD be checked whether 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 deployed. It SHOULD be tested exclusively in an isolated environment.

For IT systems, there SHOULD be an acceptance procedure and a release declaration. Those responsible SHOULD file the release declaration at an appropriate location in writing. In the event that errors are identified during ongoing operation despite the acceptance and release procedures, there SHOULD be a procedure for error resolution.

OPS.1.1.3.A10 Ensuring the Integrity and Authenticity of Software Packages (S)

Throughout the entire patch or change process, the authenticity and integrity of software packages SHOULD be ensured. For this purpose, it SHOULD be checked whether checksums or digital signatures are available for the software packages used. If so, these SHOULD be verified before installing the package. It SHOULD also be ensured that the necessary programs for verification are available.

Software and updates SHOULD generally only be obtained from trustworthy sources.

OPS.1.1.3.A11 Continuous Documentation of Information Processing (S)

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

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection corresponding to the state of the art. The proposals SHOULD be considered for high protection needs. The specific determination is made within the framework of an individual risk analysis.

OPS.1.1.3.A12 Use of Tools in Change Management (H)

Before a tool for change management is used, it SHOULD be carefully checked whether it can distribute changes appropriately in the information domain. In addition, it SHOULD be possible to define interruption points at which the distribution of a faulty change is stopped.

OPS.1.1.3.A13 Measuring the Success of Change Requests (H) [Specialist Responsible Persons]

In order to verify whether a change was successful, the respective specialist responsible persons for patch and change management SHOULD perform so-called post-tests. For this purpose, they SHOULD select suitable reference systems as quality assurance systems. The results of the post-tests SHOULD be documented as part of the change process.

OPS.1.1.3.A14 Synchronization within Change Management (H)

In the change management process, appropriate mechanisms SHOULD ensure that devices that are temporarily or persistently unreachable also receive the patches and changes.

Additional Information

Good to Know

The International Organization for Standardization (ISO) provides requirements in ISO/IEC 27001:2013, Chapter 12.1.2 Change Management, that are relevant to patch and change management.

The IT Infrastructure Library (ITIL) provides guidance on establishing a change management process.