How to analyze SOD violations in SAP ERP and S/4HANA: an overview

When setting up your SAP authorization concept you follow 2 rules:
1. minimize access (in particular to very risky transactions/data)
2. avoid combinations of access authorizations that are risky, like creating a vendor and posting an invoice for the same vendor.

remQ has built-in controls for several SOD use cases, like SOD risks that you will find in the SOD matrix of SAP GRC Access Controls. But you can set up your own, new rules very easily. Here we explain a few basics that you should understand when you start your journey.

Where does SAP save information about who created or changed an SAP Business Object?

When a user creates a vendor in the SAP system, the username is saved together with the vendor master data in table LFA1. The fields is LFA1:ERNAM (created by).
Now when some user changes data for the vendor, changes are logged in SAP change documents: change documents exist for >1500 business objects in SAP ERP or S/4HANA, and also customers can create their own change document types. Basically a change document is a simple set of data that only has information about which object was changed, by whom (username), when, and the change details (old value/new value). All change documents are saved in tables CDHDR and CDPOS.

How can you make use of the data?

We use the example above about creating or changing a vendor, and posting/changing an invoice: there are 4 possible SOD combinations that you need to check if you want to cover 100% of risks in the scenarios:

1. user creates vendor and posts invoice
2. user creates vendor add changes invoice
3. user changes vendor and posts invoice
4. user changes vendor and changes invoice

In all cases, the user might try to set up a bogus vendor/invoice or change bank details and divert a payment.

So in order to cover all 4 scenarios, you need to have 4 queries getting data from different sources and compare the usernames and make sure the invoice is from the same vendor:

1. user creates vendor and posts invoice: table – table
2. user creates vendor add changes invoice: table – change document (type BELEG _or_ INCOMINGINVOICE)
3. user changes vendor and posts invoice: change document – table
4. user changes vendor and changes invoice: change document – change document

The tables involved are LFA1 and BKPF for vendor and invoice respectively, and the change document types are KRED (for the vendor), and BELEG (accounting document) or INCOMINGINVOICE (for MM invoices).

In this simple example, there are 6(!) combinations that need to be covered in order to detect all possible scenarios.

Because reading data from a table and accessing data in a change document works somehow differently, different ways and tools are required.

How remQ helps to access and correlate the data

We have developed 3 tools that make life easier and allow to detect all those transactions where a user executes a high risk transaction and changes data, or excuses a high risk combination of transactions/changes a combination of data.
For single transaction that are considered high risk, you can use the Single Action Tool: this allows to define which business object and change document you want to monitor, and even which field you consider as critical, e.g. monitor only changes to vendor bank details.
For combinations of transactions, you can use the SOD Tool and/or the SQVI Query Viewer together with our mapping tool. The SOD tool gives access to data in change documents, and automatically correlates only change documents that “belong together”, like invoices that come the same vendor that was changed. The SAP standard SQVI transactions enables you to create and run analysis for data in tables.

These 3 tools are own framework for Access Violation Management and can be set up by users without coding.

We have examples in our Knowledge Base on how to set up SOD controls using these tools.

From risk to mitigation

Access risks such as from the SAP GRC Access Controls SOD matrix can be avoided in some cases by changing SAP authorization roles, or assigning different roles to users when re-organizing work and processes. But in many cases, organizations cannot avoid to grant high risk combinations of authorizations to users, simply because there are not so many users. In that case, you find residual risks in SAP GRC Access Controls and you accept them. remQ’s Access Violation Management allows you to set up controls for each residual risk that you have in SAP GRC, and monitor all activities related to them. You the can review activities and have a compensation controls for those risks.