Lesson 18 of 33
In Progress

Escalation Process

1                  Introduction

1.1              Purpose

This document describes the procedures that the KPMG Global SOC (GSOC) and its Member Firms will follow to manage Security Incidents and escalate issues or matters of evident concern identified through monitoring and/or internal and external sources of information.

1.2              Scope

This document covers the Security Incident Response and Escalation process within the KPMG GSOC ecosystem and the Member Firms on-boarded to the GSOC.

1.3              Ownership

The responsibility of ownership and ongoing management of this document, including the processes contained therein, rests with the Head of GSOC.

1.4              Audience

The intended audience for this document is the GSOC Team and the Security Teams at corresponding Member Firms. The document may also be viewed by the concerned IPBR personnel and the KPMG Global and Member Firms management that are responsible for and/or have established interest in this area.

1.5              Change Management Cycle

This document must be reviewed periodically to comply with the relevant processes as mapped out within the Document Management Process.

1.6              Exceptions

All requests for exceptions to this processes contained within this document should be directed to the Head of GSOC who, depending on the nature and the scope of the request, may liaise with the wider Security Management Team / Security Board to authorize or reject the request. Any such exceptions should be deemed valid only if granted in writing (e.g. communicated via email) and are valid for a period of 1 year only when they will automatically expire unless extended or renewed in the interim.

1.7              Reporting Violations

Not applicable to this process.

1.8              Key Definitions

Following standardised definitions are provided for the key terms used within this document to ensure consistent and appropriate use throughout the KPMG GSOC space, including liaison with the Member Firms. Please note, these definitions may have to be utilized contextually within this document and may not constitute exact phrases.

1.8.1          Escalation

Increasing the visibility and the management control, of a Security Incident or a Security Incident related request.

1.8.2          Handover

The term Handover is used to refer to Security Incidents, Security Incident related requests or information handed over and/or provided (may or may not include Threat Intelligence) to the Member Firms.

2                  Escalation Process

2.1              Process Overview

Escalation management is an exception handling process, and therefore is not considered as a routine part of other processes. This document aims to serve as a reference for both KPMG GSOC and Member Firms analysts for triggering the Escalation process under specific scenarios, samples of which are documented within this document. These scenarios make it permissible for any member of the GSOC or Member Firm’s security team to invoke the Escalation Process and request additional attention and support.

The following references are provided for further disambiguation by listing out the standard scenarios that are not covered by the Escalation Process:

  • The process of validating and escalating high priority Security Incidents is covered within the Triage Process
  • The process of raising Security Incidents to Member Firms is covered within the Security Incident Management Process
  • The process of validating and escalating IT incidents is covered within the IT Incident Management Process

2.2              Scope

From a Security Incident perspective, the scope of the Escalation Process include the Security Incidents identified by the KPMG GSOC directly through their monitoring function or having become aware of similar situations based on information provided by and/or gathered from external sources.

The scope of escalations covered under this process guide include escalations within the KPMG GSOC setup, e.g. L1 to L2, termed as Internal Escalations and also the escalations between KPMG GSOC and Member Firms, termed as External Escalations. These two types of escalations cannot be considered to be mutually exclusive and an internal escalation may or may not occur in synchronicity with external escalations and vice versa.

KPMG Member Firms define their Incident Response processes independently to suit their individual needs. The process defined in this document may require Member Firms to make some adjustments to their internal Security Incident Handling processes – to the extent of the interface touch points and corresponding sub-processes such as Security Incident handover, Security Incident assignment, support requests, information requests, etc.

2.3              Responsibility and Authority

The responsibility and authority for escalation is divided between the Internal Escalation and the External Escalation function of the KPMG GSOC.

2.3.1          Internal Escalation

The Internal Escalation function will have more leverage and flexibility supported by established automated communication lines. The GSOC resources are aligned within the same organisational spectrum (KPMG GSOC) with high tendency for team coherence. The internal escalations can be triggered by any GSOC role including Level 1, Level 2, Shift Lead, GSOC Operations Manager, Head of GSOC, Threat Analyst, etc. Head of GSOC is to be notified for all escalation requests. CISO and Privacy Liaison Officer will be notified for all P2 or higher priority incidents.

