Lesson 27 of 33
In Progress

Service Management

1                  Introduction

1.1              Purpose

This document describes how services offered by the KPMG Global Security Operations Centre (GSOC) are managed to ensure continued compliance to the GSOC terms of reference and any agreed service level agreements (SLA). It specifies how the resources and capabilities of the GSOC are used to provide value to member firms.

1.2              Scope

This document covers activities performed within the GSOC to introduce new services, enhance existing services as well as managing any capacity changes to the services and resources they depend on.  

1.3              Ownership

The responsibility of ownership and ongoing management of this document, including the processes contained therein, rests primarily with the GSOC Director who will work in coordination with the wider stakeholder community to agree measurable metrics and also gather strategic requirements for continuous improvement.

1.4              Audience

The intended audience for this document is the GSOC Team and third party service providers.

1.5              Exceptions

All requests for exceptions to this processes contained within this document should be directed to the GSOC Director who, depending on the nature and the scope of the request.

1.6              Reporting Violations

Any violations to this policy should be reported directly to the following email address:

<<gsoc-manager@kpmg.com>>

2.1          Responsibilities

The following roles have responsibilities for respective components of the service management process. This list is not intended to provide an extensive list of the responsibilities of each of the roles, but only represent high level responsibilities related to this process.

1.6.1          GSOC Director

The GSOC Director has the overall accountability of all services provided by the GSOC.

1.6.2          Service Manager

The Service Manager role is an assigned role, primarily performed by the GSOC Operations Manager (GOM). The Service Manager has overall responsibility for defining new services and ensuring that services are delivered in accordance with agreed business requirements. They will also lead service definition, reviews and manage the service lifecycle. Service Manager’s activities include:

2.1.1       GSOC Operations Manager (GOM)

The GSOC Operations Manager serve as the service manager. They may delegate responsibility for specific services to other members of the GSOC.

1.6.3          Service Team

Service team is a virtual team that is stood up to facilitate the management of services within the GSOC. Service teams comprise of personnel that are responsible for Service Delivery and also need to be consulted on service changes, development and retirement.

The Service Team includes GSOC personnel, service providers, service support, subject matter experts and occasionally the representatives of the Member Firm. Depending upon the service, some members may participate on an “on-call” or as needed basis.

The duties of the Service Team include, but are not limited to, the following:

2.2          Upstream (Dependent) Processes

2.3          Downstream (Affected) Processes

2                  Service Management Process

The Service Management Process will continuously evolve overtime to ensure its relevance and currency as the GSOC builds out its capability to respond to the ever changing threat landscape, e.g. the ability to interface to wider range of platforms.

2.1              Process Overview

Service Management refers to the entirety of activities – directed by policies, organized and structured in processes and supporting procedures – that are performed by the GSOC to plan, deliver, operate and control services offered by the GSOC.

The process is focused towards maintaining the agreed optimum service levels and also perform enhancements as part of continuous improvement. This process is in line with ITIL version 3.

Services are managed throughout their lifecycle to ensure that they continue to operate in accordance with the terms of reference. An overview of the lifecycle of a service is shown below and defined in the subsequent sections:

2.2              Service Strategy

2.2.1          Strategies

The strategies for each service must be defined to align with the objectives of the GSOC as specified in the terms of reference. The strategies will be defined in relation to the:

2.2.2          Policies and Processes

The GSOC service management is governed by KPMG International and UK’s policies. Processes have been defined to capture the activities performed staff within the GSOC achieve the desired functionality of the GSOC while adhering to the policies.

2.2.3          Service Specification

GSOC services are defined following the format adopted by existing services in the Service Catalogue. A new service specification could be initiated through a request received from member firms or started as part of the GSOC’s plans for continued service improvement. A service request received may only provide limited information related to the requirements for the service and therefore further analysis will be performed to extract relevant information to include in the service definition. Other sources of information to include in the service definition structure will include, but not limited to:

2.2.4          Service Management Planning

Service management planning will be carried out to determine the current and future requirements of the services. This will enable any anticipated resources requirements to be planned for and thus avoiding service failure or disruption.

