Does it Have to be Painful to Reorganize SoD Conflicts and SAP Authorizations?

At the conference on SAP Security - Tips for Security, I shared with you the knowledge I've gained from both SoD and authorizations reorganization projects and daily tasks in Managed Services. For those of you who could not attend the conference, we have prepared a brief summary.

At the outset, we asked ourselves what might be the reason for the decision to embark on such a venture as the Authorization Reorganization Project. Example scenarios are:

1. The company has experienced data leakage or financial fraud resulting from overly broad user rights.
   We found out about the incident by accident. How many events did we not learn about?
2. There has been a failure on the production system -. unintentional human mistake. Were the authorizations too broad? Do we know how to reproduce the error? Does the system keep logs, and do we know how to read them?
3. SAP role clutter, loss of sense of control over roles. Add new permissions to roles, do not remove permissions. The result: everyone has access to (almost) everything.

SoD Concepts

We also recalled the basic concepts of SoD - from the general to the specific:

Deadline	Definition
SoD matrix	A set of defined and described authority conflicts in a given area (e.g., FI, TR, SD, HR, Basis)
SoD conflict	A critical combination of at least two business processes (e.g., issuing payroll + changing bank account, opening accounting periods + releasing documents for payment, system configuration + importing transportation)
Risks	A description of the SoD conflict from the business point of view and the possible consequences of the assigned powers
Process	Business operation (e.g., opening an accounting period, releasing documents for payment)
Authorization ID	defined transactions, reports, tables that is, the values of SAP fields checked by the engine of the matrix defined and configured on the SAP system. All that we want to catch as "critical" in the permissions of controlled users
Mitigations	Control of risks to which access should be withdrawn/maintained for specific users; controls can be manual, compensatory, automatic, following the "four eyes principle"
SoD Segregation of duties	That is, each employee performs only his part of the process and no one is authorized to act beyond his position responsibilities!

PRU Planning

When planning a PRU, at least the following 5 phases should be planned:

1. Analysis Current SoD conflicts, authorization problems, status of roles, status of procedures
2. Planning tasks and responsibilities in the PRU, the new Concept of Authorization
3. Configuration new roles, Firefighter
4. Tests/Pilot
5. Production Start - Hyper care, documentation has its owners, mitigations

A whole host of challenges and pitfalls await us during the project, such as when we analyze critical accesses on the SAP system and detect who has an assigned SAP_ALL profile....

It may not be so easy for individuals to want to give up such wide, comfortable access. The argument: "I'm a key user and need wide access on a moment's notice in case of an emergency on the system."
Another surprise concerns another important aspect in the project. Well, the authorization and SoD reorganization project is an eminently interdisciplinary project. To create a perfect project team, we need to involve and divide tasks among both business and technical users (Authorization Team, module consultants, developers, Basis). Unfortunately, very often when a project has "authorization" in its name the project owner is often assigned in IT teams:

Examples of Standard SAP Tools Compared to SAST Suite Tools

After defining the owners of topics and tasks in each phase of the project, it is important to think about the appropriate tools that can be useful in an entitlement and SoD reorganization project. It is worth looking at the tools available from SAP and in the market that reduce time-consuming and automate work project team. Below I give examples of how SAP standard tools are juxtaposed with SAST Suite tools.

1. SoD conflict matrix - or our authorization engine. Let's start our activities by collecting and documenting the critical processes in the organization.
   SAP standard: configuration of "Critical combinations" and "Critical authorizations" in SUIM. Verification exclusively At the Tcode (transaction) access level.
   SAST Suite: ready library of SOD conflicts (more than 300 defined conflicts) by SAP modules. Verification at the level of Tcode access + permission object + value of permission object fields.

4. Trace - we use this functionality to trace user actions on the system against the authorizations used.
   SAP Standard: ST01 or SM20 (Security Audit Log), SU53, STUSOBTRACE
   SAST Suite: Ability to start tracking any users from a single dashboard + full data on activities performed + creation of a role from trace.
   User tracking + creating a role from the permissions used + displaying missing permissions
   The result: creation of a role from the trace on the selected user.

Summary

Let's not forget the other challenges of the Authorizations Reorganization Project:

• Concept of Entitlement - maintenance - this document is a "living organism"
• Authorization and user management processes
• Identify area owners and roles
• Cyclic checks of SoD and authorizations - at least once a year
• Maintain continuity of the authorization system and SoD

Let's Collaborate

Should you be particularly interested in any of the issues discussed, you are cordially invited to contact me.