2.3.2          External Escalation

The External Escalation primarily relies on the pre-agreed modes of communications and interfaces to exchange information between the KPMG GSOC and the corresponding Member Firms, as described in the Communications process.

External escalations follow a bi-directional workflow with majority of the time the KPMG GSOC initiating the process to hand over issues and/or remediation task(s) however under certain circumstances the escalation request can originate from the Member Firm towards the GSOC, e.g. against a long pending request for information and/or assistance.

The External Escalation function from KPMG GSOC to the Member Firm will follow a pre-determined approval process classified based on the Security Incident Priority Level.

2.3.3          Exceptional Circumstances

In cases where the GSOC is contacted by the Police, GSOC Partners (Threat Intel Provider, Government, etc.) or HR about a Security Incident or a malicious personnel, all such matters will be recorded as a ticket within RSA Archer SecOps and handed over to the KPMG GSOC Unexpected Security Incidents committee.

2.4              Roles

The following roles within the KPMG GSOC have responsibility for elements of this process.  Please note that these are not comprehensive listing of responsibilities of each of the following roles, but only represent high level role specific responsibilities to support the Escalation Process.

2.4.1          Head of GSOC

The Head of GSOC is ultimately responsible for the proper implementation of the Escalation Process and to ensure that supporting processes continue to remain healthy and relevant.  Head of GSOC is responsible to ensure low priority elements are run without much supervision and escalations are invoked only in the case of high priority tickets or matters of evident concern related to security.

2.4.2          GSOC Operations Manager

The GSOC Operations Manager primarily acts a conduit between the GSOC Analysts and the Head of GSOC. His responsibilities include taking ownership of all internal escalations and ensure external escalations are validated and prioritised correctly.

2.4.3          GSOC L1 Analyst

The GSOC L1 Analyst is one of the primary user of the internal Escalation Process.  SOC L1 Analysts will escalate all such Security Incidents to KPMG GSOC L2 Analysts which were being investigated as low priority but turned out to be of higher importance.

This should not be confused with the standard Triage Process where the L1 Analyst will triage and handover all low priority Security Incidents via pre-established automated or non-automated interfaces to corresponding Member Firms.

SOC L1 Analysts are instrumental in ensuring that the Escalation Process is running as per the guidelines and provide recommendations for improvement as appropriate.

2.4.4          GSOC L2 Analyst

The GSOC L2 Analyst is the second primary user of the Escalation Process.  They will review the L1 escalated requests for false positives and may request further information from L1 before deciding to escalate or de-escalate the Security Incident. Once validated and found to be true, the GSOC L2 Analyst will escalate all qualified high priority Security Incidents or Security Incidents requiring further analysis to the corresponding Member Firm(s).

The GSOC L2 Analysts are equally instrumental in ensuring that the Escalation Process is running as per the guidelines and provide recommendations for improvements to the process if applicable.

2.4.5          GSOC Tooling Engineer

The GSOC Tooling Engineer will ensure that the Security Incident detection content will maximize the value of automation to accurately prioritize Security Incidents prior to the triage process.  This will include the inclusion of threat intelligence indicators and internal device information (e.g., active directory identities, VIP lists, etc.) into detection and prioritization content.  They will also ensure that information about false positives identified by Analysts during and after the triage process is incorporated into the updated content rules.

Any escalations from their part, while rare, will be primarily routed through the GSOC Operations Manager. An example at this level include the escalation scenario where the Content Analyst is finding it challenging to ensure the Member Firm provides the relevant data after one request and one follow-up.

2.4.6          GSOC Threat Analyst

The GSOC Threat Analyst will ensure that continuously updated threat intelligence (e.g., indicator lists) is provided to support GSOC Tooling Engineer-designed automation.  The GSOC Threat Analyst will also provide internal GSOC intelligence notes as needed to support the triage process. Any escalations from their part, while rare, will be primarily routed through the GSOC Operations Manager.