The GSOC Operations Manager will coordinate service management planning with key stakeholders including the Global CISO, member firm representatives and SMEs.

Service management planning will be achieved through a set of planned meetings as follows:

2.2.4.1         Quarterly Meetings

The Service Manager will meet with the Service Team and to discuss, among other things, the following agenda:

2.2.4.2         Annual Meetings

Annual meetings will be scheduled to discuss, among other things, the following additional agenda:

2.2.5          Activities, Inputs and Output

The diagram below illustrates some of the activities that will be performed as part of capacity planning together with some possible inputs and outputs.

2.3              Service Design

Service design involves determining the best options available to provide the functional requirements for the new service using the resources and capabilities available or accessible to the GSOC. Within the GSOC, Service Design will follow the ITIL V3 Service Design process, which is summarised in the diagram below.

2.3.1          Service Capacity Management

In order to ensure that the GSOC continues to operate effectively the capacity of its resources must be managed to ensure that new services can be accommodated and to plan for any anticipated capacity changes.

2.3.1.1         Defining Baseline Capacity (1.0)

Baseline capacity captures the recorded resources necessary to keep the GSOC functioning to the minimum level of service. This takes into account the requirements of the minimum set of services that the GSOC is expected to deliver at one time. Therefore, the baseline capacity should be updated whenever there are changes to the minimum set of services.

2.3.1.2         Documenting existing capacity (2.0)

The existing capacity of the GSOC is documented to develop a view of the state of the GSOC. This documentation complements the inventory of the assets within the GSOC and feeds into any capacity planning exercises.

The GSOC will initially (i.e. during the build phase) and continually determine whether the existing capacity meets the baseline capacity. If not, then then a capacity improvement plan will be created and a change request initiated.

2.3.1.3         Monitoring capacity (3.0)

The capacity of the resources within the GSOC will be monitored. Automated mechanisms shall be utilised to detect whether the capacity is exceeding defined thresholds. This monitoring will not only focus on raising alarms when the thresholds are exceeded but will also monitor the rate of change and predict when the threshold will be reached.

When the overutilization thresholds are exceeded, the ITS Global Incident Management Process will be invoked. The priority of the incident will be determined based on whether it is the lower or upper threshold that has been exceeded.

Resources whose utilisation consistently falls below the underutilization threshold will noted and included in the next session of capacity management reviews.

2.3.1.4         Thresholds

Every resource (people and technology) within the GSOC have a maximum capacity to handle the task or provide the functionality required within the GSOC. Exceeding this capacity may affect the GSOC’s ability to provide its services. For this reason, the level to which the resources are utilised should be captured and thresholds, which call for action if exceeded, must be defined.

Thresholds are defined in terms of the percentage of utilization. These are provided in the table below.

Threshold type DescriptionThreshold value (% of utilization)
UnderutilizationThe level indicating that the resource in question is underutilized.10
Lower overutilizationThe level at which an amber warning must be raised75
Upper overutilizationThe level at which a red alarm must be raised85

The thresholds are not measured as instantaneous values because spikes in utilization are anticipated. Instead they define consistently over the threshold for a given time period.

2.3.1.5         Preparing capacity plans (4.0)

A Capacity Plan will be created. This plan will include a business case for the required capacity, assumptions as well as details about the capacity being sought. As assessment will be performed as part of the plan to identify current as well as anticipated capacity requirements.

2.3.1.6         Exception management

All exceptions that cannot fit into capacity plans or that breach the defined thresholds will go through a risk assessment as defined in the GSOC Risk Management Process.

  Record for next review session (5.0)

A record will be made where the underutilization threshold is consistently breached and an action plan included in the next capacity management review session.

2.3.1.7         Approving capacity plans (6.0)

The GOM will approve all capacity improvement plans and approve the budgets necessary to implement plan.

2.3.1.8         Executing the Capacity Plan (7.0)

