S 4.258 Secure configuration of the SAP ABAP Stack

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

The ABAP stack is the traditional execution environment of an SAP system. This applies especially to the system versions generally referred to using the term SAP R/3, since the R/3 components and modules are executed in the ABAP stack.

The initial configuration of the ABAP stack is complex and consists of many individual steps. The complexity increases when applications and modules need to be configured in addition to specifying the configuration of the SAP Basis, which is necessary in R/3 systems. In these systems, all relevant government agency or business processes must be modelled by configuring (customising) or modifying the ABAP code.

The following describes the most important steps that need to be performed when specifying the initial configuration of the ABAP stack from a security perspective. The descriptions are limited to the configuration of the SAP Basis and do not address the configuration of the modules or applications.

Specifying clients for operations

First, a client must be specified for the operation of the SAP system. A client is understood to be a technical subcomponent in an SAP system. This term should not be confused with clients in the sense of customers. The existing standard clients numbered 000 (SAP reference client), 001 (production preparation client), and 066 (early watch client) must not be used after installation.

An SAP system may contain several clients serving a variety of different purposes. However, all clients in an SAP system are interconnected through the SAP reference client that is used to perform configurations that apply globally to the entire SAP system.

From a security perspective, it should be ensured that clients with very different security requirements are not operated together on a given SAP system. For example, a productive client should never be operated together with a development client on an SAP system. If they were to be operated together, developers would also be able to change client-independent objects, which would have direct effects on the productive clients. For this reason, it is absolutely necessary to separate these clients.

Performing IMG tasks relevant to security

The SAP Implementation Guide (IMG, SAP Reference IMG) is an internal system list pre-defined by SAP containing the configuration steps necessary to configure an SAP system. The list is organised hierarchically and adapted to the system version used and the components installed. In addition, it is also possible to create your own IMGs (project IMGs) containing only those configuration steps from the SAP Reference IMG actually necessary for the system to fulfil its purpose. IMGs also offer the ability to record which configurations have already been performed so that the current configuration status can then+ be stored this way.

S 2.346 Use of the SAP documentation contains information regarding the SAP IMG documentation that must be taken into consideration. All IMG tasks specified during the planning phase (see also S 2.341 Planning the use of SAP) must be executed to completion.

The following IMG tasks must always be performed:

The IMG tasks performed will also affect the safeguards described in the following, amongst other things. They are listed here explicitly, since they are highly relevant from a security perspective.

Customising profile parameters

Profile parameters are used to configure the basic functions of an SAP system. For this reason, the profile parameters must be adapted to the requirements during configuration. Since several types of profiles are available (for example, the start profile, default profile, and instance profile), the administrators must be familiar with the profile mechanism.

In general, the setting to be used must be specified for each individual profile parameter. Special attention must be paid to the following parameters from the point of view of security:

Transaction RZ10 should be used for profile administration. Manual changes should not be made at the file system level. To display the profile parameters, it is also possible to use the RSPARAM report, which can be called using transaction SE38. The profile files must be protected at the operating system level against unauthorised access.

References to detailed information on how to handle profiles can be found in S 2.346 Use of the SAP documentation.

Configuring system change options

The system change options must be set according to the role assumed by the SAP system. These settings specify whether or not changes are allowed in general to internal system components and application components. For example, this affects the ABAP system code, usually all objects in the Data Dictionary (DDIC), as well as the object name space.

For productive systems, it is recommended to set the system change options globally to "Not modifiable". This means changes can only be made by installing them using the transport system. This is desirable for productive systems so that changes can only be made using defined procedures and workflows. It is important here to define and maintain a proper change management process (see S 4.272 Secure use of the SAP transport system).

The settings for test and quality assurance systems should be the same as the settings for the production system, i.e. set globally to "Not modifiable". Changes must be made in the development system and then transported to the quality assurance system and ultimately to the productive system after they have passed the quality assurance tests.

In development systems, the components not affected by the development should be set to "Not modifiable". However, the components currently under development must be set to "Modifiable".

The settings of the system change options can be displayed using transaction SE06 or SE03.

References to detailed information on this subject can be found in S 2.346 Use of the SAP documentation.

Specifying client configurations

In addition to the change options which apply to all clients of the SAP system, it is also possible to protect individual clients against changes to client-dependent properties. This setting should be used on all productive clients. These settings also determine whether or not changes to the clients are logged automatically so that the changed settings are available immediately after checking as a transport request and can be transferred to other clients to be operated using the same settings.

The change management concept must specify which scheme will be used to deploy changes in the clients and which clients are used for what purpose (e.g. if the client is a productive client, test client, or development client).

