5/10/2018 (20) Segregation of Duties in SAP explained | LinkedIn

On May 8, 2018, we published revised versions of our Privacy Policy, User Agreement and Professional Community Policies. Please read these updated terms and take some
time to understand them. Your use of LinkedIn services is subject to these revised terms. Visit the LinkedIn blog to learn more about these changes.

7 2 11 Free Upgrade
Search
to Premium

Segregation of Duties in SAP explained

Published on January 19, 2018

Alexander Polyakov Follow

Founder, CTO, CISO at ERPScan. Speaker/Writer/Trainer 22 1 1
18 articles

Let’s talk about the oldest and most known SAP Security area – SAP Segregation of Duties,
or the SAP SoD. I will try to embrace it in general, without in-depth details.

Plenty of articles that cover various aspects of SAP Security, especially concerning
vulnerabilities and risks, paved the way for today’s discussion on how we can protect SAP
(which is of particular importance now given the upcoming GDPR).

Segregation of Duties, or SoD, is a major factor while dealing with different responsibilities
and job profiles across an enterprise. In an organization, there are multiple functions, which
are performed together with a set of roles/responsibilities. SoD means that these roles are
assigned in such a way that any individual should not have end-to-end access rights over any
function. Segregation of Duties assures that no one has the physical and system access to
control all phases of a business process or transaction: from authorization to custody or
record keeping.

An individual should not oversee more than one of these three transactions components:
authorizing transactions (approval), recording transactions (accounting), and handling the
related asset (custody). For example, a person who can approve purchase orders
(purchasing) should not be responsible for processing payments (accounts payable). There
are hundreds of SoD conflict examples in different SAP products and industry solutions.
Messaging

T f ll S ti f D ti i i l dt t4
https://www.linkedin.com/pulse/segregation-duties-sap-explained-alexander-polyakov/ 1/6
5/10/2018 (20) Segregation of Duties in SAP explained | LinkedIn
To follow Segregation of Duties principles, you need to carry out 4 processes:

1. SAP SoD Development

7 2 11 Free Upgrade
Search
to Premium
2. SAP SoD Implementation

3. SAP SoD Assessment

4. SoD Remediation in SAP

Most companies try to embark upon these processes from the last step, and their activity
turns out to be in vain (and you will learn why).

1. SAP SoD Design

Companies should set up an organizational structure where the roles (let’s call them business
roles) of every employee type are outlined. The roles are, for instance, an account manager,
marketing specialist, administrator, and support engineer. The business roles should consist
of certain functions (let’s call them actions) such as create payment order, approve payment
order, create vendor, delete user.

Each action can be associated with one or more system functions in an application. In SAP,
these functions usually are transactions that also may be web pages, services, remote
function calls, screens or others, depending on a business application.

In fact, actions in SAP should be associated with transactions and authorization values as
well, but it’s not relevant at this particular stage.

The table is an example of required assignments. The name of a business role in a second
column is called Customer Master. There are actions associated with it, in the third column
(for instance, change customer) and a transaction for each action in the fourth column (for
example, transaction XD02 for Change Customer action). You can read more about
transactions here from the previous posts
https://www.linkedin.com/pulse/segregation-duties-sap-explained-alexander-polyakov/ 2/6
5/10/2018 (20) Segregation of Duties in SAP explained | LinkedIn
transactions here from the previous posts.

After you complete your organization structure development, create an SoD matrix. Define
7 2 11 Free Upgrade
Search which business roles are critical to combine in one user account. For example, Customer to Premium

Master and Customer Incentives should not be assigned to one user account as Customer
Master Role has rights to create sales deal, and Customer Incentive role – to change
customer master data action. If one user can run these two actions, it may end up with fraud.

The next step is to define levels of risks for each combination and fill out the matrix, the
example of which is shown in the screenshot.

In the matrix, business roles are listed in the left column and the upper string (each number
is associated with a particular business role). The level of risks in case both roles are
assigned to one person is shown at the intersection, where “H” stands for high risk, “M”
implies medium risk, and “L means low risk. A cell is empty if this combination does not
pose a risk.

