SAP Se cu r it y Co n ce p t s ,

Se g r e g a t io n o f D u t ie s ,
Se n s it iv e Acce s s &
M it ig a t in g Co n t r o ls

J onathan Levitt
March 20 15
Ag e n d a

1. Introduction
2. SAP Security Design Overview
3. The SAP Authorization Concept
4. Approaches to SAP Security
5. Segregation of Duties & Sensitive Access
6. Mitigating Controls
7. Questions

March 2015
PwC 2
Ob je ct iv e s

At t h e e n d o f t h e s e s s io n , t h e p a r t icip a n t w ill:
• Gain an understanding of the SAP security environm ent and why security is im portant
to the audit;
• Define and understand what a segregation of duties conflict in SAP is, and how to
m onitor/ address it; and
• Define and understand m itigating controls.

March 2015
PwC 3
SAP Se cu r it y D e s ig n Ov e r v ie w

March 2015
PwC 4
SAP Se cu r it y D e s ig n Ov e r v ie w
Introduction

W h at is SAP Se cu rity D e s ign ?

At its m ost fundam ental level, SAP Security Design refers to the architectural structure of
SAP security roles. However, effective security design is achieved via the convergence of
role architecture:
1. SAP Security Organizational Structure & Governance
- Ownership, Policies, and Accountability
2. SAP Security Processes
- User Provisioning, Role Change Managem ent, Em ergency Access
3. Ongoing Managem ent & Monitoring of the Security Environm ent
- KPIs, Recertification, “Get Clean & Stay Clean”

March 2015
PwC 5
SAP Se cu r it y D e s ig n Ov e r v ie w
Introduction

Org
Structure &
Security & Governance
Provisioning
Processes

SAP Security
Architecture

Mo n ito rin g

Effe ctive SAP

M Se cu rity D e s ign

Man age m e n t

March 2015
PwC 6
 SAP Se cu r it y D e s ig n Ov e r v ie w
SAP Security Design Challenges
• Misalignm ent of IT vs Business
Objectives
• User provisioning process with • Lack of Strategic Security Design
insufficient autom ation & Org Decisions
inform ation Structure & • No Role or Security Design
Security & Governance Ownership
• Role Change Mgm t lacks risk and
quality controls Provisioning
Processes
• Inefficient em ergency support process
• Overly Com plex Security Design
SAP Security • Lacks flexibility to respond to
Architecture ongoing changes
• Managem ent KPIs for Security Design • Lacks scalability to grow with
are not established organization
• Lack of autom ation for ongoing • Inefficient Role Build Approach
m onitoring & recertification • No Docum entation of Security
Mo n ito rin g
procedures Control Points
• Insufficient SoD and/ or Mitigating • Inherent Segregation of Duties
control fram eworks Risk
Effe ctive SAP
M Se cu rity D e s ign

Man age m e n t

March 2015
PwC 7
SAP Se cu r it y D e s ig n Ov e r v ie w
Audit Issues & Com plexity
• Poor security can lead to audit issues
‒ When access controls are not in place, it im pact the am ount of reliance audit can
place on reports com ing from SAP
‒ Segregation of Duties is a key underlying principle of internal controls, and is the
concept of having m ore than one person required to com plete a task. Security can
have a detrim ental im pact on this control (to be discussed in greater detail later in
presentation).
• It is som etim es difficult for auditors to dig deep into SAP because security is com plex:
‒ In SAP ERP 6.0
o 10 8,0 0 0 transaction codes
o 2,60 0 authorization objects
‒ Several transaction codes can perform sim ilar tasks

March 2015
PwC 8
Th e SAP Au t h o r iz a t io n Co n ce p t

March 2015
PwC 9
Th e SAP Au t h o r iz a t io n Co n ce p t
Introduction

Org
Structure &
Security & Governance
Provisioning
Processes

SAP Security
Architecture

Mo n ito rin g

Effe ctive SAP

M Se cu rity D e s ign

Man age m e n t

March 2015
PwC 10
Th e SAP Au t h o r iz a t io n Co n ce p t
Introduction (continued)

