SAP GRC 10.

1 - Access Control Project

Lessons Learned

January 2015

Big Picture: Identity Management and Access Control

Create Users
Assign Roles
New Hire /
Change Position

BOBJ
Reme
diation

User
Position

Compliance
Check

SRM

SAP HCM (HR)

HR Master record
Position Based
Access

SAP NetWeaver
Identity Management

SAP GRC
Access Control

Line Manager

Calculates Entitlements
Based on Position

Compliance Check
& Remediation

Approve Assignments

Non SAP
Systems
Create Users
Assign Privileges

Big Picture: Solution

Create Users
Assign Roles

New Hire /
Change Position
Web Front end
to access request

BOBJ
Reme
diation

User
Position

Compliance
Check

SRM

SAP HCM (HR)

HR Master record
Position Based
Access

SAP NetWeaver
Identity Management

SAP GRC 10
Access Control

Line Manager

Calculates Entitlements
Based on Position

AMR, DMR, CEA, PUA

Approve
Using Workflow

= Not in Scope

Non SAP
Systems

Create Users
Assign Privileges

SAP GRC Components Implemented

Process
Controls *
Redesigned
Roles &
Provisioning
Process

Provision &
Manage
Users
(PMU)

SAP User
Analyze &
Manage
Access Risk
(AMR)

* Design &
Manage
Role (DMR)
Centralized
Emergency
Access
(CEA)

Phase II

How many Roles in Production?

A.
B.
C.
D.

> 2,000
> 1,000 and < 2,000
> 500 and < 1,000
< 500

SAP Security Design Considerations

Task Based Roles vs. Job Based Roles

Decision:
Bite Size Inherent Conflict Free
Task Roles

Task Based Role Approach

Process Invoice
T-Code

T-Code Description

F-43

Enter Vendor Invoice

Maintain Vendor Master

T-Code

T-Code Description

MK01

Create Vendor

Security is built based on small, definable

tasks executed by a user (e.g. Process
Cash Receipts)
Larger number of roles per user
decreased risk of duplicate access
Transaction codes in one role with very
minimal exception
Smaller number of roles to choose from

Global Roles; Global Processes; Global Role Owners

Job Based Role Approach
A/P Clerk
T-Code

T-Code Description

F-43

Enter Vendor Invoice

MK01

Create Vendor

ME23

Display PO

Security is built based on positions/jobs for

a group of users (e.g. Accounts Receivable
Manager)
Smaller number of roles per user
increased risk for granting functionality
more than once
Transaction codes and authorizations
typically duplicated in many roles.
Too many Job roles to choose from leading
to complexity in provisioning process

User Access and SOD Management :

How it works?

Request Access

List of Roles

Manager Approve

SOD Check
(based on Rule-sets)

1: Removed User
2: Adjusted
Roles
Access
3: Adjusted
SOD
1: Removed User
Rule-set(s)
Access
2: Adjusted Roles
3: Adjusted SOD
Rule-set(s)

Reject

Approve

Apply Mitigating
Controls

Role Owners

Why Mitigate Segregation of Duty Conflicts?

Function:
ZPR01 - Vendor Master Maintenance

Roles:
ZE:PR_MAINT_VNDR_MSTER_BU_IT
ZE:PR_MAINT_VNDR_MSTER_HR
ZE:PR_MAINT_VNDR_MSTR_IC_BU_IT
ZE:PR_MAINT_VND_MSTR_BU_IT_RUS
XK01
XK02

Mitigate
the users
with SOD
ME21
ME21N

Risk:
ZP008 - Maintain a
fictitious vendor and
initiate purchase to
vendor

Mitigating Control:
PRO.PROCR.EBAYI.
C01:
The Global Vendor
Manager reviews
monthly vendor adds
and change reports.

Roles:
ZE:PR_MAINT_PURCHASE_ORDER

Function:
ZPR02 - Maintain Purchase Order

Risk Mitigation Strategy

Level

Risk Definition

Mitigation Strategy

Low

Low inherent risk. Well controlled and consistent

processes in place

Blanket Mitigation. Mitigation

does not need to be part of the
control framework

Medium

Medium inherent risk. Well controlled within the control

framework and well tested. Business processes and
controls which support the risk are consistent/centralized
across the organization.

Mitigated at User or Risk

Level. Mitigation needs to be
part of the control framework

High

High inherent risk. Processes may be

inconsistent/decentralized across the organization. Global
or local entity specific controls are in place to mitigate this
risk.

Mitigated locally at the User

Level. Mitigating control needs
to be part of the control
framework.

Critical

High inherent risk and existing controls are not sufficient to

mitigate this risk

No one shall have this risk

Access Controls Governance enabled by SAP GRC

10

Process Consideration
Automated User Provisioning

Role Management Process

Fire Fighter Process
User Access Review Process
Critical / Sensitive Access Review
SOD Rule-set Review

11

Lessons Learned
Principle of Security Redesign
Ensure that SAP Roles are clean and inherently conflict free
Use transaction history as the basis of redesign
Log transactions 6 months before start of the project
Define stakeholders and engage. Leverage steering committee to manage changes.
Engage with External Auditors early; They are a key stake holder.
Define business SOD rule-sets early; SOD rule-sets are the basis of your SOD conflicts.
Dont believe all that your consultants promise. Think about sustaining the process and systems when
consultants are gone.
Change management, Change management, Change management: Training is key.
Articulate the Governance process.

12

Governance Model
Governance Team /
Steering Committee
Controllers/Process
Owners
Role Owners
Information
Technology
SOX PMO/Internal
Audit

Automated
Provisioning
Automated SOD and
Access Review
Fire Fighter
User reports

GRC Maintenance
Role and Rule-Set
Management
Fire Fighter Access
SOD Review

People

Process

GRC
(System)

Controls
User Access Review
Critical Access Review
Firefighter Access
Review
SOD Rule-set and
Reports Review
ITGC Control

13

How to contact me:

Sangram Dash
sangramdash@gmail.com
https://www.linkedin.com/in/dashuclaanderson

14

Disclaimer
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies.

15