A Guide to Securing Your SAP

ECC System
Raymond Mastre, CISA, CRISC
Director SAP Security/GRC
PwC
Agenda

Introduction
Basic SAP ECC Security Concepts
Securing your SAP ECC System
Choosing Your Role Design Methodology
Audit Compliance Topics (SoD and SA) and
Security Design Monitoring
Case Study
Wrap-up
Introduction

Over 10 years of SAP Security

and SAP GRC Experience

Completed 10-15 Global SAP

Security Design/Redesigns

Experience working in Beauty,

Pharma, Public, Defense and
Chemicals Industries

CRISC and CISA certified

Raymond Mastre,
Director SAP Security/GRC
PwC
Agenda

Introduction
Basic SAP ECC Security Concepts
Securing your SAP ECC System
Choosing Your Role Design Methodology
Audit Compliance Topics (SoD and SA) and
Security Design Monitoring
Case Study
Wrap-up
Basics SAP ECC Security Concepts

User master record

User requires valid user 1

ID and password

T-code check
User requires an
authorization
2
for transactions

Authority check
User requires an 3
authorization for
business objects
Authorization Analogy

The proper key must be cut specifically for a certain lock

Authorization Analogy
The proper authorization is needed to unlock the SAP program

User

SAP Program
Profile

Authorization
Authorization
Object

Authorization Authorization
Field values Object Fields
SAP Security Key Components

Authorization (fields and values)

Profiles
Users
Roles
Authorizations and Profiles

SAP Authorization SAP Program

Structure Access Element

There are also Profile

composite profiles that
can have other assigned
single or composite
profiles. For example,
SAP_ALL or SAP_NEW
are composite profiles. Authorization
Authorization Object

Authorization Authorization
Field values Object Fields
Users

SAP Authorization SAP Program

Structure Access Element

User

Profile

Authorization
Authorization Object

Authorization Authorization
Field values Object Fields
 Profile Generator

SAP Profile SAP Authorization SAP Program

Security Admin Generator Structure Access Element
creates role and
assigns T-code
menu item(s) User
SAP generates
Authorization Data
based on the menu
items and
Roles Profile
corresponding
USOBT_C tables

Menu Authorization
USOBT_C Items Authorization Object
USOBX_C
(SU24)
Authorization
Data Authorization Authorization
Field values Object Fields
Relevant Security Tables

T-code to Role Mapping AGR_TCODES

Role to User Mapping AGR_USER
Role to Role Name AGR_DEFINE
Roles Within a Composite AGR_AGRS
Authorizations in a Role AGR_1251
Organization Values in a AGR_1252
Role
Fields Within an Object TOBJ
Agenda

Introduction
Basic SAP ECC Security Concepts
Securing your SAP ECC System
Choosing Your Role Design Methodology
Audit Compliance Topics (SoD and SA) and
Security Design Monitoring
Case Study
Wrap-up
Leading Practice Security Designs

Job Based Methodology Task Based Methodology

User General
FI Common
AP Clerk AP Display
Processor

Redundant
Access

FI
Document
AP Reversal FI
Manager Document
Processing
 What is Job Based?

Security roles are built based on positions/jobs for a group of users (e.g.
Accounts Receivable Manager)
A single role contains all of the access to perform a job
Transaction codes and authorizations typically duplicated in many roles

AP AP
Supervisor Clerk

AP Manager
 What is Task Based?

Security is built based on small, definable tasks executed by a user (e.g. Process
Cash Receipts)
Multiple roles are assigned to the user for them to perform their day to day tasks
Transaction codes exist in a single role, with minimal exceptions

FI Document
Reversing
F.80

F.81
SBWP
SU53
FI Document
Processing
FB03 FB01
FBV3
FB02
User General

FI Common
Display
Job vs. Task

Job Based Task Based

Number of roles
1-3 assigned to users
8-10

25-40 Tcodes per Role 6-10

T- code
Significant Minimal
Duplication

On-going change
Role Content Change Role Assignment Change
management

Limited Scalability Highly Scalable

High number of roles with SODs and SOD Low or no roles with SODs and remediation is
SOD
remediation is difficult easy
Common Challenges with ECC Security