Once the Capacity Plan has been approved, it will be executed. The execution will involve triggering other processes such as ITS Global Change Management Process, GSOC Content Management Process and Continual Service Improvement Process.

  Requests for increased capacity (8.0 and 9.0)

Service requests that require changes to the capacity of the GSOC will be evaluated to determine whether the current capacity of the GSOC can handle the request. A business case will also be established before including the request into the capacity improvement plans.

2.4              Service Transition

Service transition involves moving a new or updated service from the design phase into operation. However, since any new service or update to an existing one will result in changes to the GSOC environment, service transition must be managed to minimize the risks of failure and disruption.

The goals of service transition include, but are not limited to, the following:

Service transition will include the following steps:

2.4.1          Knowledge management

As part of transition to a new service any knowledge collected within the GSOC and from external sources will be managed to ensure that GSOC staff have a sound and shared understanding of the situation, the options, consequences and benefits.

2.4.2          Risk Management

All risk assessments during service transition will be handled through the GSOC Risk Management Process.

2.4.3          Change and release management

All changes to GSOC services will be handled through the GSOC Change Management Process. Release Management will be handled by the GSOC following the ITS Global Change and Release Management Process.

2.4.4          Service configuration management

Service configuration management ensures that the integrity of service assets and configurations is maintained throughout the lifecycle of a service.

The configuration of services as well as assets that enable the service to be provided will be managed through the ITS Global Change Management Process.

2.4.5          Service validation and testing

The goal of service validation and testing is to assure that a service will provide value to the GSOC and its customers. All tests performed during service transition will be handled through the GSOC Test Management Process.

2.4.6          Phased Roll out

A phased roll out approach will be adopted for new changes. Enhancements to services may also follow this approach depending on the type of enhancements and the risks associated with the change. This approach will follow the following steps:

2.5              Service Operation

Service operation includes all the activities that are performed to achieve effectiveness and efficiency in the delivery and support of services so as to ensure value for the customer and the GSOC.

2.5.1          Service Request Management

Requests for new services as well as enhancements to existing services are managed through the Service Request Management Process illustrated in the figure, and described, below.

  Initiate service request (1.0)

The service requestor creates a service requestor and sends it to the Service Manager. Requests coming from outside the GSOC will be communicated through the GSOC Service Desk or via the GSOC Communication Process.

  Documenting service requests

A record that holds any management-relevant information and history of a specific request is created for each service request. This record will include, but not limited to, the following information:

Field Description
Unique identifier Service Request ID (ticket id)
Ticket OwnerPerson registering and accepting the request
Ticket AgentAssigned person currently working on that request
Service Request proposerName of the Person triggering the Service Request
StatusStatus of the request. Is set when passing a Control Activity
ServicesService(s) affected by this request
Member FirmsMember Firm(s) affected by this request
UsersUser(s) affected by this request
DescriptionThe description of the service request including the Change Argument
Resolution TimeThe resolution time depends on the priority of the request
Times Request receivedThe time when the request was received
Times Request forwardedForward-history is saved to the record
Request Working MinutesTime spend actually working on that request
Solution DescriptionThe description of handling the request
Closing CommentAdditional Information to the closing activity
Additional RemarksText for additional information

  Service request classification

It is anticipated that the GSOC will receive a number of service requests. Service requests will be classified based on business impact to GSOC. Classification will be a continual process, until the request is fulfilled and will determine how the request is prioritised over other requests.

  Service request status

The following table specify the various statuses that each service request might be in at any particular time.

StatusDescription
NewThe Service Request Management Process is triggered. The record is created and is given a unique identifier.
RegisteredThe information of the Request was added to the record. Every mandatory filed was completed.
ClassifiedThe request was classified. Every control factor was defined.
AssignedThe request was forwarded to another member of the GSOC team. The reason for forwarding the request is recorded.
AbortedThe request was aborted.
Request fulfilledThe request was fulfilled from the GSOC’s point of view.
Closed/EndedThe request was successfully fulfilled from the Requestor’s and the GSOC’s point of view.

2.5.1.1         Types of service requests

The following types of service requests will be handled in this process:

