2-3-0 acr1 high level design 1

8/11/2019 2-3-0 Acr1 High Level Design 1

1/17

Access Control Product:

High Level Design

Documenting the high level solution design; capturinghow business requirements will be met with atechnology solution

Author(s): Fahri Batur

Issue Date: 4thNovember 2013

Version: v1.0

Contact: Fahri Batur+971 (0)55 207 [email protected]
mailto:[email protected]:[email protected]:[email protected]


2/17

2. High Level Design www.integrc.com

Contents1. Document Details ..................................................................................................................... 3

2. Business Requirements ........................................................................................................... 5

3. Solution Design ........................................................................................................................ 6

4. Technology ............................................................................................................................. 17


3/17


1. Document DetailsThe document management details are shown in the section below.

Document Distribution

Integrc:

Fahri Batur

Client:

Hind Obaid Saeed Al Falasi

Version 1.0

Document Change Control

Document change history is detailed below.

Date Version Author Changes

thNovember 2013 1.0 Fahri Batur Initial version

Document Purpose

This document provides a high level solution design of the access control requirements and options that havebeen considered for the implementation of a GRC solution.

Any design decisions that have been considered as part of this document are documented in full in the DesignDecisions Workbook in Appendix One.

Note: Generic elements of the SAP GRC suite are referenced thro ugho ut this d ocum ent; however the

scope of th is do cument is l imi ted to GRC Access Contro l only .


4/17


Other Reference Documentation

Details of other supporting documentation are listed below.

Document Title Version Comments


5/17


2. Business RequirementsBusiness Objectives

RouteOne project deliverables will provide traceability of requirements throughout the project thus mappingrequirements to solutions and specific functionality through to test cases and scenarios and businessassurance that the solution has met the requirements. This High Level Design is the first step of thistraceability and will initially set out what is to be achieved; Strata is embarking on a journey to bolster accessrelated controls, the goals of which are to successfully deliver the following objectives:-

Stratas goal is to manage access risks and conflict of duties for its core business processes.

Implementation of SAP GRC Access Control to automate user and role management and implement amore appropriate SAP Authorisation concept by a role re-design.

Requirements Summary

Requirements are categorised here at the highest level and mapped to the appropriate SAP GRC AccessControl module in the table shown below.

Requirement Category Category Overview SAP GRC 10.0 Module

SoD and critical riskmanagement

SoD and critical risk management to providevisibility of risk exposure created by inappropriateSAP access and provide assurance to thebusiness that these risks are being appropriatelymanaged

Access Risk Analysis

Emergency access to systems Safer provision of elevated access to SAP withability to monitor the actions of privileged users

Emergency AccessManagement

utomated and compliantuser provisioning

Automation of provisioning process with enforcedSegregation of Duties check built into the process.

Access RequestManagement

SAP roles and authorisationsgovernance

SAP roles authorisations governance andmanagement. Enforce role build methodology overthe long term and invoke enforced SoD checksinto the role development process

Business Role Management


6/17


3. Solution DesignSAP GRC Access Control is the chosen technology to meet the business requirements, connecting to the SAPtarget systems in order to provide best in class access controls for risks associated with provision of SAPaccess to users.

System connectivity between SAP GRC Access Control and target systems will be facilitated by either SAPstandard secured RFC [SNC] connections or third party adapters for non standard target systems. The tablebelow shows standard connectivity between GRC Access Control and Strata target systems.

System SAP/3rd Party

ECC 6.0 SAP

BW 7.01 SAP

GRC 10.0 SAP

Note: Further inform ation relat ing to system co nnectiv i ty can be found in the Technolo gy

Requirements Document.

The landscape for SAP GRC Access Control will be two-tiered consisting of a Development and Productionenvironment. This alignment with business requirements will reduce the cost of ownership and reduceimplementation time by not introducing a middle tier of QA environment.

The Transport Management System (TMS) enables the export and import of SAP authorisations,configuration, customisation, tables, and workflow between SAP application instances.

The following sections will now be broken down by each relevant SAP GRC Access Control module andprovide additional detail of each will help meet the objectives of the solution.

Access Risk Analysis

SAP GRC Access Risk Analysis (ARA) will be the reporting tool that will provide Strata with a real time positionof Segregation of Duties (SoD) and critical risk conflicts across connected systems.

The table below provides an overview of the module and its business benefits to Strata.

Module Overview Business Benefits


7/17



