S 1.14 Patch and change management
Description
The task of change management is to design all changes made to applications, infrastructure, documentation, processes, and procedures so that they are manageable and controllable. In the area of information technology in particular, many government agencies and companies are faced with the challenge of correctly and promptly making the necessary changes to components in their system landscapes due to the ever-increasing rate of development in technology and increasing user demands.
Experience in government agencies and companies has shown that security gaps or disruptions during operation are often caused by making changes incorrectly or not making the changes necessary. The lack of or a neglected patch or change management can quickly result in security vulnerabilities in the individual components, and therefore open up potential points of attack.
This module shows how to establish properly functioning patch and change management in an organisation, how to monitor and optimise the corresponding process for patch and change management to avoid disruptions to operations, and how to minimise and promptly eliminate security gaps. The descriptions are concentrated on IT operations, but can also be implemented in other business processes. Patch and change management as used in this module refers to the task of planning and monitoring changes, although this term is sometimes used in other contexts to refer to the people who actually perform the tasks in patch and change management.
The time and effort required for drawing up and implementing such a process are considerable. For this reason, this module should be implemented on large information systems in particular. For smaller and less complex information systems, it may be sufficient under certain circumstances just to implement S 2.221 Change management.
Threat scenario
The following typical threats to IT-Grundschutz are examined in this module:
Organisational Shortcomings
| T 2.1 | Lack of, or insufficient, rules |
| T 2.9 | Poor adjustment to changes in the use of IT |
| T 2.17 | Inadequate labelling of data media |
| T 2.26 | Lack of, or inadequate, test and release procedures |
| T 2.27 | Lack of or insufficient documentation |
| T 2.28 | Violation of copyright |
| T 2.132 | Poor consideration of business processes in patch and change management |
| T 2.133 | Poorly defined responsibilities for patch and change management |
| T 2.134 | Insufficient resources for patch and change management |
| T 2.135 | Poor communication in patch and change management |
| T 2.136 | A lack of an overview of the information system |
| T 2.137 | Poor and inadequate planning when distributing patches and changes |
| T 2.138 | Poor recovery options for patch and change management |
| T 2.139 | Poor consideration of mobile devices in patch and change management |
| T 2.140 | Inadequate contingency planning concept for patch and change management |
Human Error
| T 3.38 | Errors in configuration and operation |
| T 3.92 | Misjudging the relevance of patches and changes |
Technical Failure
| T 4.22 | Software vulnerabilities or errors |
| T 4.33 | Poor-quality or missing authentication |
| T 4.71 | Problems when automating the distribution of patches and changes |
Deliberate Acts
| T 5.2 | Manipulation of information or software |
| T 5.145 | Manipulation of data and tools for patch and change management |
Method recommendation
To secure the information system examined, other modules will need to be implemented in addition to this module. These modules are selected based on the results of the IT-Grundschutz modelling process.
A series of steps need to be taken to set up an effective system for handling patches and changes.
Planning and design
All changes to the hardware and software versions used as well as to their configurations should be controlled and monitored by patch and change management. In order to enable the documentation and evaluation of all changes, all IT systems entered in the patch and change management system should be subject to patch and change management (see S 2.423 Specification of responsibilities for patch and change management). This means changes to the configuration and status of these systems can only be made through the patch and change management system. The management of the government agency or company must then delegate the responsibility for patch and change management. The organisational implementation of patch and change management is a cross-functional task spanning various departments in an organisation. IT operations, information security management and the specialised departments must be involved in patch and change management.
Every single patch or change operation starts with a change request. The request should be formulated first and then checked by the change manager. The relevance, urgency, planned execution (deadline, procedure) as well as possible risks and problems should be specified and recorded in the change request (see S 2.421 Planning the patch and change management process and S 2.422 Handling change requests).
Technical aids, for example for automatic software distribution, can be used to support the patch and change management implementation. If special tools are used for patch and change management, then it must be ensured that a concept for their use is created (see S 2.424 Security policy for the use of patch and change management tools).
Purchasing
A variety of products can be purchased to support the patch and change management process. To select a suitable product from the choices available, the requirements for these tools, for example the platforms the product will need to support, must be specified before purchasing (see S 2.425 Selection of suitable tools for patch and change management).
Implementation
When implementing a patch and change management system, all IT systems to be managed by the system should be divided into groups of one or more systems. Furthermore, it is necessary to document changes to these systems at a central location (see also S 2.34 Documentation on changes made to an existing system).
Operation
Depending on the size and complexity of the patch to be installed or change to be made, it is recommended to define tests, checkpoints, breakpoints, and deployment priorities in an execution plan. When defining these items, it must be ensured that the intended security level is maintained while making the change and after the change has been completed. The approval and execution of changes should be coordinated, and the resources and interests of the specialised areas and IT operations must be taken into account when coordinating the changes (see S 2.426 Integration of patch and change management into the business processes and S 2.427 Co-ordination of change requests).
For quality assurance purposes, to detect errors, and to prevent future errors, every patch and every change should be evaluated upon completion (see S 2.429 Measuring the success of change requests).
Changes, especially software updates, can be performed manually or with the help of suitable tools. When tools are used, it must be ensured that the tools are specially protected to prevent misuse and do not threaten the overall security since they often run with system administrator privileges. Tools also offer the possibility to make changes simultaneously on numerous systems. However, in this way the effects of an error are multiplied accordingly, and therefore careful tests should be conducted before carrying out the change (see S 2.428 Scalability in patch and change management). It is also necessary to note that the systems to be changed may need to be switched off temporarily or permanently or may not be accessible for a while. This applies especially to mobile devices such as laptops, smartphones and PDAs (see S 4.323 Synchronisation within patch and change managements). In addition, the integrity and authenticity of the software installed must be guaranteed technically during the entire patch and change management process (see S 4.177 Assuring the integrity and authenticity of software packages).
The auto-update mechanisms of the software used must be examined regardless of if or how they will be utilised in the patch and change process (see S 4.324 Configuration of auto-update mechanisms in patch and change management).
Disposal
If systems used for patch and change management are taken out of operation, then they should be properly disposed of. More detailed information can be found in S 2.13 Correct disposal of resources requiring protection.
Contingency Planning
The business continuity plans for each application and IT system administered by the patch and change management system must be taken into account in contingency planning (see S 1.3 Contingency Planning). Since patch and change management contributes to the technical implementation of security measures in the organisation, suitable redundant technical systems and replacement systems must be available to counteract the effects of any failure that cannot be compensated for. Furthermore, substitution arrangements are particularly important to ensure the decision-making and approval process is maintained.
Planning and design
| S 2.221 | (A) | Change management |
| S 2.421 | (B) | Planning the patch and change management process |
| S 2.422 | (B) | Handling change requests |
| S 2.423 | (A) | Specification of responsibilities for patch and change management |
| S 2.424 | (A) | Security policy for the use of patch and change management tools |
| S 3.66 | (W) | Basic terminology of patch and change management |
Purchasing
| S 2.62 | (B) | Software acceptance and approval procedure |
| S 2.425 | (C) | Selection of suitable tools for patch and change management |
Implementation
| S 4.65 | (C) | Testing of new hardware and software |
Operation
| S 2.219 | (A) | Continuous documentation of information processing |
| S 2.426 | (C) | Integration of patch and change management into the business processes |
| S 2.427 | (C) | Co-ordination of change requests |
| S 2.428 | (Z) | Scalability in patch and change management |
| S 2.429 | (Z) | Measuring the success of change requests |
| S 4.78 | (A) | Careful modifications of configurations |
| S 4.177 | (B) | Assuring the integrity and authenticity of software packages |
| S 4.323 | (Z) | Synchronisation within patch and change management |
| S 4.324 | (C) | Configuration of auto-update mechanisms in patch and change management |