SAP Security Security within the SAP application is achieved through the
Architecture authorization concept.

The authorization concept is to help establish m axim um security, sufficient privileges for
end users to fulfil their job duties, and easy user m aintenance.

March 2015
PwC 11
Th e SAP Au t h o r iz a t io n Co n ce p t
Three levels of security in SAP

U s e r m a s te r
re co rd
User requires valid
user-ID and password 1

T-co d e ch e ck

User requires an
authorization for 2
transactions

Au th o rity ch e ck
User requires an
authorization for
underlying 3
authorization objects
and field values

March 2015
PwC 12
Th e SAP Au t h o r iz a t io n Co n ce p t
The Com ponents
Ro le s
SAP U s e r Mas te r Re co rd Contains transaction codes, authorizations
Master data for SAP users
(m apped to one profile) and user assignm ents

Au th o rity Ch e ck
Pro file s Perform ed by SAP to help establish that a user
Container of authorizations has the correct authorization to execute a
particular task.

Au th o rizatio n Obje ct:

Tem plate for security that contains fields with
blank values

Au th o rizatio n ( Fie ld Valu e s ) :

Authorization object with com pleted fields

March 2015
PwC 13
Th e SAP Au t h o r iz a t io n Co n ce p t
Bringing it together

Le t’s m ake an an alo gy… th e Lo ck an d th e Ke y

To o p e n th e lo ck, th e p ro p e r ke y m u s t be cu t s p e cifically fo r
a ce rtain lo ck

March 2015
PwC 14
Th e SAP Au t h o r iz a t io n Co n ce p t
User Types
SAP Authorization
Structure

U s e r Typ e
User
Dialog A
System B
Com m unication C
Service S Ro le
Reference L

Pro file

Au th o riza tio n

March 2015
PwC 15
Th e SAP Au t h o r iz a t io n Co n ce p t
Authorization Structure
SAP Authorization
Structure

User

Ro le

Authorization is not the sam e as Pro file

transaction. Why?

Au th o riza tio n

In SAP, you can perform the sam e

function with different transactions.

March 2015
PwC 16
Th e SAP Au t h o r iz a t io n Co n ce p t
Authorization Structure (continued)
SAP Authorization SAP Program Access
Structure Elem ents

User • SAP is delivered with

about 150 0 authorization
objects
• An object is a structure
provided by SAP to grant
Ro le access to a data elem ent
or a task in a
specific content.

Pro file

Au th o riza tio n
Au th o riza tio n
Obje ct

Au th o rizatio n Au th o riza tio n

Fie ld Valu e s Obje ct Fie ld s

March 2015
PwC 17
Th e SAP Au t h o r iz a t io n Co n ce p t
Authorization Structure (continued)
SAP Authorization SAP Authorization SAP Program Access
Structure Structure Elem ents

User

Ro le

Me n u Ite m s Pro file

U SOBT_ C
Au th o riza tio n
U SOBX_ C Au th o riza tio n
Obje ct
( SU 2 4 )

Au th o riza tio n Au th o rizatio n Au th o riza tio n

D a ta Fie ld Valu e s Obje ct Fie ld s

March 2015
PwC 18
Th e SAP Au t h o r iz a t io n Co n ce p t
Why are authorization objects required?

In SAP, you can perform the sam e function with different transactions:
Tr a n s a ct io n Co d e
MK0 1 FK0 1 XK0 1
Conventional approach
protection via m enu/ function

SAP approach protection

Cre ate Ve n d o r once via authorization

March 2015
PwC 19
Th e SAP Au t h o r iz a t io n Co n ce p t
The Authority Check
Tr a n s a ct io n Co d e ch e ck :
Obje ct S_ TCODE Start T Code
Fie ld 1 TCD Start T Code FB0 3

Au t h o r iz a t io n ch e ck :
Obje ct F_ BKPF_ BUK Display posting
Fie ld 1 ACTVT Display 03
Fie ld 2 BUKRS Com pany Code 10 0 0

March 2015
PwC 20
Ap p r o a ch e s t o SAP Se cu r it y