he most frequently implementedmodule of the SAP GRC AccessControl suite. ARA leverages a set ofdefined rules to identify access riskexposure within SAP/Non SAP

echnical roles.

he module provides a number ofreports that can be used tobenchmark metrics and identifyaccess risks at user, role, profile and

user group level.

Reduce time evaluating requests by:-

Real time SoD check, or as frequently as required

Alleviating the need for manual human intervention in SoDcompliance checks - instead the risk analysis can be handledautomatically and would only require approval or rejection from theResponsible Owner

Integration with provisioning module (ARM) to prevent accessrequests from being approved if an access risk is identified

Provides functionality to improve visibility of potential fraud risk and controlover access, helps resolve these access issues and ensures that they are notre-introduced by

Identifying access to critical roles or transactions

Reducing requirements for further full reviews and redesigns

Highlighting unacceptable SoDs to be removed from current rolesand/or users

Ensuring on-going compliance through automated risk analysisduring user provisioning to prevent SoDs being created

Better reporting of access risks through integration with reporting tools by:-

Simplifying and combining all risk and control information intoDashboards for easier interpretation by senior management

Identifying changes in access risk over time and across divisions

Access Risk Analysis Ruleset

The core engine of ARA is its ruleset. The ruleset is used to report on SoD and single sided risks at the role,

profile, user and user group level.

The ruleset is made up of multiple groupings of transaction codes and authorisation objects across a set ofbusiness processes that Strata will monitor in the form of risks. The ruleset is effectively a set of rules that areused to analyse roles and users to identify risk exposure.

SAP GRC Access Control is delivered with a standard ruleset that reflects years of best practice thinking interms of risk identification and definition. This standard ruleset will be leveraged as a starting point to facilitateconversations with Strata stakeholders regarding identification of risks applicable to your organisation throughrisk identification workshops.

The table below outlines the standard SAP rule sets that will be activated for SAP target systems


8/17


System Ruleset Comments

ECC 6.0 ECC, BASIS The ECC and BASIS rules will be activated for the ECC system. HRrelated rules will be deactivated

BW 7.01 BASIS BASIS rules will be activated in BW 7.0. A standalone ruleset for BWdoes not exist, nor is one required for non technical SoD reporting inthis system

GRC 10.0 BASIS Only BASIS rules will be activated in GRC 10.0

Access Risk Analysis Mitigating Controls

The concept of mitigating risks is important in the business as usual process of SoD risk management. The

goal will be to have as few SoD risks present in the production system as possible but some risks will beunavoidable. In these cases, it will be paramount to be able to prove to auditors that any residual risk ismitigated, i.e. that there are business controls in place that will identify if a user is able to or has used theirconflicting access in a way that is detrimental to Strata.

In ARA, controls are mapped to risks and can be assigned to users or roles. It is then possible to report onwhich risks are mitigated and which are still unmitigated. This is an important distinction as unmitigated risk isinherently bad as fraudulent activity could go undetected.

The process of running mitigating controls will be executed outside of ARA.

Mitigating Controls for access based risks will be determined once the risks in the ruleset have been agreed.

Integrc will facilitate workshops with Strata to identify mitigating controls and where appropriate, leverageexisting controls based on business processes.

Access Risk Analysis Configuration

Before ARA can be used to conduct its analysis, a number of parameter ids will need to be configured. Theseparameters control the behaviour and default settings of ARA along with the change logs associated with it.

The parameters configured within the development system will mirror those in production. Further detail on theparameter configuration will be included in the detail level design.


9/17


Access Risk Analysis Deployment

The target systems that are considered in-scope for ARA are

SAP ECC 6.0SAP BW 7.01SAP GRC 10.0


10/17


The following table outlines how ARA will be deployed and connected to the different environments.

System GRC 10.0 ECC 6.0 BW 7.01

GRC 10.0 DEV DEV DEV DEV

GRC 10.0 PRD DEVPRD

DEVPRD

DEVPRD

Emergency Access Management

Emergency Access Management (EAM) will be used to manage elevated access to critical businessprocesses across connected systems. The table below provides an overview of the module and its businessbenefits to Strata.


he SAP GRC module that managesaccess to SAP in an emergency that isypically outside an end users business

as usual responsibility.

Centralised Emergency Access Management

Centralised platform to manage and provision emergency accessto SAP systems

Centralised reporting on all connected SAP systems

Better placed for interaction with newer SAP technologies such asanalytics, mobile platform and in-memory computing.

Enhanced control over what users do whilst logged on with enhancedaccess. This can reduce the risk of data confidentiality issues, dataintegrity issues and system availability issues

