Changes to information systems such as replacing a network device, creating a new database instance, or upgrading software are often necessary for improved performance, reduced costs, and higher efficiencies.However, those changes to information processing facilities and systems, if not implemented properly, may lead to the compromise of information assets stored in or processed by these facilities.Risks (seen from an information security point of view) arise when changes are performed in an uncontrolled way, i.e., confidentiality, integrity, and availability of systems, applications, information… could easily be endangered.Organisations can establish and apply change management procedures to monitor, review and control changes made to the information processing facilities and systems.Change management which requires that changes to the organization, business processes, information processing facilities, and systems that affect information security are controlled. Change management is a structured process for reviewing proposed IT system or service changes. This process occurs prior to implementing the requested change on an organization’s network, thus minimizing or eliminating network outages. IT change management is necessary to ensure any changes to the network will not degrade the performance of the network. Any changes to the network should be a defined, purposeful action to eliminate a found vulnerability, upgrade a component on the network for improved performance, or replace a currently obsolete or faulty network component. Changes can be categorized into three types:
- Standard Changes: Standard changes are routine, and follow a pre-established process regarding risk analysis and pre-approvals. These changes are vetted processes that have been pre-approved for execution. Examples of standard changes include the following:
- Upgrading RAM or hard drive size
- Replacing a failing network device
- Making a new database instance
- Normal Changes: Normal changes do not have a pre-established process. A risk analysis and deployment plan must be submitted for approval prior to implementing these changes on the IT network. Examples of normal changes include the following:
- Upgrading to a new compliance management system
- Upgrading network devices for improved performance
- Relocating a server farm
- Emergency Changes: Emergency changes are when an unplanned outage has occurred, or is likely to occur, due to a discovered vulnerability that possesses a significant threat to the network. Examples of emergency changes are the following:
- Installing a security patch
- A network device outage
- Recovering from a major incident (i.e. fiber strand cut)
Changes in technology are very frequent, and so are changes that affect our ISMS (not only for the sake of improvements, but also in daily business). But, if we don’t manage them according to a procedure, we might find surprises that can (often) involve an information security incident or an interruption of the business, which can also affect our customers. So, if you manage the changes, I am sure that you can improve your organization, because managing activities in any type of business is the best way to improve it – which also means that controlling the changes decreases the headaches and the costs.
Control
Changes to information processing facilities and information systems should be subject to change management procedures.
Purpose
To preserve information security when executing changes.
ISO 27002 Implementation Guidance
Introduction of new systems and major changes to existing systems should follow agreed rules and a formal process of documentation, specification, testing, quality control and managed implementation. Management responsibilities and procedures should be in place to ensure satisfactory control of all changes. Change control procedures should be documented and enforced to ensure the confidentiality, integrity and availability of information in information processing facilities and information systems, for the entire system development life cycle from the early design stages through all subsequent maintenance efforts. Wherever practicable, change control procedures for ICT infrastructure and software should be integrated. The change control procedures should include:
- planning and assessing the potential impact of changes considering all dependencies;
- authorization of changes;
- communicating changes to relevant interested parties;
- tests and acceptance of tests for the changes (see 8.29);
- implementation of changes including deployment plans;
- emergency and contingency considerations including fall-back procedures;
- maintaining records of changes that include all of the above;
- ensuring that operating documentation (see 5.37) and user procedures are changed as necessary to remain appropriate;
- ensuring that ICT continuity plans and response and recovery procedures are changed as necessary to remain appropriate.
Other information
Inadequate control of changes to information processing facilities and information systems is a common cause of system or security failures. Changes to the production environment, especially when transferring software from development to operational environment, can impact on the integrity and availability of applications. Changing software can impact the production environment and vice versa. Good practice includes the testing of ICT components in an environment segregated from both the production and development environments. This provides a means of having control over new software and allowing additional protection of operational information that is used for testing
purposes. This should include patches, service packs and other updates. Production environment includes operating systems, databases and middle ware platforms. The control should be applied for changes of applications and infrastructures.
Change management processes are essential for ensuring that risks associated with significant revisions to software, systems, and key processes are identified, assessed, and weighed in the context of an approval process. It is critical that information security considerations be included as part of a change review and approval process alongside other objectives such as support and service level management. Change management is a broad subject matter, however, some important considerations from an information security perspective include:
- Helping to ensure that changes are identified and recorded.
- Assessing and reporting on information security risks relevant to proposed changes.
- Helping classify changes according to the overall significance of the change in terms of risk.
- Helping establish or evaluate planning, testing, and “back out” steps for significant changes.
- Helping ensure that change communications is handled in a structured manner.
- Ensure that emergency change processes are well defined, communicated and that security evaluation of these changes is also performed post-change.
All major changes to information systems and the introduction of new systems should be subject to an agreed set of rules and procedures. These changes should be formally specified and documented. Furthermore, they should go through the testing and quality control processes. To ensure that all changes comply with the change control rules and standards, organisations should assign management responsibilities to appropriate management and should set out the necessary procedures.
- Organisations should plan and measure the likely impact of planned changes, taking into account all dependencies.
- Implementing authorisation controls for changes.
- Informing relevant internal and external parties about the planned changes.
- Establishing and implementing testing and acceptance testing processes for changes
- How the changes will be implemented, including how they will be deployed in practice.
- Establishing emergency and contingency plans and procedures. This may also include setting out a fall-back procedure.
- Keeping records of all changes and related activities, including all activities listed above(1 to 6).
- Operating documentation and user procedures are reviewed and updated to reflect the changes.
- ICT continuity plans and recovery and response procedures should be reviewed and revised to reflect the changes.
- Organisations should integrate change control procedures for software and ICT infrastructure to the maximum extent possible.
Changes to the production environments such as operating systems, and databases may compromise the integrity and availability of applications, particularly the transfer of software from development to production environment. Another risk that organisations should be cautious against is changing software in the production environment may have unintended consequences. To prevent these risks, organisations should perform tests on ICT components in an environment isolated from the development and production environments. This will enable organisations to have greater control over new software and will provide an extra layer of protection for real-world data used for testing purposes. This extra protection can be achieved via patches and service packs. Steps to manage change includes:
1. Request for change: Each change can be initiated as a Request – better known as a “Request for Change” or “RFC.” This request will also serve as a record and as evidence that a particular change has been requested. The change can be initiated internally (by an employee) or externally (by a customer), and will be registered in a specific form. Changes may affect assets of the organization (hardware, software, networks, etc.), but can also affect processes, services, agreements, etc. Therefore, it is important that detailed information about the type of change is recorded in the RFC. It is also important to record more information, such as the person requesting the change, the date, the department (or interested party) affected, etc.
2.Approval process: The RFC is received by a person who is responsible for analyzing it, so this person is the first filter. This person is only responsible for studying the details of the request and identifying the potential impact to the business, including economic impacts and impacts related to the information security (e.g., if the change is to upgrade the operating system of a server that is in the production environment – that can be critical for the business). Further on, another person (typically the person responsible for changes, e.g., IT Manager or Change Manager), based on the information generated previously, will decide if the change is approved or rejected. For that decision, it is important to consider all the implications that the change may have, including internal ones (departments, compliance with information security requirements, objectives, etc.) as well as external ones (customers, suppliers, etc.). Finally, if the change is approved, another person (typically appointed for change implementation, e.g., Project Manager) is responsible for planning the change and its implementation. That same person will also plan tests that allow for checking that changes are performed in the correct way. These three persons can be the same person (this may be recommended for small companies), although it is recommended that they are different for bigger companies, because in such way it will be possible to separate roles/functions. Finally, not all the changes are equally important, so it is necessary to classify them (for example: Low, Medium, and High). This classification can be based on the impacts to the business and to the ISMS.
3. Communication: It is also important that the company (for example, through the person responsible for changes) keeps in contact with the person who initiated the change, or interested parties involved in the change (stakeholders, users, customers, public, etc.), because they must be informed of every decision or action that is carried out in relation to the change that is being managed. These communications can be via phone or email (in order to be registered), meetings, etc.
4. Fall-back and emergency changes:Another important issue to consider is when an error takes place during the implementation of the change. In this case, it is important to have a fall-back procedure to return to the previous state. The person responsible for executing the fall-back procedure can be the same person responsible for the change implementation. Finally, this fall-back procedure can be defined during the planning-for-implementation step, establishing what needs to be done to return to the previous stage. For example: the Windows 10 operating system is updated to Windows 11, but one application fails (we can think of this as an information security incident, because we lost the availability of the system), so in this case it will be necessary to return to Windows 10.
Changes to systems within the development lifecycle must be controlled by the use of formal change control procedures. System change control procedures should integrate with, be aligned to and support operational change control. Formal change management procedures are designed to reduce the risk of accidental or deliberate development of vulnerabilities that may allow systems to be compromised once the changes are put live. For system change control, it is important that the system owner understands what changes are being made to their system, why and by whom. It is their responsibility to ensure that their systems are not compromised through poor or malicious development. They should therefore be involved in setting the rules for authorization and pre-live testing and checking. Audit logs are required to provide evidence of the correct use of change procedures. Many aspects of change control that should be included, ranging from simple documentation of the changes through to consideration of the time for deployment to avoid negative business impact.When operating platforms are changed, business-critical applications need to be reviewed and tested to ensure there is no adverse impact on organizational operations or security. When operating system platforms are changed it is commonplace that some applications may have compatibility problems. It is important therefore to test operating system changes in a development or test environment where critical business applications can be checked for compatibility with the changed OS. Procedures for control and testing of operating system changes should follow standard change management control.Modifications to software packages need to be discouraged, limited to necessary changes and all changes should be strictly controlled. Vendor supplied software packages are designed for the mass-market and are not really designed for organizations making their own changes to them. In fact most of the time the ability to make such changes is locked out by the vendor and customization limited to within the package. Where open-source software is used, it is far more likely that changes can be made by the organization, however, this should be restricted and controlled to ensure that the changes made do not have an adverse impact on the internal integrity or security of the software.
Common Challenges
“Change Management Takes Too Much Time.” Change management processes are notoriously susceptible to becoming overly complex. Staff who conduct changes are more likely to attempt to bypass change management processes they feel are too burdensome by intentionally classifying their changes at low levels or even not reporting them. If you are starting a Change Management program it is often helpful to first focus on modelling large-scale changes and then working to find the right change level definitions which help balance risk reduction with operational agility and efficiency.