Lesson 19 of 33
In Progress

Identity & Access Management Process

1                  Introduction

1.1              Purpose

Identity and Access Management is a key aspect to safeguard data confidentiality, integrity and availability with GSOC. The purpose of this document is to describe the process for managing account lifecycle within GSOC.

For the purpose of this document, all GSOC systems within the administrative scope of GSOC shall be referred to as “GSOC managed systems”. For all systems outside of administrative scope of GSOC, they shall be referred to as “External GSOC systems”.

1.2              Scope

This process covers only accounts on GSOC managed systems. Accounts on external GSOC systems will be covered within their respective documentation. For situations where accounts in GSOC managed systems is dependent on an external GSOC system account, this document will describe at a high level how access/changes can be requested.

Also this document only covers the lifecycle of an account from creation until it is deactivated. It is KPMG’s policy to not delete accounts, but to deactivate them in order to retain auditability.

It will not detail technical authentication and technical authorisation details.

This process will cover the following GSOC managed systems, within the Production and Quality Assurance (QA) environment):

  1. CRITS Portal
  2. CRITs MongoDB
  3. IIS Webserver
  4. RSA Archer SecOps
  5. SharePoint
  6. SQL 2012
  7. RSA Security Analytics

This process will cover requests for the following external GSOC systems:

  1. GSOC Organisation Unit (OU) within ITS UK Active Directory
  2. ITS Global Service Desk maintained by ITS Global
  3. Layer 7 Proxy

The document does not go into elaborate detail, provide low-level technical procedures, or address all potential outcomes or failure cases.

1.3              Ownership

This document is owned by the GSOC Director.  He or she is responsible for ensuring that this is updated and maintained.

1.4              Audience

This document is intended for all SOC members (see Section 2.7).

1.5              Exceptions

Exceptions to this process can be temporarily authorized by GSOC Operations Manager.

1.6              Reporting Violations

Failure to adhere to this process must be reported to the GSOC Director.

1.7              Responsibilities

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 Identity and Access Management (IAM) process.

1.7.1          GSOC Director

The GSOC Director has overall accountability for systems within the GSOC.

1.7.2          GSOC Operations Manager

The GSOC Operations Manager is responsible for the day to day running of the GSOC. They will be the key approver for access requests of GSOC managed systems and external GSOC systems.

The GSOC Operations Manager shall be responsible for auditing all L3 Analyst related IAM requests and re-certifications.

1.7.3          Tooling Engineer

The Tooling Engineer will ensure that all GSOC managed systems will be configured as per this process. They are also to ensure that all identify associated with access rights that GSOC has authority for, do not have default passwords. Also, to ensure that all service accounts being used have its passwords changed as per KPMG security policies.

1.7.4          L3 Analyst

The L3 Analyst shall be responsible for reviewing all access changes for GSOC managed systems, with the exception of their own.

The L3 Analyst shall also be leading the recertification process for all GSOC managed systems and external GSOC systems with the exception of their own.

1.7.5          GSOC Members

All GSOC members will be expected to understand this process, and which mechanism to use when requesting access.

1.8              Upstream (Dependent) Processes

Resource Offboarding Process

Change Management Process

1.9              Downstream (Affected) Processes

Disaster Recovery Plans

Crisis Management Process

 

2                  Process Overview and Considerations

There are different types of accounts and their management are described in the sections below.

2.1              Identity and Access Management (IAM) Lifecycle

For all accounts, the Identity and Access Management Lifecycle is as follow. The rest of the document will describe how this lifecycle is applied to all account types.

  1. Request – New joiner/leaver/mover/change in access needs
  2. Authorise – Request for access is approved
  3. Provision – Request is implemented
  4. Monitor – Recertify accounts throughout lifetime of account, putting in requests to change if required

2.2              Authorisation Matrix

The below table includes the types of authorisation each standard role should have within the GSOC. It covers the systems which each role should have in order to perform their role. Granular details about their access will be covered in the technical configuration documentations. An X indicates authorisation for access.

 GSOC OUCRITS PortalMongoDBIIS WebserverSecOpsSecurity AnalyticsSharePointSQL 2012ITS Global Service DeskDoor Access
L1 AnalystXX  X X XX
L2 AnalystXX  X X XX
L3 AnalystXX  X X XX
Reporting AnalystXX  X X XX
Compliance AnalystXX  X X XX
Threat Intelligence AnalystXX  X X XX
Tooling/Content EngineerXXXXXXXXXX
Operations ManagerXX  X X XX
GSOC DirectorXX  X X XX
Member Firm Employees involved with GSOCX     X X 

2.3              High Level Process Flow

The flow chart below depicts how the IAM Lifecycle will be implemented in the GSOC. It is largely self-explanatory, and additional details are provided in the sections below.

2.4              IAM for External GSOC Systems