Introduction
Basic SAP ECC Security Concepts
Securing your SAP ECC System
Choosing Your Role Design Methodology
Audit Compliance Topics (SoD and SA) and
Security Design Monitoring
Case Study
Wrap-up
Key Areas to Review

The following are key areas to consider when reviewing SAP

security:

SoD and sensitive access

Monitoring of sensitive objects
Security strategy assessment
What are SoDs and SAs?

Segregation of Duties (SoD)

Helps to establish adequate division of responsibilities
between those that create master data and perform
transactional data
Example: Create G/L Account and Post to G/L

Sensitive Access (SA)

Helps to establish that critical functions in a system are
restricted to authorized individuals
Example: Post to G/L
How to Monitor SoDs/SAs

Companies have many different ways to monitor SoDs/SAs

SAP GRC Access Control
Other access control systems (Bizrights, ControlPanel, etc.) or
homegrown monitoring tools
Transaction SUIM
 SUIM
Use transaction SUIM to check for users with sensitive
transactions, objects, or SoDs
Monitor Sensitive Security Objects

S_DEVELOP Controls debug access in

SAP. Value 01 and 02 should
generally not be given in
production.

S_RFC Allows a user to potentially

perform remote calls to other
systems

S_TABU_DIS Controls the ability to view or

change tables in SAP. Star
values should be avoided.

S_PROGRAM Controls program calls in SAP.

As with S_TABU_DIS, avoid
stars.
Security Design Assessment
A security design assessment benchmarks several key
performance indicators against a successful security design

Is less concerned with the access a user has and more

concerned with how they got it

Is completed by performing a statistical analysis of the SAP

Security Environment
Statistical Analysis of SAP Security
Environment
Below are example benchmarks for examining an SAP
security design:
Number of duplicated transaction codes in roles
Number of authorization objects in assigned roles
Number of changed and manually-inserted authorization objects
Number of roles
Number of roles with transaction code ranges or wildcards
Number of changed authorizations
Example: Duplicated Transaction

Duplication of transaction codes complicates the provisioning

process
Example: User needs access to transaction code VD01. If this
transaction code sits in seven different roles, which one can
we assign?
SAP tables to query
AGR_1251
AGR_TEXTS
TSTCT
Expected query result: 5%-8% transaction codes should be
duplicated
Exceptions are transaction codes with different functionality; for
example, F110 (create payment proposal, run payment proposal)
Assessing SAP Security Design
Agenda

Introduction
Basic SAP ECC Security Concepts
Securing your SAP ECC System
Choosing Your Role Design Methodology
Audit Compliance Topics (SoD and SA) and
Security Design Monitoring
Case Study
Wrap-up
Case Study Profile

Company Profile

Consumer Products (Beauty)

Original SAP Implementation: Completed in early 2000s

Total User Count: ~5,000 SAP User IDs

SAP GRC 5.3 Installed at time of project start

Before

Prior to Project

Role Count: 18,000+

Users: 5,000 (3,000 user with more than just T&E)

Firefighter Usage: 3,000,000 transactions in first six months

Business ownership: Limited

SAP GRC Version: 5.3

After

Prior to Project

Role Count: 300 task roles (350 enabler roles)

Users: 5,000 (3,000 user with more than just T&E)

Firefighter Usage: 150,000 transactions in first six months

Business ownership: Significant

SAP GRC version 10

Wrap Up

Top Points to Remember:

Core elements of SAP security are authorizations, profiles,

users, and roles
There are two main methodologies for designing SAP security:
Job and task
Transaction SUIM and/or SAP GRC can be used to test for
Segregation of Duties and Sensitive Access
Sensitive SAP security objects should be restricted
appropriately
An assessment of SAP security design is one indicator on how
successful your security will be long term
 Questions?

Contact me:
raymond.p.mastre@us.pwc.com

This content is for general information purposes only, and should not be used as a substitute for consultation with professional advisors.

2014 PricewaterhouseCoopers LLP, a Delaware limited liability partnership. All rights reserved. PwC refers to the US member firm, and may sometimes refer to the
PwC network. Each member firm is a separate legal entity. Please see www.pwc.com/structure for further details.