A large global company frequently applies more than one matrix due to the differences in
the business processes by location or business unit.

It’s worth mentioning that this matrix is system-independent. Therefore, it doesn’t matter
which kind of business application you manage, be it either SAP ERP, HANA, J2EE
platform, Oracle PeopleSoft application or even home-grown solution. Your aim is just to
define high-level business roles in this matrix.

2. SAP SoD Implementation

How to implement SoD in SAP systems? First, it’s necessary to map business
roles and actions to technical roles and transactions. Traditionally, companies hire some Big
Four consultants to conduct all steps described here (i.e. defining organization structure, role
modeling, naming conventions for technical roles, etc.).

After you considered the tables (SoD Matrix and SoD Business Roles provided in
screenshots 1 and 2), you need to create technical roles in an SAP system based on defined
tables, assign technical roles to user accounts in SAP so that every user acquires one or more
technical roles.

Why more than one? For example, both an account manager and marketing specialists have
the same responsibilities and can execute similar actions (e.g. sending updates to a
customer), which can be collected into one technical role (let’s call it customer update role).
Every business role (real role in the organization) is associated with several technical roles
https://www.linkedin.com/pulse/segregation-duties-sap-explained-alexander-polyakov/ 3/6
5/10/2018 (20) Segregation of Duties in SAP explained | LinkedIn
Every business role (real role in the organization) is associated with several technical roles
(access to many transactions).

7 2 11 Free Upgrade
Search
3. SAP SoD Assessment to Premium

Moving from theory to practice, I’d like to point out that SoD Assessment is the most
complicated process. Even if the previous steps (SoD development and SoD
implementation) are properly fulfilled, you need to be sure that everybody follows these
requirements during any change. It is time for SoD tools to come into play.

SAP SoD Tools

SoD tools check if users can execute critical transactions or their combinations in the
existing organization structure since there is a risk of fraud. The word “existing” indicates
that most of the companies don’t even have SoD Development and SoD Implementation
steps in place. Unfortunately, if a company is unaware of what employees should do and
how they run particular actions in SAP, the SoD tools won’t be instructive.

However, some approaches still can be come in handy. There are various of tools to check
SOD from SAP’s SAP GRC to 3rd party tools such as ERPScan, SecurityWeaver,
ERPMaestro, and others.

How to work with SoD tools, if you don’t have an organizational structure and don’t know
what every user should do? SoD tools provide a list of typical actions in a particular
business role and transaction names correlated with the actions. For example, an admin role
definitely should have at least one action, i.e. creating a user that can be performed by
executing the SU01 transaction in SAP. More advanced tools encompass these templates for
a particular Module, such as Material Management (MM), CRM (Customer Relationship
Management), or even for particular Industry such as Oil and Gas, and Retail.

So, what can we gain from these tools? First and foremost, we obtain the list of users with
access to critical default transactions, which exist almost everywhere (e.g. SU01 – user
creation, SE16 – table reading). This alone can save a lot of time and give a high-level
understanding how bad our situation with the role management is. If we see hundreds of
users who can run critical transactions (e.g. SU01, SE16, SM59), there are multiple issues at
the SoD Design stage regardless of company’s business processes. Secondly, we can get the
list of users with the access to typical combinations of critical transactions such as create
payment order and approve it. Once you have customization and use alternative ways to run
transactions (for example, using ZSU01 instead of SU01 to create a new user), you can
configure it in the SoD tool and rescan the system with the customized options.

There are advantages to applying SoD tools even if you don’t know what your organization
structure should look like or if you don’t have any idea of business processes of this
organization (for example, if you perform external assessment). It is a good solution to
quickly identify who can perform critical transactions such as “delete user.”

Undoubtedly, there are some limitations. Companies may have custom transactions for
https://www.linkedin.com/pulse/segregation-duties-sap-explained-alexander-polyakov/ 4/6
5/10/2018 (20) Segregation of Duties in SAP explained | LinkedIn