If the request concerns access to one or more existing services then the GSOC IAM Process will be invoked. Requests for new services will proceed with the specification of the new service while enhancements will proceed with the specification of the enhancements required on one or more existing services.

2.5.1.2         Service specification (2.0/3.0)

The service team determines whether the requestor is documented appropriately and then creates a service specification in accordance with the Service Catalogue. Enhancements to existing services will be specified as amendments to the existing service specification.

2.5.1.3         Business case for service requests

Service requests will only be implemented upon determining that the business case for the service request is valid. This decision will be made by the Service Manager and will involve back and forth discussion with the service requestor to determine the motivation for the request and whether an alternative already exists. Key inputs into the decision making process will include, but not limited to:

Where the financial incentives of adding a new or updating an existing service outweighs the risk of breaching the threshold the Service Manager will bear the responsibility of deciding whether to go ahead with the service request or not.

Once the business case for the request has been evaluated, the risks associated with the implementation of the request will be evaluated using the GSOC Risk Management Process.

2.5.1.4         Service capacity requirements (4.0)

Each new service introduced into the GSOC may place additional strain on the capacity of the infrastructure as well as on human resources within the GSOC. These must be identified and planned for accordingly. Once the capacity requirements have been identified, an assessment must be performed to determine whether the existing GSOC capacity can handle the new service. If the capacity of the GSOC is found to be inadequate, the GSOC Capacity Management Process is triggered to address the requirements.

2.5.1.5         Approving the service request (5.0)

If the GSOC capacity is adequate, then the service request is sent to the GOM for approval. Once the service request has been approved, the design process is triggered to design and implement the service.

2.5.1.6         Reporting to the requestor (6.0)

Once the service requestor moves into the design phase, the service requestor will be informed and kept up to date during the design phase using the GSOC Communication and Reporting processes.

2.5.2          Problem Management

All problems associated with GSOC services shall be handled through the ITS Global Problem Management Process.

2.5.3          Capacity Monitoring

The resources used by a particular service will be monitored to determine whether the usage is within the thresholds, as defined in Service Capacity Management, Section 3.4.5.

2.5.4          Service Maintenance

Service maintenance involves monitoring the operation of a service and the supporting infrastructure to identify areas of the service needing an update. All maintenance activities will be processed through the ITS Global Change Management Process.

To facilitate service maintenance and continual service improvement, the operation of the GSOC services will be monitored to collect KPI and metrics that will be used in determining the maintenance activities and improvements necessary on the services.

2.5.5          Service Desk

The GSOC service desk will be operated in accordance with the GSOC Service Desk Management Process.

2.5.6          Service Status and Outage Notification

The status of GSOC services, and any outages, will be communicated to relevant stakeholders using the GSOC Reporting and Communication processes.

2.6              Continual Service Improvement

Continual Service Improvement (CSI) defines techniques and activities performed within the GSOC to monitor and determine the effectiveness, efficiency and economy of the GSOC service and ensure that improvements are identified and implemented. This process follows the ITIL V3 process, the details of which are included below.

2.6.1          Objectives for CSI

The objectives of the CSI include:

2.6.2          CSI Inputs

The following diagram illustrates the interactions between the CSI process and other GSOC processes.

The information in each of the interfaces is described in the table below.

ProcessInterfaceInformation
IT Incident ManagementA
ITS Global Problem ManagementB
ITS Global Change ManagementC
GSOC Capacity ManagementD
GSOC Service Desk ManagementE
Service Level MonitoringF
GSOC Vulnerability ManagementG
GSOC Shift ManagementH
GSOC Financial TrackerI
GSOC Security Incident Management ProcessJ
GSOC CSI RegisterK
L
GSOC Risk Management ProcessM

The GSOC will align with ITS Global strategy to ensure that all planned changes are tracked and any improvement opportunities must be identified. The GSOC CSI Register [3] is a repository in which improvement opportunities are recorded and managed in order to provide a co-ordinated, consistent view of improvement activities.

2.6.3          Improvement Lifecycle

The CSI process follows a simplified ITIL V3 lifecycle as follows:

