Reverse Engineering for the SAP security concept

How content is the organization with the current set up of the roles in SAP? Are your users happy with the assigned authorizations? If they are, the auditor probably is not happy with the assigned authorizations to the roles and users…..

Maybe there are already plans to redesign the current authorization concept…. How easy would it be if you can redesign the authorization concept with reverse business engineering? Instead of thinking and designing which authorization should be included in which role from scratch, just have a look at the authorization the users have and analyze the functionality the users have been using (or wanted to use) based on the executed transactions and assign these needed authorizations to the roles.

Example:

User John Smits is assigned to the composite role for system administrator S99-XXXX_SYSTADM. This system administrator role has 13 single roles assigned. In this overview the assigned roles are showed whether or not the user is using transactions from these roles. If transactions are used via the role, the executed colomn has a checkmark and the role is executed by the user (Figure 1).

Figure 1 Role details of user John Smits

If you double click on the role, you get the role details like the transactions, authorizations, executed transactions, if the transaction is locked in the SAP system et cetera (figure 2).

Figure 2 Transaction details of role

Let’s go back to the user John Smits. John wants to have broader access rights and was temporary assigned to a broad access role to solve an issue. This temp role was removed from the user after he solved the issue. Now let us have a look at the transactions of the user (figure 3).

Figure 3 Total transaction of user John Smits with executed and missing information

The transactions in red are no longer assigned to the user (also checkmark in column Missing (3)). The transactions in black are still assigned to the user. The checkmark column executed (1) means the user has executed the transaction. The column Frequency (2) shows the number of times the user has executed the transaction.

With this information you can search the single roles that have the missing transactions and analyze if the user should be assigned to this single role(s). If you double click on the transaction, a new screen shows the information about the transaction and the roles that have the transaction assigned. For this example we want to add transaction MB03 so we double clicked on the transaction MB03. The transaction is assigned to 2 single roles Display Material Documents Inv – S99MXXXXMADID and Display Material Documents Purchasing – S99MXXXXMADPD (figure 4).

Figure 4 Detail information about transaction including roles that have transaction included

SOD simulation

For this example we want to add the single role S99MXXXXMADID to the composite role S99-XXXX_SYSTADM of the user. To keep a compliant security concept we use the SOD simulation functionality of the CSI Role Build & Manage (RBM) tool (figure 5).

Figure 5 SOD simulation for role requests

Running the SOD simulation gives the overview “before” and “after” adding the single role to the composite role. In this case, no new SOD conflicts will be created by adding the role (Figure 6)

Figure 6 Results of SOD simulation for role request

And the request can be send automatically via workflow and email to the approver. After the request is approved by (all) the approver(s), it is even possible to have the change implemented in SAP directly, no longer manual role changes need to be done in the SAP system

Use reverse Business engineering to redesign of the complete role concept

The above example is just one way to use reverse Business engineering to redesign the security concept for just one user. Off course this is also possible for a complete redesign process. Instead of looking at one user, you look at the total usage of transactions of all the users and assign these used transactions with the correct authorizations to roles. (Figure 7).

Figure 7 User vs (executed) transaction overview

And the functionality for reverse engineering goes even further. The used organizational levels can be read from the existing roles and documented in the central codification functionality of CSI RBM. Usaging of the deriving functionality of CSI RBM you can automatically derive all the roles, both single and composite for the new role concept for both organizational (like company codes) and non organizational (like movement types)values.

©

©

©

©

(C) Meta Hoetjes 2014 
CSI Authorization Auditor and CSI Role Build and Manage are registered trademarks by CSI Tools bvba
www.csi-tools.com