Emergency Access Management Master Data

Mapping of end users, fire fighter ids, controllers and owners will need to be identified during the project. Thiswill be documented in the Master Data Design product.


11/17


Emergency Access Management Access

The underlying technical roles that provide access for EAM IDs will be identified and mapped by the Project.

The assignment of EAM Ids to end users (once in business as usual) will be facilitated by SAP GRC AccessRequest Management.

Emergency Access Management Deployment

The target systems that are considered in-scope for EAM are


The following table outlines how EAM will be deployed and connected to the different environments.



GRC 10.0 PRD DEV

PRD

DEV

PRD

DEV

PRD

Access Request Management

SAP GRC Access Request Management (ARM) is the provisioning tool that will provide Strata with the abilityto manage SAP user access management and role assignments within connected systems.

SAP access requests are created online in the tool by requestors and submitted for approval. The requestorwould be responsible for selecting the roles required by the user. Once submitted, the request is routed onlineby workflow to relevant approvers.

An integrated and enforced SoD check is carried out during the process in order to help avoid introducing SoDrisks into the environment. Where an SoD is identified by this enforced check, the approver has to make adecision on how the request should proceed.

Once all approval conditions are met, the request is submitted for provisioning where ARM auto provisions the

access to the user in the relevant target system(s).


12/17




ccess Request Management manageshe access of users to SAP and non-SAP

systems. This solution automates the newoiners (account creation), movers,(provisioning of roles) and leavers(deactivation of user accounts) process.

RM integrates with EAM to

automatically provision elevated accesso end users by utilising workflow.

RM also integrates with ARA allowingpotential SoD and critical risk conflicts tobe identified prior to assignment.

Significant improvements in provisioning solution e.g. usability, workflow,flexibility, speed, maintenance, implementation and system performance

Dynamic workflow decision making leveraging the multi stage, multi path(MSMP) and SAP BRF+ capability

A number of ready to use out of the box workflows for ARM integration withEAM and ARA

Pro-active avoidance of unmitigated SoD risks by enforced SoD check, thusreducing fraud risk

Access Request Management Workflow Process

SAP provide a number of out of the box workflow processes for SAP GRC Access Control. Whilst additionaland customised Multi Stage Multi Path (MSMP) workflow processes cannot be created, it should be noted thatthose delivered are sufficient for leveraging all possible GRC Access Control capabilities.

All MSMP workflow processes are fully modifiable, allowing dynamic workflows to be designed andimplemented.

The addition of Business Rules Framework (BRF+) allows the implementation of custom initiators, approverstages and detour routes. A number of settings can be applied within the workflow approval stages to cater fordifferent approver types or specific stage behaviours, such as enforcing SoD checks or the mandatoryinserting of comments prior to request approval.

BRF+ will be leveraged where required to meet business requirements.

The table below outlines the workflow processes that are delivered by SAP.

Process ID Description Module Notes In Scope

SAP_GRAC_ACCESS_REQ

UEST

Access Request

Approval WorkflowARM General Access Request

Management ProcessYes

SAP_GRAC_ACCESS_REQ

UEST_HR

Access RequestApproval Workflow for

ARM HR based Access Request process No


13/17



HR OM Objects

SAP_GRAC_CONTROL_AS

GN

Control Assignment

Approval WorkflowARA Initiates a workflow item to approve

Mitigating Control assignmentsYes

SAP_GRAC_CONTROL_MAINT

Mitigation ControlMaintenance Workflow

ARA Workflow to approve changes toMitigating Control definitions.Mitigation controls are independent

to the ruleset and maintained asmaster data on each instance ofGRC

Yes

SAP_GRAC_FIREFIGHT_LOG_REPORT

FireFighter Log ReportReview Workflow

EAM Initiates a workflow item containingthe EAM session log to review andapprove

Workflow item sent to the EAMController

Yes

SAP_GRAC_FUNC_APPR Function ApprovalWorkflow

ARA Initiates approval request forproposed changes to Rule Set

Function definitions

Note: This workf low shou ld only

be enabled w ith in the GRC

Developm ent system

Yes

SAP_GRAC_RISK_APPR Risk Approval Workflow ARA Initiates approval request forproposed changes to Rule Set Riskdefinitions

Note: This workf low shou ld onlybe enabled w ith in the GRC

Developm ent system

Yes

SAP_GRAC_ROLE_APPR Role Approval Workflow BRM The Role Build/MaintenanceWorkflow