March 2015
PwC 21
SAP Se cu r it y Ap p r o a ch e s
Task Based vs. J ob Based Security Design
Jo b Bas e d :
• Security is built based on positions/ jobs within
the organization, such as AR credit associate.
• Provisioning access is based on job
responsibilities.
• Sm aller num ber of roles per user – increased risk
for granting functionality m ore than once.
• Transaction codes and authorizations typically
duplicated in m any roles.
• Users m ay be granted m ore access than necessary
as a result of “additional job” or backup
responsibilities.
• Appropriate for static organizations.
PwC
Tas k Bas e d :
• Security is built based on sm all, definable tasks,
executed by the user, such as process cash
receipts.
• Larger num ber of roles per user – decreased risk
of duplicate access.
• Transaction codes in one roles with m inim al
exceptions
• User assignm ent flexibility – sim ple to grant
additional access to only the tasks necessary.
• Supports future growth and sustainability – role
m odification decreased as a result of
functionality im provem ents and rollouts.
• Appropriate for dynam ic organizations.
March 2015
22
SAP Se cu r it y Ap p r o a ch e s
J ob Based Security Design

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

AP AP
Supervisor Clerk

AP Manager

March 2015
PwC 23
 SAP Se cu r it y Ap p r o a ch e s
Task Based Security Design
A task-based design begins by bucketing transactions into one of 4 access tiers: General, Display,
Functional and Control Point. Task-based roles contain access to only one of these tiers.

U SER PROFILE TIER 1: GEN ER AL ACCESS

General access is provisioned via one single role
m ade up of tasks com m on to users such as
printing, inbox, SU53, etc.

TIER 2 : D ISPLAY ACCESS

Display access is provisioned via a set of roles
User General defined by functional area that allow display
and reporting access intended to com plim ent
the functional roles of the users.
What

TIER 3 : FU N CTION AL ACCESS

AR Com m on Display
AP Display FI Com m on Display Functional access is provisioned via m ultiple
single task based roles. Role grouping of
activities that are the lowest com m on
denom inator of tasks and perm ission
com ponents to suit the needs of the end-users.
Vendor Master
Contract Maintenance Process Billing These groupings usually are SoD free and part
Maintenance
of a sub-process such as Invoice Processing or
Material Master Maintenance.

Organizational Organizational
TIER 4 : CON TR OL POIN TS
Where Roles that provide additional control point
Grouping - A Grouping - B
access or granularity needed by Tiers 1-3 such
as Com pany Code, Plant, etc.

March 2015
PwC 24
SAP Se cu r it y Ap p r o a ch e s
Task Based Security Design (continued)

• Security roles are built based on positions/ jobs for a group of users (e.g. Accounts
Payable Clerk).
• User assigned to the tasks needed to perform his/ her job (not a job-based role)
• User receives m ultiple single roles
• Flexibility to each individual user’s role assignm ents

AP Clerk

Organizational
User General AP Com m on Display Process Billing
Grouping - A

March 2015
PwC 25
Se g r e g a t io n o f D u t ie s & Se n s it iv e
Acce s s

March 2015
PwC 26
Se g r e g a t io n o f D u t ie s & Se n s it iv e Acce s s
Introduction
Se g r e g a t io n o f D u t ie s
A segregation of duties risk is when a
com bination of abilities that when
assigned to a backend user constitutes a
risk.
Objective of this risk is to facilitate the
appropriate division of responsibilities.
PwC
Se n s it iv e o r Cr it ica l Acce s s
A sensitive or critical access risk is
where the direct assignm ent of an
ability to a backend user constitutes a
risk.
Objective of this risk is to help establish
that access is restricted to the
appropriate individuals.
March 2015
27
Se g r e g a t io n o f D u t ie s & Se n s it iv e Acce s s
Introduction (continued)
Se g r e g a t io n o f D u t ie s
Exam ple risk:
Maintain Accounting Periods vs. Post
Accounting Docum ent in GL
Allow a user to inappropriately open
accounting periods previously closed
and fraudulently post docum ents to
that period after m onth end.
PwC
Se n s it iv e o r Cr it ica l Acce s s
Exam ple risk:
Post Accounting Docum ent in GL
Should be restricted to authorized users
to thereby decrease the risk of
fraudulent, m alicious of erroneous
journal entries being posted.
March 2015
28
Se g r e g a t io n o f D u t ie s & Se n s it iv e Acce s s
Exam ples
• Finance: Maintenance of accounting periods should be segregated from the posting of
financial transactions in the wrong period.
• Inventory : The receipt/ m ainten an ce of inventory should be segregated from order
and invoicing activities.
• Accounts Pay able: Reconciling and releasing blocked vendor invoices should be
segregated from daily processing and posting activities.
• Procurem ent: Maintenance of contracts and term s should be segregated from
paym ent and billing docum ent changes.