2.6.3.1         Define KPIs/KPXs

The KPIs/KPXs that will drive service improvement are included in the Reporting GSOC Metrics and KPIs [2]. New KPIs and KPXs identified through service design, transition or operation should be added to this document upon approval by the GOM.

2.6.3.2         Monitor service and gather Metrics and feedback

The Metrics that will be used to identify areas of improvement will be collected during service operation from client feedback, GSOC processes and technology as specified in the Reporting GSOC Metrics and KPIs [2].

2.6.3.3         Process the data

The data collected through the various mechanisms including feedback from member firms and performance of the services should be processed to ensure that it is

2.6.3.4         Analyse the data

The processed data will be analysed to:

2.6.3.5         Identify improvement opportunities

The analysis described above will result in the identification of overall gaps in the GSOC service. Improvement opportunities should be determined by considering the following:

Once the opportunities have been identified and documented, they should be sent to the GOM for approval.

2.6.3.6         Implement improvements

Improvements to the GSOC service will be aligned with the tactical and strategic goals of the GSOC. The implementation of improvement opportunities will be achieved through one or more GSOC processes as indicated below:

Improvement areaActivity typeProcess
GSOC Process  EnhancementGSOC Service Management Process  
Design
GSOC Service EnhancementGSOC Service Management Process
Scope expansion
Service retirement
Reduce false positivesGSOC Content Management Process and GSOC Threat Intelligence Management Process, GSOC Detection Optimisation Process
TechnologyIntroduce new technologyITS Global Change Management Process  
Upgrade
PeopleResourceGSOC Shift Management Process
UpskillingGSOC Career Management Process

2.6.4          Reviewing the GSOC CSI Register

The Service Team will review the GSOC CSI Register on a quarterly basis to determine quick wins and ensure that all improvement opportunities are addressed.

2.7              Service Retirement (Phase-out)

Services that have been identified as obsolete or no longer having a valid business case will be retired from the GSOC in accordance with the following process.

All services within the GSOC will be reviewed on an annual basis as part of Service Management Planning as defined in Section 3.5.4.

2.7.1.1         Initiation of service retirement (1.0a and 1.0b)

Requests for retiring services within the GSOC will be initiated either through periodic review of services as part of service management planning or through requests coming in from customers.

2.7.1.2         Evaluate service efficiency (2.0)

Services that are subject to retirement will be evaluated to determine whether the associated metrics support the case for retirement. This will be used to determine whether a business case for retiring the service is valid.

A risk assessment will be performed in accordance with the GSOC Risk Management Process to determine if the risk of retiring the service is acceptable.

2.7.1.3         Preparing the business case (3.0)

Using information from the risk assessment and the evaluation of the efficiency of the service in question, the service team will create a business case for retiring the service and send to the GOM for approval.

2.7.1.4         Approving the business case (4.0)

The GOM will approve or disapprove the request based on whether the business case for retirement is valid and the risks associated with fulfilling this request.

2.7.1.5         Continuing with operation (5.0)

If the business for retirement is not approved, then the Service Team will determine whether the request could be served as part of continual service improvement. If so, then Continual Service Improvement will be triggered. Otherwise the operation of the service will continue and the request will be closed.

2.7.1.6         Creating the phase-out plan (6.0)

A plan detailing how the service will be retired together with timelines and resources needed will be developed.

2.7.1.7         Approval for Retirement (7.0)

The GOM will determine whether or not to approve the phase-out plan.

2.7.1.8         Executing the Service Phase-out Plan (8.0)

Once the phase-out plan has been approved, the plan will be executed. This may include communicating with member firms to off-board them from the service, modifying the GSOC processes to reflect the change and changing the configurations of some of the resources within the GSOC. Any changes included in the plan will be managed through the GSOC Change Management Process.

2.7.1.9         Updating the service catalogue

The service catalogue must be updated to reflect the changes made to the GSOC services.

3                  References

  1. Capacity Plan
  2. Reporting GSOC Metrics and KPIs
  3. GSOC CSI Register