This document discusses how to identify authorization checks for custom transactions in SAP systems in order to include critical custom transactions in the rule set for authorization auditing. It provides instructions for searching the transaction table (TSTC) to find custom transactions, checking transaction programs for AUTHORITY CHECK statements using transaction SE93 or report RSABAPSC, and identifying table authorization groups for parameter transactions by analyzing transaction views. The goal is to fine tune the GRC filter set to include checks for relevant custom transactions.

1. How to perform critical authorizations and SoD checks in SAP
systems
This blog describes how you can set up the Segregation of duties (SoD) analysis for the SAP security
concept. I compare 2 methods, The first one is using the standard SAP report RSUSR008_009_NEW and
the second one is using CSI Authorization Auditor 2014.
Method 1 Using Standard SAP report
It is possible to use the standard report RSUSR008_009_NEW to set up a basic SoD analysis in the SAP
system (figure 1).
Figure 1: Report RSUSR008_009_NEW
With this report is it possible to get an overview of users/roles having access to critical authorizations
and/or critical combinations (SoD conflicts). Before you can run the report, you need to define the rule
set first. The rule set contains critical authorizations and critical combinations. The critical
authorizations must be defined and after this is done, you can define the critical combinations. In this

2. example I will create a simple rule set for the critical authorizations to maintain customer master data
finance view. The transaction and corresponding authorizations are defined (figure 2).
Figure 2: Set up of critical authorizations in report RSUSR008_008_NEW
After the critical authorizations are defined, the report can be run and the results (users/roles having
access to the defined critical authorizations) are shown on the screen. A drill down functionality to see
how the user gets the access to the critical authorizations is unfortunately not possible (figure 3) and
the information if the transaction was executed by the user is also missing.

3. Figure 3: Results of critical authorizations user level
The report shows the assignment of the critical authorizations and does not show you the SoD conflicts.
To report the SOD conflicts, you have to define the critical authorizations first, followed by the critical
combinations. A critical combination (SOD conflict) is one or more critical authorizations combined
with AND logic (figure 4).
Figure 4: Definition of critical combinations in report RSUSR008_009_NEW
After the rule set with critical combinations is defined, the report runs and the users are shown. Once
again, a detailed analysis how a user gets the authorizations is not possible with this report and the
information if a user did really use the transactions of the SoD conflict is missing (figure 5). The

4. Definition of SOD conflicts is only using AND logic.
Figure 5: Results of critical combinations user level
Is it a useful report?
If the rule set if defined correctly, the report will give the overview of users having access to critical
authorizations. The critical authorizations can be defined with or without S_tcode value. However,
there are many cons why you should not want to use this report:
Creating the rule set for critical authorizations and/or critical combinations is very hard. If you
want to extend the rule set with your organizational values it will become very hard to implement
and can lead to thousands of rules. The rule set is local to each client so you have to define a rule
set in every single client. The rule set can be transported, but the rule set you want to use in the
development system will be a different one compared to the one in the production system.
Therefore you should not use the transport option; it will overwrite your rule set.
No pre-defined rule set can be used. You have to implement a rule set beginning from scratch.
Defining the rule set will be more time consuming and cost more than buying existing external
tooling.
When you apply support packs you don’t get updates for the rule set.
Running the report can take up a long time and is additional workload for the SAP server.

5. Creating the rule set is very hard, but maintaining the rule set will even be a more complex
task. Change management must be set up to the rule set maintenance and the authorizations to do
this must be restricted to the authorized users.
The results of the report are only useful for high level reporting. In order to analyze how a
certain critical authorizations or combination can be removed from a user, drilling down will not
give the needed information.
Documenting remediation, exceptions and compensating controls to mitigate the risks are not
possible.
The report will detect the issues from existing users; it will not prevent unauthorized
authorizations when assigning roles to users.
Who is responsible for the rule set and who is authorized to make changes to it?
SOD conflicts are only created with AND logic between critical authorizations.
Method 2: Using external tooling: CSI Authorization
Auditor
I will use CSI Authorization Auditor 2014 show how an external tool can be used for SoD checking. CSI
Authorization Auditor comes with a pre-configured rule set with all critical authorizations and over 400
pre defined SOD conflicts. Therefore the definition of critical authorizations and SOD conflicts from
scratch is not needed. This is a real time saver. The rule set can be adjusted to company values, like
customized transactions, authorizations, organizational levels, locked transactions, deactivated
authority checks et cetera. The organizational values like company codes, sales organizations, plants
et cetera can be easily added and used across the analysis. If you already have a pre defines rule set
for the SOd conflict and critical combinations, this can be imported into the tool as well.Changes to
the rule set are logged and can be restricted for changing. Additional information regarding the critical
authorizations like the risk, control objectives and suggested controls can be added to the rule set as
well. THeSOd conflicts can be defined with various logics like AND, OR and even NOT logic.
Figure 6 is an example of a pre defined critical authorization query, containing the critical
authorizations to maintain customer master data in the finance view. The query is defined with the
transactions (in the tab transactions) and the authorization values (in the tab authorization values).
You can also adjust the pre defined queries and create new ones if you would like.