March 2015
PwC 29
Se g r e g a t io n o f D u t ie s W a lk t h r o u g h

March 2015
PwC 30
Se g r e g a t io n o f D u t ie s W a lk t h r o u g h

March 2015
PwC 31
Se g r e g a t io n o f D u t ie s & Se n s it iv e Acce s s
How to m onitor?

• Com panies have m any different ways to m onitor segregation of duties and sensitive
access:
‒ SAP GRC Access Control
‒ Other access control system s (Approva, ControlPannel, SecurityWeaver, ACL,
etc.) or “hom egrown” m onitoring tools
‒ Reporting transaction code “SUIM”.

March 2015
PwC 32
M it ig a t in g Co n t r o ls

March 2015
PwC 33
M it ig a t in g Co n t r o ls
Introduction

D e fin in g an d ap p lyin g Mitigatin g Co n tro ls

If violating access cannot be rem ediated as there is a legitim ate business purpose for
access then m itigation is going to be required. Mitigating controls are designed to cover
the residual risk of a user having that access.
For exam ple, if a business unit is too sm all to segregate duties in the purchasing
departm ent and users m ust have the ability to create and approve purchase orders for the
business to function, the business m ay choose to establish a m itigating control to analyze
transactions by users with access to both sides of the SOD conflict to m itigate the risk:
• Risk: A user can create and approve a fictitious PO.
• Key Control: The ability to release (approve) and create purchase orders is
segregated.
• Mitigating Control: Location supervisor analyze purchase orders entered into SAP
by the two Purchasing Clerks from the business unit

March 2015
PwC 34
M it ig a t in g Co n t r o ls
Considerations

No Deactivate or
Is the risk truly a risk for
Switch to Low
compliance requirement?
Risk
Determine the
controls in place
Yes that mitigate

Preventive Detective

Scenario 1: Scenario 2: Scenario 3: Scenario 4:

No intent to grant access.
Management does not intend
that any users receive access
to the risk. No mitigating
controls should be created.
Some Users Require
Access
The SOD is enforced partially
in the environment, most
users do not have the access,
however some need it.
Detective controls (mitigating)
are put in place for these
users.
Remediation of Access
Occurring
Management intends to
enforce the SOD however
most users currently have
access as the business
processes require redesign
and/or the access
remediation.
Detective controls (mitigating)
are put in place while
remediation occurs.
Detective Controls
Management has detective
controls in place that mitigate
the associated risk.
Management does not intend
to segregate the access in
the system to mitigate the risk
in a preventive manner.

Mitigation
Process
March 2015
PwC 35
Qu e s t io n s ?

This publication has been prepared for general guidance on matters of interest only, and does
not constitute professional advice. You should not act upon the information contained in this
publication without obtaining specific professional advice. No representation or warranty
(express or implied) is given as to the accuracy or completeness of the information contained
in this publication, and, to the extent permitted by law, PricewaterhouseCoopers LLP, its
members, employees and agents do not accept or assume any liability, responsibility or duty of
care for any consequences of you or anyone else acting, or refraining to act, in reliance on the
information contained in this publication or for any decision based on it.

© 2015 PricewaterhouseCoopers LLP. All rights reserved. In this document, “PwC” refers to
PricewaterhouseCoopers LLP which is a member firm of PricewaterhouseCoopers
International Limited, each member firm of which is a separate legal entity.