We are all aware of the importance in having the SAP security in place. What I do find remarkable that the focus is always on transactions codes: Financial audits,SOx compliance or user requests. All is focused on users having access and being restricted to transaction codes.
SAP confirms that transactions can be bypassed in their definition of SAP security in the help file.
"To ensure that a user has the appropriate authorizations when he or she performs an action, users are subject to authorization checks. The following actions are subject to authorization checks that are performed before the start of a program or table maintenance and which the SAP applications cannot avoid:
- Starting SAP transactions (authorization objects S_TCODE). Indirectly called transactions are not included in this authorization check.
- Starting reports (authorization object S_PROGRAM)
- Calling RFC function modules (authorization object S_RFC)
- Table maintenance with generic tools (S_TABU_DIS)."
There are many kinds of transactions like standard transactions, enjoy transactions, custom transactions or parameter transactions. And nobody is really aware about the (very large) number of transactions that are available in the SAP system. If you are not aware of the transaction codes and its functionality, unwanted access to critical functionality and even SOD conflicts will occur.
Example of different transactions leading to the same functionality: Post incoming payment. If you want to post an incoming payment from a vendor, you can go to the functionality via transaction code F-42. It is also possible to port the accounting document with FB01 (Post documents). And there are even greater risks, if the authorization objects values are not properly restricted on the account type, you can do not only post incoming payments for a vendor, but also for a customer and for the general ledger.
This is why I have decided to write an e-book about the SAP authorization concept and the logical and illogical aspects about it. If nobody is aware about the very large number of transactions and the exact purpose of each and every available transaction, but everybody still focusses on restricting and analyzing the transaction codes, then this causes problems if you want to restrict access in SAP systems. And the same goes for SOD conflicts. If you focus on the transaction codes, you cannot be 100% sure if you are defining a good rule set for the SOD conflicts.
Simplified example: the access to the critical functionality doing payments. Let’s define a rule to analyze if only authorized people are able to do a payment in a SAP system. So first of all we define the transaction with which you can do a payment: F110 – payment postings. And assign the authorizations that grant access to doing payments: F_REGU_BUK with action 21 and F_REGU_KOA with action 21. Now if we run this rule, the people with these transactions will get reported. But what if you are not using transaction F110, but have created a custom transaction ZF110 to do the payments? The real risk is not reported, because the people having the custom transaction and the authorizations will not be reported.
GRC - it is all about risk management. As we state in our e-book “The most difficult thing when auditing SAP security is to define the criteria you need when a user should be reported as user with access to a certain critical functionality (like “can update vendor master data”). The more criteria you use, the higher the risk that you will not find users who can do certain functionality. To analyze and mitigate the real risks you have to make sure the criteria to report risks (rule set) is correct. If the focus is on transaction codes, you have to make sure that all the transaction codes are covered in the rule set. There will always be transactions missing in the rule set, not only caused by the lack of knowledge of the purpose of all existing transactions, but also due to system limitations, because only a limited number of transactions can be covered in the rule set. And if the transactions are missing in the rule set, the risk will not be reported. And if a risk is not reported, this means that your GRC system is not reporting all risks. Also, the more criteria are used, the greater the risks of false negatives.
At CSI tools we simplify and focus on the core of SAP security, the authorization objects. With this approach, the risk is always reported, even if the transaction code is missing in the rule set.
This is why we now see that so many companies, that have already invested in very expensive GRC solutions, are nowadays using CSI tools to report the real risks. People get more and more convinced about the real risks and how to report them.