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

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

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)

Figure 4 – Example of transactions being used in CSI Authorization Auditor

Figure 5 – Example of SOD conflict with Executed (STAD) information
(C) Meta Hoetjes 2014 
CSI Authorization Auditor and CSI Role Build and Manage are registered trademarks by CSI Tools bvba
www.csi-tools.com

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

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):

-          Transactions that are secured via Call transactions and/or authority checks

1.       Via SE93 Enter the custom transaction and click button Display (example below is for transaction FD01)

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

5.       This will give you the AUTHORITY CHECKS as result.

Hint: Double click on the line to see the details of the statement

6.       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”

7.       When the custom transaction calls another transaction, double click on the transaction

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

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

The table TDDAT gives the relations between tables and table authorization groups.
(C) Meta Hoetjes 2014 
CSI Authorization Auditor and CSI Role Build and Manage are registered trademarks by CSI Tools bvba
www.csi-tools.com

Display roles - are they really display only?

Sometimes I come across roles within the SAP system that are setup and assigned as a display role. However, when further analyzing the roles it seems that the roles are not really display roles (any more). The first focus while setting up display roles is probably removing the non display ACTVT values for the corresponding authorization objects. The list of ACTVT values and meaning of the values can be found in table TACT.

No * value  and no non-display values should be given to the ACTVT value in a display. This seems logical, but sometimes only the 01 and 02 values are removed and the other critical (*) values are forgotten.

ACTVT is used by many authorizations object. The list of these objects can be found in table TACTZ.

ACTVT however is not the only authorization field that should be changed to display values, there are others as well like PPFCODE, AUTHC in HR and JOBACTION in Basis. Make sure the values that are assigned to the object fields are really only display. And while testing the role, make sure you perform both positive and negative testing.

And last, if you assign multiple  roles to one user, make sure the combination of the display role and non display roles gives not broad access rights.

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

User type reference not always taken into account

We are all aware that different type of user types exists in the SAP system (http://help.sap.com/saphelp_nw04/helpdata/en/3d/3272396ace5534e10000000a11405a/content.htm).

I find the use of reference users a bit "tricky" and my experience is that this user type is not always investigated properly during an authorization analysis.

What are reference users:

Reference user type 'L'

Authorization enhancement

No logon possible.

Reference users are used for authorization assignment to other users.

Usage: Internet users with identical authorizations

Using reference users has it benefits, if a user is assigned to a reference user, it inherits the authorizations from this reference user. This can be  helpful with Employee Self Service users for example.

However,  the link to the reference user isnot always in your SAP report (via SUIM or table agr_users).

There are some reports in SUIM that will give you the link between a user ID and the reference user (like users by complex selection criteria (S_BCE_68001400)

Please be aware that  not all SUIM reports will make the link to the reference user

Also bare in mind that the table AGR_USERS will not show the user with the authorizations from a reference user will (therefore you won't see what roles are assigned to the user via this reference user).

How to search for the usage of reference users (this action can be part of your periodic authorization review)

1. Check if reference users are existing in your system (like SE16->URS02 usertpe L)

2. If they do exist.

2a.Check the assignment of authorizations to this reference user

2b.Check the assignment of users to this reference users (via S_BCE_68001400)

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

SAP Special users

SAP NetWeaver AS ABAP creates the standard users SAP*, DDIC, EARLYWATCH, TMSADM, and SAPCPIC during the installation process. The standard users are protected by defaults passwords. Nowadays, most companies are aware of this and will change this default password(s) and implement security procedures for these users.
SAP recommends to take the following action securing the users:

• Maintain an overview of the clients that you have and make sure that no unknown clients exist.
• Make sure that SAP* exists and has been deactivated in all clients.
• Make sure that the default passwords for SAP*, DDIC, and EARLYWATCH have been changed.
• Make sure that these users belong to the group SUPER in all clients.
• Lock the users SAP*, DDIC, and EARLYWATCH. Unlock them only when necessary.
•  Delete SAPCPIC if you do not need it. At least make sure that you have changed the default password for SAPCPIC.
•  Change the default password of TMSADM. 
  for more information, see Changing the Password of User TMSADM.

I agree these actions need to be taken to provide a minimum level of security for these users. But is this really enough?

I would recommend to spend some time analyzing the usage of these users. This can be done via additional security audit software and/or combined with the security audit log.
You might be surprised with the results. In many cases we could see that a SAP standard user was being used for logging on to the system via interfaces or running background jobs that nobody knew of.

Then the fun part starts: answering the "what" and "why" questions and clean up/document everything......
Be warned, this might take some time!
Good Luck!

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

Holiday season!

Holiday season is coming! That means business will have to continue as usual, but hopefully you will be able to leave for some days/weeks/months/....
Not all positions need to be replaced during holiday absence probably, but I can imagine there are some activities that needs to be done, like authorization maintenance and the company will hire a replacement employee.

I don't know if you know the statistics of authorization requests within your company? Often you can see there is a increase of authorization requests if the  authorization/security manager is on Holiday. Why is this the case you might wonder? Is there a new project with new functionality being implemented? Possible..... but maybe people are just testing the knowledge/experience of the replacement employee and are trying to get the authorizations that where rejected in the past.

If the knowledge and experience of the replacement employee is ok and the internal procedures (like  Segregation Of Duties checking, change management procedures with approvals, analysis tools, etc.) are set up and working correctly there might be no issues at all. But please keep in mind... when the cat is away, the mice play!


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