An example at this level include the escalation scenario where the Threat Analyst uncovers a possible threat which requires support from the Member Firms but find it challenging to ensure the Member Firm provides the relevant response after one request and one follow-up.

2.5              GSOC Internal Escalation

This section provides guidance on the escalation criteria and the corresponding mechanism for the different types of escalations expected typical within the KPMG GSOC. The factors include consideration for sample cases where in the typical GSOC workflow such escalations will take place.

2.5.1          Criteria for Internal Escalation

Following is an account of type of Security Incidents that may result in GSOC triggering an internal escalation request.

2.5.1.1         Process and/or Technology Issue

If GSOC L1 Analyst notices a process which is hindering the performance of the Security Operations, e.g. a broken process or a less than optimal piece of technology, L1 may seek clarification from L2.

Upon either notification from L1 or finding out about the broken process or a piece of technology, L2 can attempt resolution or escalate to the corresponding party (Tooling Engineer, Content Engineer, Threat Analyst, etc.) keeping the GSOC Operations Manager in the loop.

2.5.1.2         Insufficient Data

GSOC L1 Analyst may escalate a Security Incident which has unclear data or unusual or confusing data to seek assistance from L2. L2 may be able to help or will need to request for more information from the Member Firm. The escalation to the designated Member Firm, copying in the GSOC Operations Manager, will result in case the response is not received within the pre-agreed timeframes in relation to the attached priority level.

2.5.1.3         Workload Limit

GSOC L2 Analyst may escalate to the GSOC Operations Manager if a:

  1. Significant number of L1 tickets are pending and cannot be picked up due to the workload.
  2. Significant number of tickets are pending L2 input but are not being addressed due to the L2 workload.

 GSOC L3 (Senior GSOC Level 2) may escalate to the GSOC Operations Manager if a:

  1. Significant number of L2 tickets are pending that require Member Firm response or input and the agreed response times have elapsed.
  2. Significant number of L2 tickets are piling up due to the increased workload.

2.5.1.4         Externally Driven Factors

Refers to situations where communication, or a lack thereof, with a GSOC-external party requires internal escalation.  Examples include:

  • Internal escalation to request the immediate Line Manager within GSOC to intervene to speed up the process of seeking response to a long pending information request that requires communication to a senior member of the corresponding Member Firm
  • Challenges with getting Member Firm to accept Security Incident handover
  • Communication conflict or argument with the Member Firm

2.5.1.5         Compromise of GSOC Enabling and/or Support Services

Situations may arise from time to time, due to technical failures or a disaster, where GSOC enabling and/or support services are compromised resulting in either reduced or no service at all to support and sustain GSOC operations. Support from the KPMG Global Services to restore these services will be requested by the GSOC Operations Manager with support from the Head of GSOC through the standard Business Continuity Management (BCM) and Disaster Recovery protocol.

2.5.1.6         Malicious Behaviour

Situations where an internal resources is suspected to be involved in malicious behaviour are reported to the GSOC Operations Manager, any suspicions against the GSOC Operations Manager are reported to the Head of GSOC and any suspicions against the Head of GSOC are reported to the Global CISO.

2.5.2          Escalation Mechanisms

The purpose of this section is to highlight the available vehicles for the escalation and when it is suitable to execute each of them. It must be ensured that an auditing process is maintained for all escalations in which the elements of any communications related to the escalation are recorded.

2.5.2.1         Tool-based Escalations

RSA Archer SecOps provide Security Incident handover between L1 and L2 role through the use of in-built workflows. All internal escalations can be managed through the use of SecOps. Please refer to the SecOps guide for reference how this can be achieved.

RSA Archer SecOps maintains an audit trail for all communications and escalations by default. For any escalation related communication performed outside the bounds of RSA Archer SecOps, audit trail should be maintained by following up all in-person dialogues and telephone conversations through an email and attaching a copy of that email to the corresponding Security Incident within RSA Archer SecOps, where possible. RSA Archer SecOps Notes capability is utilised where appropriate to directly record follow up conversations and actions.

