Change Management Process
Changes are inevitable in any environment. Within the KPMG Global Security Operations Centre (GSOC), changes will be required on the supporting infrastructure as well as on the services provided by the GSOC. These changes need to be planned for and managed in order to minimise incidents brought about by changes to the GSOC environment.
This document provides details about how GSOC will interact with Global’s change management process.
The GSOC will receive change requests that may affect different components within its ecosystem as well as external to the GSOC. This document covers changes that affect the IT components and associated processes including software, hardware, network and configurations as well as content driving the GSOC services. It also covers changes to processes within the GSOC.
This document is ultimately owned by the GSOC Director. The responsibility of ongoing management of this document, including the processes contained therein, rests with the GSOC Director.
This document is intended for all GSOC members. (Section 2.7 – Responsibilities).
Exceptions to this process can be temporarily authorized by the GSOC Director or GSOC Operations Manager.
Failure to adhere to this process must be reported to the GSOC Director.
The following roles have overall responsibility for elements of this process. Please note that these are not comprehensive listing of responsibilities of each of the following roles, but represent these roles’ specific responsibilities to support the Change Management Process. The roles have been aligned with ITS Global’s roles, but modified to accommodate GSOC’s staffing model.
The Tooling Engineer will act as the implementer for tooling changes that are within the scope of the GSOC.
1.7.2 GSOC Director
The GSOC Director has overall responsibility for and authority over the Change Management Process. They are directly responsible for ensuring that change management procedures are followed, and ensuring that there is adequate staffing to meet the requirements of this Change Management Process.
1.7.3 GSOC Operations Manager
The GSOC Operations Manager will support the GSOC Director in ensuring that the changes to the GSOC are carefully planned and approved before being implemented. They will also coordinate the resources necessary to implement a change.
The GSOC Operations Manager has the responsibility to approve or reject a change request before it can be scheduled. The approval may be based on business need, priority, cost/benefit, and potential impacts to other systems or processes. They can make recommendations for implementation, further analysis, deferment, or cancellation.
Members of the GSOC can initiate requests for change, coordinate approvals for the change requests as well as implement the changes. They will work actively on the change and in collaboration with the Change Requester and/or Implementer, planning and implementing assigned changes, or coordinating the efforts of other groups or individuals.
The GSOC will work closely with ITS Global on the implementation of changes. ITS Global owns the Global Service Desk.
GSOC is adopting a change hierarchy for change approvers depending on the risk level and impact of the change. Please refer to Appendix 1.
The Change Authority Board (CAB) is a standing body of GSOC members consisting of the GSOC Operations Manager, L3 Analyst and Content Engineer. Their combined approval is required in order to be considered a CAB approval. Please refer to Appendix 1 for the changes they are expected to approve.
- ITS Support Process (UK and Global)
- Content Management Process
- Business Continuity/Recovery Plan
- Continuous Improvement Process
- Service Management Process
- SECOPS Customisation Process
- Every process and policy at KPMG UK and International
- Risk Management Process
- Test Management Process
- All GSOC processes
- Document Management System
The goals of this process are to:
The workflow for change management within the GSOC is shown below.
The change process will require a sufficient level of detail to be captured before it can be assessed by the relevant approvers. The following processes will describe the various steps from initiation to approval, implementation and closure of a change.
This change management process will be invoked upon a request for a change to GSOC. This step initiates the change and captures basic details which will be elaborated upon further down the process. The following are some, but not limited to, scenarios that could trigger change management. The change initiator could be outside the GSOC.
For all GSOC initiated changes, the following information shall be gathered before initiation.
It is important to note that although the responsibility to implement lies with ITS Global, all GSOC retains governance over all GSOC initiated changes and shall be held accountable for the outcome of the change. This will include but not limited to:
Depending on the type of change initiated, different Global processes will be triggered.
2.3.3 Review Changes
Before tickets can be closed, the completed changes shall be reviewed to confirm that everything is working as intended.
The changes deployed to the Production environments will synchronised onto QA as defined in Section 3.5.
2.4 Synchronising Production and QA Environments
The QA environment must be kept current to ensure that tests carried out within QA are relevant. As it takes approximately a day to synchronise Production and QA, the following mechanisms can be considered depending on the number of changes scheduled:
Overarching principles on top of above:
- 4) shall be applied.
Change that are likely to affect any of the GSOC services will be communicated to affected stakeholders using the GSOC Communication Process. This will be done ahead of time in the case of standard or routine changes, and as scheduled in the change implementation plan. For emergencies changes, the GSOC has the authority to implement the change and communicate the outages, if any, afterwards to affected stakeholders.
As the GSOC matures, multiple versions of the same software might be created. Bugs or features of the software are often only present in certain versions (because of the fixing of some problems and the introduction of others as GSOC develops). Therefore, for the purposes of locating and fixing bugs, or reverting to a known state, it is vitally important to be able to retrieve and run different versions of the software.
This section will cover the following components:
- RSA Security Analytics
- RSA SECOPS
Refer to ITS UK Configuration Management document for all other components.
This section will not cover the technical aspects of how configurations are extracted from the components, or the actual configurations of the components.
The positioning of the numbers below be, “A.B.C.D”. Configuration Versioning for each component shall be as follow:
- For each Routine Change, the number in position D shall be increased.
- For each Standard or Emergency Change, the number in position C shall be increased, and number in position D reset to 0.
- For the version created each month as a result of Section 4.4, the number in position B shall be the same as the month. The number in position C and D shall be reset to 0.
- Annually, the number in position A shall be increased, B reset to 1, C and D reset to 0.
On the first day of each month, the current configurations maintained on file shall be refreshed. At time of writing on 20th March 2015, the GSOC does not have any versioning control systems in place. As such, all configurations shall be versioned manually in accordance to Section 4.3, and stored on SharePoint. Access controls shall be implemented on the files to prevent unauthorised modifications.
Refer to backup plans on how redundancy will be maintained for these files.