Yes

SAP_GRAC_SOD_RISK_REIEW

SoD Risk ReviewWorkflow

ARM /ARA

Workflow process to initiate androute the SoD Risk Review. Canalso be configured to initiate theremoval of violating roles via

Yes


14/17



Access Request Workflow

SAP_GRAC_USER_ACCESS_REVIEW

User Access ReviewWorkflow

ARA /ARM

Workflow process to initiate androute the User Access Review.Can also be configured to initiateremoval of un-used/non requiredroles via Access Request

Workflow.

Yes

Access Request Management - Access Request Process

The current user provisioning process will be identified during requirements gathering and translated into ARMready process flows.

Custom Approver Determinator (CAD) settings shall be converted to BRF+ decision tables. The requirement ofenforcing SoD/Critical risk analysis on the Access Request shall also be enabled.

Access Request Management Configuration

Before ARM can be used for automated user provisioning, a number of parameter ids will need to beconfigured. These parameters control the behaviour and default settings of ARM along with the change logsassociated with it.


Access Request Management Deployment

The systems that are considered in-scope for ARA are


The following table outlines how ARM will be deployed and connected to the different environments.


15/17


System GRC 10.0 ECC 6.0 BW

7.01


GRC 10.0 PRD DEV

PRD

DEV

PRD

DEV

PRD


SAP GRC Business Role Management (BRM) will govern the end to end technical role development process.The tool applies a role build methodology against all connected systems according to configuration basedupon Strata requirements. BRM will also enforce an SoD check each time a role is saved thus helping toprevent the introduction of SoD risks into roles.



Business Role Management governs theend to end processes for SAP ABAP roledevelopment from inception to production

usage.

BRM integrates with ARA and ARM.

Provides a single enterprise role repository for role design, testing andmaintenance to enforce consistency and standardisation

Facilitates the role design process with a pre-defined (and customisable)design methodology and workflow

Supports the definition and documentation of role information,

authorisations and testing results

Supports integration with ARA to enforce the risk analysis during roledesign to prevent risks from entering application systems

Reduces fraud risk by pro-active avoidance of SoD risks at the role level.ISACA write that it is 7 times more expensive to fix security related issuesafter the event than to put preventative measures in place to avoid them

Allows preventative measures to be carried out far quicker than manualalternative (using GRC simulation functionality)

Using the business roles concept can enhance business ownership of


16/17



roles and related concepts as they aid better understanding of theprovision of access to users

Business Role Management Configuration

Before BRM can be used to provide governance over role builds, a number of parameter ids will need to beconfigured within GRC. These parameters control the behaviour and default settings of BRM along with thechange logs associated with it.


Role methodologies will be defined in the detailed level design document to cover various role build scenarios.

Note: These scenarios wil l b e determined by attr ibutes that are assigned to the role, e.g. Functional

Area and system .

A suitable and sustainable role naming convention will need to be in place so that BRM can be configured toleverage the naming convention.


Role Mapping

The business roles concept, (new addition to GRC 10.0) will be leveraged to group cross system access. Abusiness role is a virtual container for roles that span across multiple systems.

Business roles can be used to determine the access necessary for the function or process the user is involvedwith, helping organisations better manage changes to access. Once Business roles have been mapped withthe appropriate job tasks, organisations can easily control compliance or business risk by running their rulesagainst the requests.

Business roles are system independent. An example is, when Strata creates a business role that has assignedtwo technical roles, one for system A, and one for system B. When this business role is assigned to the user

(having two technical roles from two different systems) it is not necessary to select the system for the businessrole itself. The request will automatically provision to both the technical role's systems.

This approach makes it more straightforward for understanding, requesting and approving access to SAP.

Note: This approach w il l replace the exist ing dependant role con cept.

Business Role Management Deployment

The systems that are considered in-scope for BRM are

SAP ECC 6.0

SAP BW 7.01


17/17

SAP GRC 10.0

The following table outlines how BRM will be deployed and connected to the different environments.



GRC 10.0 PRD DEVPRD

DEVPRD

DEVPRD

4. Technology

The architecture of GRC 10.0 has evolved: the product is now hosted on a dedicated platform, separated frommonitored systems. Previous versions have been located within the monitored SAP system: This change isintended to enable organisations to establish a single control system from which to manage and administerprotected systems, and it also allows a significant amount of processing requirements from GRC activities tobe removed from the monitored system.

2-3-0 acr1 high level design 1

Documents