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. Now you have a chance to learn about some of the basic operations one can perform to bring the SAP information security to a higher level. The goal of the ERPScan team is to help IT personnel make critical decisions while identifying technologies and strategies to increase the cybersecurity in the business. The 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 related steps.
There is a number of various functions in the SAP system implemented through programs, transactions, and reports. The access to these objects must be restricted by means of setting up various authorization values. They should 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, escalate their privileges or steal critical data. A typical example is that 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 the protection that prevents conflicts 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 would be having a right to create Payment Order and simultaneously to approve it. Thus, SoD helps to segregate incompatible responsibilities.
In this article, only 5 security check steps will be given, but they are the main access control checks dealing with the most critical access rights and the related settings. Since 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.
There are at least 100 critical privileges only in the SAP BASIS that we’ll talk about, as well as the number of rights in each module is approximately the same. As 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.
As a further step, you can choose to get critical access rights from the ITAF regulatory document by the ISACA  or from the Deutschsprachige SAP Anwendergruppe DSAG standard . Then, you should reconfigure SoD. The best thing to do in this case is before starting an analysis of the 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
The SAP_ALL profile is a composite profile. It contains all the privileges for the SAP system including the 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 the 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.
- It’s recommended to create only one user with a profile for emergencies and keep this user’s password in secret. Instead of using the SAP_ALL profile, 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 give them 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 the additional access control for particular programs was not implemented, a user that is authorized to run programs can start any program. That, in turn, happens very often, especially in client programs. Authorization groups are created to control the access to programs. Each authorization group corresponds to several ABAP programs. Users can start only these programs that are included in the authorization groups assigned to their profiles.
It means that the 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).
The 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 (includuing user account creation, OS command execution, 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 the development.
Editing and running some programs can cause a risk of sending back inaccurate or incomplete information by the program. Besides, if a user is allowed to start SE38 transaction, it can lead to an unauthorized program modification that can impact the system integrity.
- Minimize the number of users with these privileges, roles should be assigned according to the least- privileges principle.
- It’s important, to add additional authorization checks into the most critical programs, by modificating 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, for example, usernames, password hashes, user types, client ID, etc.
For the 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:
- S_TABU_NAM:TABLE=USR02 or USH02 or USRPWDHISTORY;
or (for all other versions):
The users that have access to the listed tables have right to change the password hash of any user. Therefore, they can login the system under any account.
The number of users with access to USR02, USH02, USRPWDHISTORY tables must be restricted with regard to 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 the interaction with external OS commands. These 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 executing 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.
The SM69 transaction is used to control external commands and allows modifying them and installing 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 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 the user was allowed to start the SM69 transaction, this can lead to an unauthorized command modification, which in turn can have a negative effect both on the OS and on 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 the utilization.
- Besides, perform regular review of policies, procedures and criteria associated with the authorization group set up for new programs.
[EASAI-NA-24] The check for disabled authorizations
Authorization checks are used each time when it is required to verify whether a 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 an 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 implement these checks successfully, 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 the authorization checks is risky as 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 disabling authorization check for individual transactions.
The absence of critical authorizations check can result in unauthorized critical actions performing to the system. Consequently, the system efficiency will lower and fraud actions will become possible. Moreover, such disabled authorization checks may indicate a backdoor in a system.
It is recommended to verify the necessity of disabling authorization check for system authorization object in a particular program, transaction or RFC-function. Analyze program names, transactions or RFC-functions with system authorization objects where an 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.
That’s it for today’s article, we hope you like our work. If you do, check out our new product [link].