General security

SAP Security for CISO part 14: SOD [Updated 2019]

Numerous articles covering different aspects of SAP Security mostly regarding vulnerabilities and risks paved the way for today's discussion on how we can protect SAP (which is of particular importance given upcoming GDPR).

Let's start with the oldest and most known SAP Security area – Segregation of Duties. I will try to embrace it in general, without in-depth details.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

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 various 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.

To follow Segregation of Duties principles, you need to carry out four processes: SoD Development, SoD Implementation, SoD Assessment, and, of course, SoD Remediation. 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. 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 screenshot illustrates a table, which 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.

After you complete your organization structure development, create an SoD matrix. Define which business roles are critical to combine in one user account. For example, Customer 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. 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 specialist 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

(access to many transactions).

3. SoD Assessment

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.

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 3^rd 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 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 hundreds of users, which can run critical transactions (e.g., SU01 – create new user, SE16 – 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 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 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.

3. 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

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

There are plenty of resources such as this one describing each step of this process in detail and giving you so many alternatives how to solve discussed problems that sometimes it's harder to choose the right approach then to implement it. Anyway, now you know the Segregation of Duties basics.