2.5.2.2         Direct Communication-based Escalations

Direct communication which may involve one or more modes of communications:

  • Personal 1-1 dialogue between the parties
  • Telephone conversation
  • Email

Based on the nature of the Security Incident, P1 or P2, any escalation request made through SecOps may also be followed up through other non-automated, non-Tooling based channel to match the corresponding urgency for remediation.

2.5.3          De-escalation Mechanisms

De-escalation mechanism are setup to ensure the normal course of action is adhered to as soon as reasonably possible. All Security Incidents are appropriately de-escalated after:

2.5.3.1         Escalation has been Deemed Invalid

If the escalation has been found to be invalid, the Security Incident is de-escalated and rules are marked to be revisited to evaluate if any adjustments are required to avoid similar escalations in the future, i.e. whether the baseline needs re-provisioning and the corresponding findings recorded in the lessons learned database.

2.5.3.2         Escalation has been Resolved and Returned to Initial Handler

After the resolution of a valid escalation situation, an escalation may return to the original handler for continued handling, such as resolution of unclear data, a process and/or technology issue that is addressed, or workload limits that have been addressed.

2.5.3.3         Exception Scenarios

Some issues when escalated will not be de-escalated till the time the corresponding parties agree to such a demotion. This includes but is not limited to:

  • High-priority Security Incidents (P2 or higher, as appropriate)
  • Persistent workload issues
  • Externally driven issues which has triggered the interest of the higher management at a strategic level, e.g. current threat landscape, etc.

2.5.4          Reporting

The escalation transition such as transfer of Security Incident between different priority level (P1, P2, etc.) will be reflected in standard reports as mandated by the Reporting Process.

2.6              External Escalation

The purpose of this section is to explain the processes and criteria surrounding external escalations which refers to escalations from the GSOC to the Member Firms.  It is important to note that communications with the Member Firms to provide awareness of Security Incidents is not considered an escalation.

External escalations are intended to capture scenarios which require more senior attention within the Member Firms and/or GSOC, either for the purpose of Security Incident investigation, Security Incident remediation, or other communications which require senior member firm awareness such as an urgent threat intelligence which is affecting or has a tendency to affect a member firm.

2.6.1          Criteria for External Escalation

Following is an account of type of Security Incidents that may result in triggering an escalation request.

2.6.1.1         Priority Level Considerations

The fundamental criteria for escalation emanates from the Priority level of the Security Incident. The following description is provided to serve as a reference for all such escalation touch points:

 GSOC L1 AnalystGSOC L2 AnalystGSOC Operations ManagerHead of GSOCGlobal Privacy OfficerGlobal CISOSecurity CouncilMF CISOMF NiTSOPrivacy Liaison
P1 / P2If the L1 triage and corresponding investigation reveals a P3 or lower Security Incident to be a likely P2 or higher Security Incident, L1 will escalate to L2 for further analysis.Verify that reprioritisation is valid. Return to L1 in case of invalid escalation Security Incident.Liaise with the Member Firm to adjust escalation of the Security Incident.Notified if valid.Notified if valid.Notified if valid. Informs the Security Council if required.Involved for Critical Incidents.Notified if valid.Notified.Notified in case of suspected data breach.
P3 / P4If the L1 triage and corresponding investigation reveals a P2 or higher Security Incident to be a likely P3 or lower Security Incident, L1 will escalate to L2 for further analysis.Verify that reprioritisation is valid. Return to L1 in case of invalid escalation Security Incident.Liaise with the Member Firm to adjust de-escalation of the Security Incident.Notified if valid.N/A. The numbers will be reflected in the standard reports.N/A. The numbers will be reflected in the standard reports.N/A. The numbers will be reflected in the standard reports.N/A. The numbers will be reflected in the standard reports.N/A. The numbers will be reflected in the standard reports.N/A.

2.6.1.2         Quick Response Required for Security Incident Investigation or Triage

