S 2.422 Handling change requests

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Change Manager

The requests for patches and changes should be submitted and processed according to the specified procedure.

Submitting and recording requests for change

First, all requests for change must be recorded. For all required information to be present, it is recommendable to provide the applicants with a form (see template of a request for change from the Resources for IT-Grundschutz).

This application is also designed for coordinating the change (see also: S 2.427 Coordination of change requests). For example, if a change was requested in order to resolve an existing problem, the request should also contain a corresponding reference to the problem, usually a recording number in a database.

Not every request for change is handled as a normal change within the patch and change process. Some clearly described routine changes that are performed in a standardised manner and nevertheless refer to a change can be handled similarly to a service request. For example, a service request would include the process of resetting a password and, in relation to patch and change management, a change to the login banner of a service (the text the services uses to answer when a connection is established via the network interface).

Filtering and accepting requests for change

After a request for change has been recorded, it is checked by the Change Manager. In so doing, requests for change that cannot be performed, are unnecessary, or were received in duplicate are to be determined. Such requests should be rejected, stating the reason. This way, the applicants are provided with the option of reconsidering and reformulating the request for change.

Once a request for change has been accepted, the information is entered into a change dataset in order to perform the change. The dataset can be captured in a software tool, on paper, or even in a specifically created database. During the further procedure, the change dataset is complemented by the following information:

• determined priority and category,
• assessment of the effects and the required resources,
• recommendations of the Change Manager and/or the Change Advisory Board (CAB),
• date and time of authorisation,
• planned date of implementation of the change,
• current date and current time of the change,
• date of evaluation,
• test results and problems that occurred,
• reasoning for a possible rejection of the suggestion and/or request, and
• schedule and analysis data.

Classifying requests for change (priority and category)

Once a request for change has been accepted, it must be prioritised and categorised:

• The priority describes the importance of a change and is derived from the urgency and the effects. If it is a question of correcting a known error that was already classified within the framework of patch and change management, the priority may also be provided. Here, the priority of the change should always be checked and, if required, corrected by the Change Manager, however. The same is applicable to security patches or updates requested by information security. However, the final priority is defined within change management taking into consideration the other requests for change currently being processed.
• The Change Manager determines the category on the basis of the effects to be expected and the required resources.

The classification consisting of priority and category defines the way the request for change is processed further and therefore describes the importance of the planned change.

Priorities are assigned to a change by the Change Manager and are divided into different priority levels, whereby the security management should be granted a power to veto a priority that is too low and/or an incorrect priority. For example, the following priority levels can be assigned by the Change Manager:

• Highest priority:
  A request for change with the highest priority refers to a problem causing significant difficulties for the target group within the framework of using important IT services, for example. Urgently required adaptations of the IT (e.g. in order to close a security gap a worm is available for on the internet) are assigned this priority. Changes to this priority are also called "Urgent Changes". The difference between these changes and the high or normal priority changes is that the required resources should be made available immediately in this case. An emergency meeting of the CAB or the information security team may also be necessary. If changes are classified in this priority, all former plans may be delayed or suspended for the time being.
• High priority:
  For example, this priority describes a change based on a severe malfunction or is connected to other urgent activities. This change is the top priority during the next meeting of the CAB regarding the assignment of resources for testing and implementation.
• Normal priority:
  A normal priority change is not characterised by any particular urgency or major effects, but must not be postponed to a later point in time. In the CAB, this change is assigned normal priority when assigning the resources.
• Low priority:
  A low priority change is desired, but does not have to be dealt with until the appropriate situation occurs (e.g. a successor version or scheduled maintenance).

Categories are normally assigned by the Change Manager, whereby the security management team should also be provided with a power to veto a categorisation that is too low. Categories are intended to provide an assessment as to the effects of the change and the strain on the organisation caused by the change process. For example, the following categories may be assigned:

• Minor consequences:
  A change in this category requires little effort. The Change Manager may approve this kind of changes without having to present the changes to the CAB.
• Significant consequences:
  This category includes changes requiring considerable efforts and having wide-ranging effects on the IT services. Such changes are discussed within the CAP in order to define the required efforts and to minimise the risk. In advance and in preparation of the meeting, the members of the CAB, and possibly some IT experts and developers are initially provided with the required documentation.
• Wide-ranging consequences:
  A change in this category requires huge effort. For such a change, the Change Manager initially requires the authorisation of the security management team. Then, the change must be presented additionally to the CAB for assessment and further planning.

Planning

The employees involved in the patch and change management process plan the implementation for all accepted changes. If required, this is performed in cooperation with the CAB. At this point of the patch and change management process, it is important to take into consideration the required technical and personnel resources and to assess the effects on operations while the change is being performed. The following aspects should be considered at a minimum:

• availability of the IT systems affected,
• reliability and recoverability of the IT services affected,
• planning of business continuity management for the IT services affected,
• blackout plans, i.e. business continuity plans, for the reaction regarding undesired effects caused by the change,
• data backup procedures,
• possible effects of the changes on other IT services (side effects),
• required technical and personnel resources and the related costs,
• required permits such as
• financial permits if, for example,
  • a fee-based update must be installed or the product must be replaced by a successor product (upgrade).
  • technical permits such as additional IT systems must be procured.
  • commercial permits such as the update have effects on the suppliers.
• number and availability of the required IT experts,
• desired implementation schedule for a change,
• consequences for using the IT services and adaptations to Service Level Agreements resulting thereof,
• possible conflicts with other changes.

Review questions:

• Is there a defined procedure describing how requests for patches and changes are submitted and processed?
• Are all requests for changes (RFCs) recorded and documented?
• Does the Change Manager check the recorded requests for change?
• Is every request for change prioritised and categorised?
• Are the resources required for the respective priorities made available?