Close

HAVE QUESTIONS?

A partner account manager can help. Contact us today.

 Subscribe me to your mailing list

SAP NetWeaver ABAP Security Configuration Part 7: Access control and SOD conflicts.

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 cybersecurity 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 a 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'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 ITAF regulatory document by the ISACA [1] or from the Deutschsprachige SAP Anwendergruppe DSAG standard [2]. 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

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.

Threat

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.

Solution

  • 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_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 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

Description

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

Threat

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.

Solution

  • 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

Description

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:

  • S_TABU_NAM:ACTVT=02;
  • S_TABU_NAM:TABLE=USR02 or USH02 or USRPWDHISTORY;

or (for all other versions):

  • S_TABU_DIS:ACTVT=02;
  • S_TABU_DIS:DICBERCLS=SC.

Threat

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.

Solution

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

Description

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.

Threat

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.

Solution

  • 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

Description

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.

Threat

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.

Solution

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.

That's it for today's article, we hope you like our work. If you do, check out our new product [link].