7. Figure 6: Pre defined critical authorizations set up
Running the queries will show the users/ roles that have access to the defined critical authorizations.
The result also gives more detailed information like how the users get access, via which profiles and/or
roles. In the example picture below the yellow circles shows via which profiles/roles the transactions
are assigned, the blue circles in figure shows via which profiles/roles the authorization values are
assigned and if the user has executed the critical authorizations (red circles in figure 7). In this
example the user not did execute (any of) the transactions for customer master data maintenance:
XD01,XD02, XD99, FD02,FD05 or FD06.

8. Figure 7: Results critical authorizations with detailed information
To do the SoD analysis, a pre defined SOD rule set can be used or a new SOD rule set can be defined
from scratch. Defining the SoDruleset from scratch is very simple. Every critical authorization query is
stored in a library and via drag and drop you can add queries to a SoD conflict. Additional information
like the risk, recommendations, compensating controls, organizational levels that are applicable, et
cetera can be added as well (figure 8).

9. Figure 8: Definition of SoD conflict in CSI Authorization Auditor
After the critical combinations are defined, the audit can be done. The report will show the users/roles
having the SoD conflict together with very useful additional information; Is the conflict executed by the
user, via which role(s), profiles does the user gets the SoD conflict, is the conflict in the role itself, et
cetera.
Drill down detail reports (figure 9), high level reports, dashboards and trending reports are also
possible to get a clear overview of the progress of clean up (getting and staying compliant) . Because
the analysis is not done in the SAP system there is no additional workload for the SAP server.

10. Figure 9: Results of SoD conflict with detailed information
Conclusion
Defining the report RSUSR008_009_NEW will be a very time consuming and expensive job even if your
SOD rule set is quite basic. Running the standard SAP report will take quite some time and will be
additional workload for the SAP server. In the end it will be cheaper to buy an existing Security
concept analyzing tools that offer more value because of the analysis functionality to get in
compliance. Therefore I recommend to use external tooling like CSI Authorization Auditor.
Geplaatst door Meta op 13:30 Geenopmerkingen:
Dit e-mailenDitbloggen!Delen op TwitterDelen op FacebookDelen op Pinterest
vrijdag 27 december 2013
Who is doing what in your SAP system?
People who are using a SAP system all known the term transaction code. SAP data is restricted
using role based access controls. Users that get access to the SAP system via a Graphical User
interface (I include portal-like functionality just to keep it simple) and the restriction of SAP
table data for the users is managed by the assigned authorizations of this user. If users want to
have access to functionality in the SAP system, the transaction code is the front door to get
access to this functionality.
STAD data

11. SAP systems keep track of the transaction codes that were started by the users. This data is
stored in the so called STAD data. STAD data can be used for monitoring, analyzing, auditing
and maintaining the security concept. When analyzing the access restrictions to SAP
functionalities and Segregation of Duty conflicts, STAD data can be used to answer questions
like:
Who has performed a certain critical functionality? And When?
If a user has a critical Segregation of Duties conflict, did he actually perform this conflict?
Also for maintaining and monitoring the security concept the STAD data can be very helpful. It
will give the overview of the functionality (transaction codes) that a user did use. This
information can be used doing Reverse Business Engineering to decide which functionality the
user does and does not need.
SAP systems only stores a limited period of STAD data. The number of days/weeks/months that
the data is stored can be managed in the SAP system itself. The larger the period of the STAD
data is defined, the more storing capacity the server needs. To downsize this capacity it is
possible to make regular downloads of the STAD data and store this somewhere else. If this
download is extended to the same database every time, you can have a large period of STAD
data which is very valuable information.
Example of download STAD data
STAD data can be extracted from the SAP server(s) using the CSI Xtractor for example. This
tool uses a Remote Function Call connection from the computer to the SAP server and the user
logs on with his own SAP logon credentials (figure 1).
Figure 1 – Logon with user-id and password to make RFC connection to SAP system

