In our previous articles we’ve already provided you the list of the 9 most important business application security critical issues [1],  covered patch management flaws [2], present the information about default passwords for access to the application [3], told about numerous unnecessary functions [4], open remote management interfaces [5] and security settings that do not fit into any of the critical issues groups [6].

Sixth critical issue. Access control and SOD conflicts. Few would try to argue that the SAP is immune to security system attacks and sensitive business data is well protected from the actions of adversaries. But now you have a chance to get to know about some of the basic operations one can perform to rise the SAP information security to a higher level. The goal of ERPScan team is to help IT personnel make critical decisions when identifying technologies and strategies to increase security in business. ERPScan team publishes a variety of original content, written by IT professionals as a way to increase infosec specialists’ productivity around the world. Today, we’re going to speak about the sixth critical issue (see the list of critical issues in our first article) and the steps related.

There are a lot of various functions in the SAP system implemented through programs, transactions and reports. It’s essential that access to those objects must be restricted by means of setting up various authorization values that would define the types of users and objects allowed to have access as well as the ways to get access. In case users are allowed to perform critical actions, they can attack the SAP system, risen their privileges or steal critical data. Typical example, a user can have access to transaction that changes access rights or access to the transaction that allows a user to read any table.

Segregation of Duties (SoD) is a method of protection that prevents conflict of interests or, in other words, having two or more access rights. The matter is, if they are granted together this can lead to fraud actions. A classic illustration here would be having right to create Payment Order and at the same time having right to approve it. Thus, the SoD helps to segregate incompatible responsibilities.

In this article only 5 security check steps will be given, but those are the main access control checks having to do with the most critical access rights and the related settings. For the reason that Segregation of Rights is based on the business processes of each particular company and as usual it is developed individually, we will not describe relevant to the SoD security checks in the present article.

Further steps

There are at least 100 critical privileges solely in the SAP BASIS that we we’ll talk about here, as well as the number of rights in each module is approximately the same. As has been already mentioned, sometimes these privileges overlap each other and it is the SoD matrix that is responsible for that. A standard matrix contains more than 200 different SoD patterns, while each company can additionally use their own ones.

As a further step you can choose to get critical access rights from the the ITAF regulatory document by the ISACA [7] or from the Deutschsprachige SAP Anwendergruppe DSAG standard [8]. Then, you should reconfigure the SoD. The best thing to do here, before starting the analysis of duties segregation, is to find out whether there are wildcards “*” in the access rights’ authorizations values.

[EASAI-NA-20] The check for accounts with SAP_ALL profile Description


The SAP_ALL profile is a composite profile. It contains all the privileges for the SAP system including main administering functions and application settings. In accordance with the segregation of duties principle, this profile has no practical use.


A user that has the SAP_ALL profile privileges can perform any actions within the system. In case authentication data of the SAP_ALL profile user was compromised, an intruder can get an unrestricted access to any business data as well as to the critical business processes.


  • User privileges should be specified according to the least-privileges principle.
  • The SAP_ALL profile should be used in case of emergency only.
  • You should create only one user with such profile (for emergencies) and keep this user’s password in secret. Instead of using the SAP_ALLprofile, it’s better to distribute this profile’s privileges between the appropriate positions. For example, instead of granting a system administrator all the SAP_ALL privileges, you should grant him only the authorizations relevant to system administering, in particular S_*. These authorizations will grant a system administrator enough privileges to administer the entire SAP solution, preventing him from performing tasks in other areas, such as, for instance, HR management.

[EASAI-NA-21] The check for accounts that may start any programs


If additional access control for particular programs was not implemented, a user authorized to run programs can start any program. That, in turn, happens very often, especially in client programs. To control access to programs, authorization groups are created. Each authorization group corresponds to several ABAP programs. Users can start only those programs that are included in the authorization groups assigned to their profiles.
So, users having the following critical access should be checked:

  • The SA38 transaction. It is used to execute programs and reports within the system;
  • The SE38 transaction. It is used to look through the programs’ source code and to develop/debug them;
  • The SE37 transaction. It is used to start function modules;
  • The SE80 transaction. It is used to edit any objects being under development (i.e. in ABAP editor).


Those users who are allowed to run any program have an unrestricted access to all system functions and can severely damage the system, as far as there are more than 30K various programs that can perform almost any action, be it user account creation and OS command execution or paying for goods and modification of salaries.

If there is no control, any user having authorization object S_PROGRAM assigned to him and access to SA38 or SE38 can execute any program. Furthermore, with access to SE37 one can start any function module, to SE80 – perform editing of any objects being under development.