2.4.1          Request

All requests shall be made through ITS Global Service Desk which is owned by ITS Global. If the request is to create a ITS Global Service Desk account, it can be created by another staff.

Once the appropriate form within ITS Global Service Desk is filled in, the request will be routed to the appropriate team/authoriser. The routing will be documented within the GSOC Support Model.

For password resets, a request must be raised through ITS Global Service Desk.

2.4.2          Authorise

The following shall be considered in the authorisation:

  1. Is there a business need for the access supported by the need to know, and has it been recorded in the form?
  2. Is there a Segregation of Duties (SoD) issue? I.e. will it grant the requestor ability to bypass SoD security controls?
  3. Is this temporary access? If yes, has details of duration and mechanisms to remove access at end of duration been documented?

If information is lacking, the form shall be rejected, and the requestor to submit a request again.

2.4.3          Provision / Implement Request

If approved, the request will be routed to the implementer who will proceed to implement the change and close the ticket once it is implemented.

2.4.4          Monitor

It will be the responsibility of the GSOC to monitor and recertify its accounts and access rights. The L3 Analyst will be leading this exercise. Quarterly, the L3 Analyst will request for a list of all accounts within UK’s Active Directory (GSOC Organisation Unit).   

2.5              IAM for GSOC Managed Systems

This section covers the process for all GSOC managed systems.

2.5.1          Request

All requests will be submitted through ITS Global Service Desk. The form will detail the mandatory information required as well as optional information to help the authoriser understand the request. The form shall be submitted to the GSOC Operations Manager for further action.

For password resets, a request must be raised through ITS Global Service Desk. If access to ITS Global Service Desk is not possible, approval for reset can be obtained verbally or through email. A retrospective ticket must be raised immediately after to maintain an audit trail of resets and approvals.

2.5.2          Authorise

The approver will review the Access Request Form and accept or reject the request. All decisions must be captured and documented. The requestor shall be informed of the decision.

If information is lacking, the form may be rejected, and the requestor to submit a request again.

The following shall be considered in the authorisation:

  • Is there a business need for the access supported by the need to know, and has it been recorded in the form?
  • Is there a Segregation of Duties (SoD) issue? I.e. will it grant the requestor ability to bypass SoD security controls?
  • Is this temporary access? If yes, has details of duration and mechanisms to remove access at end of duration been documented?

Accepted forms shall be sent to the Tooling Engineer to be actioned.

2.5.3          Provision / Implement Request

The Tooling Engineer shall configure the account as documented within the ticket, and record date of change.

For account removals, it is KPMG’s policy to not delete accounts, but to deactivate them in order to retain auditability.

For new accounts:

  1. The Tooling Engineer shall use a different communication medium for passwords than that used for notifying an end user of their identity. No default passwords shall be used for new accounts. The Tooling Engineer shall, where technology allows (e.g. enabling “Change Password a first logon setting”) or notifications (e.g. in email to account holder) mandate the account holder to change their password at first logon. All passwords shall comply with applicable password policies.
  2. The Tooling Engineer shall use unique IDs for all accounts created. These accounts shall be the same as the account holder’s Enterprise Active Directory (AD) ID.

Temporary authorisations must be deactivated when the duration indicated in the request is over. If an extension to the duration is required, a new request shall be raised. Unless approval to the new request is granted, the account shall be deactivated in accordance to the original request.

Any requests deemed as temporary authorisations (i.e. weeks) must not be iterated (repeated) more than twice. If this does occur, this is deemed as a permanent request and the permanent authorisation request shall be applied.

2.5.4          Monitor

Every month, the L3 Analyst shall review all access request tickets for GSOC managed systems, and validate the change against those configured in the systems.

Every month, the GSOC Operations Manager shall review all Access Request Forms for GSOC managed systems related to the L3 Analyst.

Quarterly, the L3 Analyst will lead the re-certification for all accounts within GSOC managed systems. The GSOC Operations Manager will recertify L3 Analyst’s accounts.

3                  IAM Supporting Processes

3.1              Emergency Access

3.1.1          In the event of a Disaster

In the event of a disaster, it is possible that all access would have to be granted to all personnel. This is dependent on the situation and approval must be obtained from the GSOC Director or GSOC Operations Manager.

3.1.2          In the event access is needed urgently and no one available has the access

In the event that access to a particular system is needed urgently, and no one available has the access, the emergency ID can be used. The emergency ID will be configured to have full access to all systems. Prior to usage of the ID, approval must be obtained from the GSOC Director, GSOC Operations Manager, L3 Analyst or L2 Analyst. Approval can be verbal or through email.

A retrospective ticket must be raised immediately after to maintain an audit trail of usage and approvals.

  1. Assumptions and Constraints

This document assumes that the human/system already has a UK KPMG enterprise ID which will allow them access to the KPMG resources.