provided actions, and once you ignore it, you get incorrect results. However, you will
anyway take into careful consideration the system’s security. For example, if there are

Search
hundreds of users, which can run critical transactions7 (e.g. SU01 – create
2 new
11 user, SE16 – Free Upgrade
to Premium
read any table, SM59 – manage remote connections) and perform numerous actions from a
default template, it means that irrespectively of business processes, there is a majority of
issues at the SoD Design stage.

Let’s see how we can benefit from SAP SoD tools if you already have an organization
structure together with risk matrix and other templates where you defined who can perform
particular actions. The next step is to import them into the tool. This process can be both
challenging and easily implemented. Depending on your format, I recommend storing your
data on SAP SoD risks in Excel spreadsheets since it will facilitate its export into some of
the tools. Unfortunately, not every tool supports the import, so be careful while choosing the
right option. After you run it, you will get the list of users and sometimes technical roles
with SoD conflicts. Now it’s time for Remediation.

4. SAP SoD Remediation

SoD Remediation is the toughest process. Nonetheless, it’s still possible to figure something
out. Sometimes deviations from the normal behavior can tell you what’s wrong. Assume,
you find that the number of users in a technical role is zero, and the question “is this role
really needed?” arises. If the number of users is more than 100, it might be better to divide it
into a number of separate roles. The same can be applied to the number of authorizations, or
authorization objects, for roles.

Afterwards, analyze the output of the tool itself, don’t worry that you will get hundreds of
thousands of conflicts at first. Most of them are not relevant, and it will require more fine-
tuning. Start with technical roles.

As a rule, the SoD tools provide not only the list of users with conflicts but also the list of
technical roles with conflicts. In case a conflict occurred in a technical role, you have a
conflict with all users included in it. Therefore, analyze your technical roles first and after
you finish with them, go to users who can access critical transactions and exclude those of
them who have particular type or status (such as blocked users, or technical users), exclude
all the administrators, and you will get the final list of conflicts. Now you need to minimize
the number of them.

Here are tips to simplify this work. Look at precisely how rights are assigned. All wildcards
in authorization objects values (if you assign access to all tables in S_TABI_DIS
authorization) and area values should be excluded. A wildcard in authorization value
provides a significant risk of potential unauthorized access and shows that nobody has cared
about clarifying what rights the employee need to accomplish the work. Furthermore, look at
the history of executed transactions. If it was not performed within last six months,
employees probably don’t need it, and you can easily exclude this access from users.

Conclusion
https://www.linkedin.com/pulse/segregation-duties-sap-explained-alexander-polyakov/ 5/6
5/10/2018 (20) Segregation of Duties in SAP explained | LinkedIn

There are numerous resources describing each step of this process in detail and giving you
so many alternatives how to solve discussed problems
7
that sometimes
2
it’s harder
11
to choose Free Upgrade
Search
to Premium
the right approach then to implement it. Anyway, now you know the Segregation of Duties
basics.

Report this

22 Likes

+12

1 Comment

Tafadzwa Chinhamo 4mo

CISA,CISM,CGEIT,CRISC,CISSP

Well explained..thank you

Like Reply

Add a comment…

Alexander Polyakov
Founder, CTO, CISO at ERPScan. Speaker/Writer/Trainer

Follow

More from Alexander Polyakov See all 18 articles

SAP SECURITY FOR CISO PART 13: SAP SECURITY FOR CISO. PART 12: Perfect SAP Penetration testing SAP SECURITY
ATTACKS AND INCIDENTS SAP MOBILE INFRASTRUCTURE… (part2) SECURITY
Alexander Polyakov on LinkedIn Alexander Polyakov on LinkedIn Alexander Polyakov on LinkedIn Alexander Polya

https://www.linkedin.com/pulse/segregation-duties-sap-explained-alexander-polyakov/ 6/6