The settings are specified using transaction SCC4. The following settings are recommended for the organisation's own productive clients (note: the abbreviations of the names of the values for the settings are the same as those used in the SAP system.):

These settings should also apply to the test and approval systems. The settings must be defined appropriately for other clients (i.e. for the development, training, and demo clients).

Administrators must be very familiar with the effects of changes to client configurations. References to the corresponding detailed documentation can be found in S 2.346 Use of the SAP documentation.

Securing executable operating system commands

The ABAP stack can be used to execute operating system commands. When the commands are executed, they are executed using the operating system rights of the technical operating system user under which the SAP system is running. In general, this user has wide-ranging administrator rights.

Access to this functionality therefore needs to be secured. In particular, the creation or modification of commands must be prevented. For this reason, the following recommendations should be implemented:

References to detailed descriptions of how to secure the operating system commands can be found in S 2.346 Use of the SAP documentation.

Ensuring password quality

The following information must be taken into account in order to ensure the quality of the passwords used to access the SAP system.

A minimum password length should be defined. The profile parameter "login/min_password_lng" can be used to set this value. A value of 8 characters is recommended. This value is also the maximum password length for the ABAP stack.

Complexity criteria should be defined for passwords. The criteria can be set using the following profile parameters:

When defining the complexity criteria, it must be ensured that the rules specified are consistent.

A maximum validity period should be defined for passwords so that users are forced to change passwords regularly. This value is configured using the profile parameter "login/password_expiration_time" , which specifies the number of days after which the password needs to be changed. It is recommended to set it to a value between 60 and 90 days.

Prohibited passwords may also be defined. These passwords are usually maintained in table USR40 using transaction SM31. The use of typical trivial passwords should be prohibited in this manner.

The values selected must conform to the rules of the valid password policy.

Configuring protection against password attacks

It is recommended to protect the SAP system from password attacks by disconnecting a user after a certain number of failed login attempts. The number of failed login attempts is configured using the profile parameter "login/fails_to_session_end".

To protect user accounts repeatedly subject to attacks from further attacks, it is recommended to lock the user accounts after a certain number of failed login attempts. This number is configured using the profile parameter "login/fails_to_user_lock".

Furthermore, it is necessary to decide if locked user accounts will be unlocked automatically at midnight or if the user administrator needs to unlock these accounts manually. This is configured using the profile parameter "login/failed_user_auto_unlock".

The values selected must conform to the rules of the currently valid password policy.

Preventing multiple logins

SAP systems can prevent several users from using a single user account simultaneously. In general, multiple login sessions by the same user are not useful in productive systems and therefore should be prohibited. The response of the system can be configured separately for SAPgui and RFC sessions and is defined using the profile parameters "login/disable_multi_gui_login" and "login/disable_multi_rfc_login".

Before prohibiting multiple logins via RFC, it must be ensured that it is impossible to have parallel sessions started using the same technical user account.

Securing configuring single sign-on

If several SAP systems are operated, the user login procedure can be simplified using the SAP single sign-on (SSO) mechanism. When single sign-on is used, it is no longer necessary to re-enter a password, because a single sign-on ticket is issued by the SAP system upon successful login, with this ticket allowing access to other SAP systems without having to log in again. Whether or not the single sign-on mechanism will be used, and if so, between which SAP systems it will be used, must be specified in the planning phase.

Consideration must be given to the following security-relevant aspects if single sign-on is used:

The following profile parameters control the SSO configuration of an SAP system:

Additional administrative tasks must be performed to configure SSO that can be managed using transactions SSO2, SSO2_ADMIN (SSO2_ACL), and STRUSTSSO2. SAP recommends the use of transaction SSO2.

References to detailed information on this subject can be found in S 2.346 Use of the SAP documentation.

In addition to the SAP SSO mechanism using tickets, it is also possible to use external systems for SSO. However, these systems then need to be integrated using the SNC (Secure Network Communication) interface. For Windows-based environments (Windows 2000 and higher), please note the option of using single sign-on via Kerberos. In this case, the user only needs to log in to the Windows system. The user no longer needs to enter a user name and password to access the SAP system. The Windows Kerberos SNC Provider is a standard component and is available free of charge. It must be noted, though, that the Windows Kerberos SNC Provider does not offer encryption mechanisms for communication. For this reason, only SNC-based authentication is available. In Windows 2000 and higher, though, it is possible to use IPSec (a standard component) between computers and utilise encryption mechanisms for communication. Whether or not this variant can be used as a single sign-on procedure in a given company or government agency must be decided on a case-by-case basis.

Additional safeguards for SNC can be found in S 5.125 Protection of communication with SAP systems, and the sources of information on SAP found in S 2.346 Use of the SAP documentation.

Review questions:

© Federal Office for Information Security. All rights reserved.