Editing and running of some programs can cause a risk that the program will send back inaccurate or incomplete information. Besides, if a user is allowed to start SE38 transaction, it can lead to unauthorized program modification that can impact system integrity.


  • Minimize the number of users with these privileges, roles should be assigned according to the least- privileges principle.
  • Its important, to add into the most critical programs additional authorization checks, by means of modification of their source code.
  • Besides, you should regularly review the policies, procedures and criteria used to specify authorized groups for the programs that are being created.

[EASAI-NA-22] The check for accounts with the privileges to modify sensitive tables with passwords


USR02, USH02 and USRPWDHISTORY are standard tables for the SAP-system, that contain sensitive user data. Those are, for example, usernames, password hash, user types, client ID, etc.
For access control over these tables, users with the following authorizations should be monitored:
For the SAP NetWeaver version with S_TABU_NAM authorization object support:


or (for all other versions):



Those users that have access to the listed tables have right to change password hash of any user. Thus, they can login the system under any account.


The number of users with access to USR02, USH02, USRPWDHISTORY tables must be restricted based on the business needs. The roles should be assigned according to the least-privileges principle.

[EASAI-NA-23] The check for accounts that may execute OS commands


For the SAP solution to interact with the host OS, there are specific mechanisms that manage interaction with external OS commands. Those OS commands can be executed by means of transactions defined in the SAP system. Moreover, only the users that have particular privileges can execute them.

The SM49 transaction allows to execute any external command (related to the OS). The SAP solution contains a detailed information for each external command,including the OS commands themselves, preset parameters and the information about whether additional parameters are permitted.

Users executing external commands should have authorization object S_LOG_COM assigned to them. The S_LOGCOM_ALL authorization object (based on S_LOG_COM) allows execution of all commands included in the S_A.SYSTEM and S_A.ADMIN standard authorization profile sets.

To control external commands, the SM69 transaction is used. It allows to modify them and to install additional security controls. The user should be granted with the S_RZL_ADM authorization object with the Activity value set to 01 in authorization profile.


The users that may execute or modify OS commands potentially can start critical OS commands and may damage the system.

Not being controlled, any user with access to SM49 or SM69 transactions (and access to S_LOG_COM or S_RZL_ADM authorization objects) can execute external OS commands of a SAP solution. There is also a risk that some commands after being edited or run will send back inaccurate or incomplete information. Besides, if user was allowed to start the SM69 transaction, this can lead to unauthorized command modification, which in turn can have a negative effect both on the OS and SAP solution integrity.


  • Minimize the number of users with these privileges, roles should be assigned according to the least- privileges principle.
  • Block these transactions and unlock them if necessary during utilization.
  • Besides, perform regular review of policies, procedures and criteria associated with authorization group set up for new programs.

[EASAI-NA-24] Check for disabled authorizations


Authorization checks are used each time when it is necessary to verify whether the user has appropriate rights to perform certain actions.

Checks of particular authorization values can be disabled at the system level. The check is not carried out if a system administrator has disabled authorization object check intentionally for the particular transaction (using SU24 and SU25 transactions). This could be useful, as while a transaction is being executed many authorization objects are being checked in a background mode as well.

To make those checks successful a user should have corresponding authorizations. As a matter of fact, some users have more authorizations than necessary. These authorizations along with some others may grant a user additional (extra) privileges and increase the workload. On the other hand, disabling authorization checks is risky as this means that system access defense mechanisms will also be disabled.To enable authorizations implemented by means of SU24/SU25 transactions, set the AUTH/NO_CHECK_IN_SOME_CASES profile parameter to Y (with RZ10 transaction). This setting is used by default in newer version of BASIS. This parameter allows to disable authorization check for individual transactions.


The absence of critical authorizations check can result in unauthorized critical actions performing to the system. Resulting from this, system efficiency will lower and fraud actions will become possible. Besides, such disabled authorization checks may indicate a backdoor in the system.


It is recommended to verify necessity of disabling authorization check for system authorization object in a particular program, transaction or RFC-function. Analyse program names, transactions or RFC-functions with system authorization objects where authorization check is disabled. Technically, disabled authorizations are marked in the USOBX_C table (a validation table for the USOBT_C table) with OKFLAG = N field value.

Authorization checks for corresponding authorization objects should be disabled only for the particular transactions and for the period of their execution.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Julius von dem Bussche

    As a side comment, S_TABU* authorizations to change USR02 etc is useless as these application tables do not have table maintenance dialogs.

    The auth/no_check_in_some_cases = Y is a correct setting as it enables PFCG. You cannot disable checks for RFC and PROG and HS etc type objects. Only for S_TCODE contexts and then it is very useful and widely used to permit API calls from subledgers to authorize indirect postings to main ledgers without being authorized to access them directly. The “old” solution was contextless and offered an import parameter to disable checks, which is much worse… -> if you set this parameter to N, then you will create a very big mess!

    Please be careful of (security) advise found in the internet without testing it yourself!




Leave a Reply