In some rare cases, where there is evidence of a potential P2 or higher priority Security Incident, it may be necessary to reach out to member firms to confirm information about systems or other suspected traffic.  This may sometimes require escalation in order to resolve quickly, or if it is unclear who has ownership or primacy over a system.  This is important to stay within the threshold requirements of targeted <5% false positive Security Incident transmission to member firms, this often requires additional investigation, particularly of potentially high priority Security Incidents.

Based on the Triage standard, the first triage is defined to take up to a total of 15 minutes, if there is a requirement for further information from the Member Firm its failure to complete escalation will result in estimating Security Incident priority on the worst-case assumptions.

2.6.1.3         Un-remediated Security Incidents

All P2 or higher Security Incidents that are handed over to the member firms but are not resolved within the recommended timelines qualify for requesting an escalation. Any such escalation request is made with the personnel, designated during the on-boarding of the Member Firm.

2.6.1.4         Service or Data Unavailability

Failure of logging service or lack of access to properly updated inventory data by the Member Firm accounts for a valid case for escalation by the GSOC. This includes scenarios such as:

  • the inventory is not kept up-to-date or
  • the access is revoked to a previously provisioned data repository

2.6.1.5         Failure to Provide Sufficient Information

This criteria applies to the triage and investigation of potential P2 or higher Security Incidents. This is related to the advanced analysis of potential threats where further investigation is dependent on the data provided by the Member Firm but is encountered by delays on their part. Such escalations are necessary to gain quick access to information that is vital for establishing a case for qualifying a Security Incident as accurately as possible.

2.6.1.6         Failure to Acknowledge Receipt

Acknowledgement of the responsibility of the Security Incident by the Member Firm is important to provide GSOC with the trust that the corresponding Member Firm will act towards the remediation of the issue. Any failure in this part should be escalated for all Security Incidents with P2 or higher priority. The same rule applies to the acknowledgement of receipt of high priority Threat Intelligence.

2.6.1.7         Failure to Remediate

Failure on the part of the Member Firm to remediate any reported P2 or higher Security Incidents within the agreed timeframes. Such failures are recorded and escalated appropriately to ensure efforts are made towards remediation.

2.6.2          Escalation Mechanisms

2.6.2.1         Automated Tool

RSA Archer SecOps is the preferred mode of communication. In certain situations SecOps may not be used for escalating to Member Firms for one or more of the following reasons:

  • Member Firm accounts are not created within SecOps.
  • Member Firm utilises non-automated modes of communications.

Alternatively, Member Firms may invest in automating their interfaces through integration of their Security Incident Management System with RSA Archer SecOps. The cost of integration may be shared by a cluster of Member Firms if they are using similar Security Incident Management tool, e.g. Remedy.

2.6.2.2         Direct Communication-based Escalations

Based on the nature of the Security Incident, P1 or P2, the escalation within the SecOps can be followed up by non-automated, non-tool based approach. This is classified as direct communication which may involve one or more modes of communications:

  • Personal 1-1 dialogue between the parties
  • Telephone conversation
  • Email

2.6.3          De-escalation Mechanisms

De-escalation mechanism are setup to ensure the normal course of action is adhered to as soon as reasonably possible. Any de-escalations requests will be routed through the Head of GSOC and the corresponding designated personnel at the Member Firm.

All Security Incidents are appropriately de-escalated after:

2.6.3.1         Escalation has been Deemed Invalid

If the escalation has been found to be invalid by the Member Firm, the Security Incident is de-escalated and the Head of GSOC is informed. A review must be conducted within GSCO for all such cases to ensure that rules are revisited to evaluate if any adjustments are required to avoid similar escalations in the future.  Such inquiries may result in the requirement for the baseline re-provisioning and / or clarifying the adjusting controls on both ends, i.e. GSOC and Member Firms.

2.6.3.2         Escalation has been Resolved and Returned to Initial Handler

After the resolution of a valid escalation situation, a response may be returned to the GSOC for continued handling, such as resolution of unclear / inaccessible data, a process and/or technology breakdown, etc.

2.6.3.3         Exception Scenarios