12. After selecting the period, the tool makes the downloads and you have a STAD database with all
the STAD data from the SAP system (in this example I have created the database in Microsoft
Access).
Figure 2 - example of used transactions per user
Figure 3 – Example of transactions being used
This downloaded STAD data can be used by own reports/analysis. It is also possible to included
this database and data in detailed SAP security analyse tools like CSI Authorization Auditor to
analyze which transactions in a certain role were used by the user (figure 4) and of SOD conflicts
were executed by the user (figure 5)

13. Figure 4 – Example of transactions being used in CSI Authorization Auditor
Figure 5 – Example of SOD conflict with Executed (STAD) information
Geplaatst door Meta op 12:37 Geenopmerkingen:
Dit e-mailenDitbloggen!Delen op TwitterDelen op FacebookDelen op Pinterest
dinsdag 10 december 2013
Fine tuning your GRC filter set with Custom transactions
Sometimes it is necessary to create new (custom) transactions in the SAP systems. These customized
transactions should always be taken into account when doing an audit/analysis on the authorizations
concept.How to identify the authorization checks for these custom transactions?
Not all custom transactions will be very critical (hopefully). But how to make sure you are including the
critical ones in your analysis? First, have a look at the custom transactions that are existing. In the
table TSTC, all available transactions are stored.
1.Via Se16 -> TSTC

14. 2.Custom transactions will begin with the letter Y or Z.
2.
Search on the y* and z* transactions
3.You get the overview of all existing custom transactions
Not all custom transactions are critical, but the critical ones should be included in your analysis.
You can have a look at the name of the custom transaction via table TSTCT, but even custom
transactions with harmless names can be critical. So you have to go through every custom transaction
to see what it really is.
Once you have your list of critical transactions you want to include these in your rule set for auditing.
But how to check if authorizations checks are included into the custom transaction? Normally a
transaction can be secured by either having the authorization check included in the report itself, or by
calling another transaction. How to check if the custom transaction has authorizations check(s):
1.
Transactions that are secured via Call transactions and/or authority checks
Via SE93 Enter the custom transaction and click button Display (example below is for transaction
FD01)

15. 2.
Double click on the program
3.
This will show the program (ABAP code). Open the Find option
4.
Enter auth and search the main program

16. 5.
This will give you the AUTHORITY CHECKS as result.
Hint: Double click on the line to see the details of the statement

17. 6.
7.
Should you not find any results, it is possible that the transaction will call another transaction and it
will inherit the authorization checks from the called transaction. Check for “transaction” instead of
“auth”
When the custom transaction calls another transaction, double click on the transaction

18. 8.
Repeat steps 3-7 to find the authorization checks for this new transaction.
Report RSABAPSC
There is a report in SAP that shows the AUTHORITY CHECKS statements in the program code of a
(custom) transaction. How to search if the ABAP program has “AUTHORITY CHECK” statement
implemented using this report
1. VIA SA38 -> report RSABAPSC
-
2.
This program will trace the AUTHORITY-CHECK command that are defined in the program (ABAP code)
of the custom transaction and will include the search in underlying sub programs. The recurrence level
can be specified, “5” is de default value.
In the example below I did a search on the AUTHORITY-CHECK values for the(not custom) transaction
F110.
Parameter transactions
Some custom transactions will be used to maintain a certain table and will be defined as a parameter
transaction. In this case, the authorization check on the table authorization group must be
implemented (object S_TABU_LIN). How to check this?
1. Via SE93 enter the transaction and the result will look like

19. 2. When the custom transaction code is a parameter transaction, the authorization group for table
should be added. Scroll down and copy the view name.
3. Search which table authorization groups are assigned to the view
Transaction SE11. Enter the view name and click the button display
4. The related tables for this view are shown in the sheet tables/ join conditions
5. Via Utilities -> Assign authorization group you can see the assigned table authorization groups for
this view

20. The table TDDAT gives the relations between tables and table authorization groups.
http://www.csi-tools.com/meta-s-blog