Some issues when escalated will not be de-escalated till the time the corresponding parties agree to such a demotion. This includes:

  • Unresolved High-priority Security Incidents (P2 or higher, as appropriate)
  • Issues which wider reach within the KPMG eco-system, such as issues affecting multiple Member Firms where the GSOC will manage the escalation till all Member Firms have resolved the issue.

2.7              Appendix A – Constraints and Assumptions

The GSOC Security Incident Escalation Process will continuously evolve overtime to ensure it stays current with the ground reality and continues to build out capability to respond to the ever changing threat landscape and also to respond to the Member Firms requirements as appropriate.

As the process matures, KPMG GSOC Analysts are expected to maintain, regularly build and rely on their knowledge and experience to guide their execution of this process. They are expected to use their best judgment when minor adaptations are needed for execution. Any significant exceptions to this process should follow the instructions in Section 2.6 (Exceptions) of this document.

The limitations recorded below persist at the time of writing this document and should be reviewed as the KPMG GSOC matures and certain constraints change or assumptions are disproven:

2.7.1          GSOC Authority to Investigate and/or Remediate Endpoints

The KPMG GSOC is not expected to have responsibility or authority for remediation or response to Security Incidents pertaining to the Member Firms. The Security Incident will be handed over to the Member Firm for resolution once it has been confirmed during the triage process and the corresponding investigation has been carried out. This handover may or may not include an escalation request. As the GSOC capability and operations continue to mature, the GSOC Triage Process and the Investigation Process will be revisited periodically, and enhanced as part of the continuous improvement process to support stronger and wider collaboration with the Member Firms Incident Response teams.

2.7.2          Limited Analytical Data

The current design of the KPMG GSOC does not include any straightforward analyst capability for data collection from endpoints.  Limited endpoint information may be available when endpoints anti-virus logs are included in GSOC logging and monitoring (LAM) systems, and some endpoint information may be available from directory services, domain name services, or member firm change management records.  This limited amount of information is likely to result in more escalations initially than otherwise required while the GSOC continues to develop more leverage in understanding the root cause behind the Security Incident.

2.7.3          False Positive Rates

The rate of false positives is expected to decline significantly over the course of time. Based on the historical analysis and keeping in mind that the GSOC monitoring and triage processes are at their initial capability, the current expectation is that:

  1. no more than 50% of all automated Security Incident detections that enter the triage process are false positives
  2. no more than 5% of all Security Incidents passed on to the member firms will be false positives

These false positive rate requirements will significantly influence analyst decisions during triage, follow-on analysis and investigation and corresponding escalation, if required.  The key is to establish a balancing act between waiting ‘just enough’ between the escalation steps or else it may result in potentially acting ‘too late’ for a high priority Security Incident.

2.7.4          Level 2 Escalation within SECOPS

RSA Archer SecOps implementation follow an escalation model comprising of Level 1 and Level 2 resources. Level 3 resource is considered to be an advanced Level 2 resource with access to same information as Level 2. The Escalation Process hence will map out to RSA SecOps layout and will not define an automated Level 3 escalation. Beyond Level 2, the escalation will either lead to the Lead Analyst and/or Shift Lead/Manager notifying the Head of GSOC.

2.7.5          Expectations for P3 and P4 Priority Security Incidents

The current definition for P4 Security Incidents is expected to result in a very large number of P4 Security Incidents, due to the GSOC maturity level starting from zero. Accordingly, it is not expected that P4 priority Security Incidents will be included in any of the Escalation Process, unless consolidated with a P2 or higher priority Security Incident.  P4 Security Incidents form part of the monthly report that is produced and circulated to the GSOC management and the corresponding Member Firm(s) periodically. The likelihood and the speed of escalation is directly dependent on the priority level with P1 to mandate the fastest escalation and P4 the slowest if none at all.

2.7.6          Automation Gaps

Member Firms rely on a number of ticketing systems (e.g. Remedy) to manage their Security Incident Handling. These systems will be gradually integrated with RSA Archer SecOps used by the GSOC to allow seamless incident escalation and handover. Member Firms utilising same ticketing systems are expected to join common initiatives to support the integration efforts while sharing the costs for economies of scale.