S 2.347 Regular security checks of SAP systems

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Auditor, Administrator, IT Security Officer

The security of an SAP system can only be guaranteed over the long term when the security is checked regularly. Checking the security helps to detect and eliminate misconfigurations and vulnerabilities.

Security checks should be performed at regular intervals by different people. For example, administrators should conduct brief checks relatively frequently (about once per month). It is recommended to create a checklist for these checks to guarantee that the scope of the checks performed is well defined. Minor problems detected during a check can usually be corrected immediately by the administrators and larger problems must be reported according to the process instructions. Security checks should be conducted by other internal roles (e.g. by someone in the IT Security or IT Audit departments) at medium-term intervals (several months). It may make sense to have checks conducted by external auditors at longer intervals. The following aspects must be taken into account when performing such checks:

Regularly researching security-relevant information

In general, administrators and the persons responsible for information security must inform themselves regularly on new issues and changes affecting the systems they are responsible for. In particular, the sources of information on SAP should be read regularly for this purpose.

See also S 2.346 Use of the SAP documentation.

Authorisations for audit users

The SAP user account used by the external auditor to examine the system configuration should be granted read authorisations only. The audit user must not be allowed to make changes. The audit user must not be assigned the SAP_ALL profile in the ABAP stack.

If the authorisations of the audit user cannot be restricted to read-only access, access must only be permitted according to the two-man principle.

SAP offers its own audit system (the Audit Information System or AIS) that allows auditors to examine an SAP system. This system provides different roles and authorisations by default that can then be assigned to the user account of the audit user. The roles available are generally designed in such a way that only read access is available. The roles can be viewed in the Profile Generator (transaction PFCG) using the "SAP*AUDITOR*" search term.

Configuring access to the AIS

The Audit Information System (AIS) can be used to perform the audits. Different versions of the AIS are available: the transaction SECR version and in the role-based version.

With the transaction SECR, it is possible to automate some parts of an audit. The AIS also allows for documenting the results of the check and storing the status of the audit (using traffic light colours for the status, i.e. red, yellow, and green).

It is recommended to define a subset of the audit capabilities offered (Top 10 Security Reports) and then conduct the corresponding audits. When auditing, the current configuration must be compared to the target configuration.

It must be noted that the AIS discloses critical system information. For this reason, access to the AIS must be restricted to the authorised auditors (S_TCODE, transaction SECR).

In contrast to the transaction SECR, the role-based AIS consists of predefined roles, authorisations, and programs allowing the assignment of authorisations to a a user necessary for an audit at the system and module levels. The focus in this case is placed mainly on business audits. The role-based AIS must be set up and configured accordingly.

Detailed information on this subject can be found in safeguard S 2.346 Use of the SAP documentation.

Checking for changes to the system change options

The settings of the system change options must be checked regularly. Transaction SE03 "Administration/System Change Options" can be used to perform this check. The global settings and the settings for each client must be checked in this case. Information on the system change options can also be found in S 4.258 Secure configuration of the SAP ABAP Stack.

It is not possible to configure the system change options for the Java stack using system settings.

Security Auditlog

The Security Auditlog contains security-relevant log entries. Therefore, this log must be evaluated regularly. Transactions SM20, SM20N, or RZ27_Security can be used for evaluation, although transaction SM20N should be preferred, since it offers an improved user interface. To be able to use transactions SM20 and SM20N, it is necessary to define the scope of the evaluation using transaction SM19 and enable the Auditlog (see also S 4.270 Logging of SAP events).

Profile parameters

The profile parameter settings should be compared to the planned target values (see also S 4.258 Secure configuration of the SAP ABAP Stack). The currently valid profile parameters can also be displayed directly using transaction SM20N. Alternatively, it is possible to generate the RSPARAM report using transaction SE38.

User information system

Audits should be performed regularly using the user information system (transaction SUIM). The following information is security-relevant in this case:

Reachable SAP Gateways

Transaction RSGWLST can be used to determine which SAP gateways of other SAP systems can be accessed by the SAP system. It displays connection and access capabilities. It is possible to view the settings in the "secinfo" file of the remote gateways that define the authorisations needed to connect to and register with the remote SAP gateway. In addition, it is also possible to check the destinations and the RFC server programs registered on the remote SAP gateways.

The assessment of the results requires corresponding technical knowledge. Since sensitive system information may also be requested using transaction RSGWLST, access to this transaction must be restricted.

The status of the SAP gateway of the local system can be checked using transaction SMGW (Gateway Monitor).

Checking the single sign-on (SSO) capabilities

Users can log on to an SAP system at first with valid authentication information (e.g. a user name and password or a certificate) and then access other SAP systems via the SSO mechanism without having to re-enter authentication information.

Transaction STRUST can be used to view the certificates of other SAP systems that allow SSO access from the local SAP system. Only trustworthy systems should be entered here. Alternatively, the examination can also be performed using transactions SSO2 or SSO2_ADMIN.

Regular examination of the authorisations

It is generally impossible to fully examine all authorisations manually, because there are simply too many. For this reason, a good authorisation concept is absolutely necessary. However, the authorisations must still be checked regularly to ensure they conform to the authorisation concept. Spot checks (see also "User information system" above) can also be performed in this case for important user groups. The authorisation concept must ensure that processes preventing users from accumulating authorisations are implemented.

In addition, tools can be used that offer integrated change and risk management so that the likelihood of a user being able to commit fraud due to authorisation problems can be reduced, for example. SAP provides the "SAP GRC Access Control" tool for this purpose, which checks the configured authorisations to determine if any users have been granted authorisations that are considered critical from a security perspective. Such examinations are usually only conducted within the framework of Sarbanes-Oxley, but generally make sense for any government agency or company. The examination must detect and display authorisations for transactions considered critical in this regard (for example SE80, SE16, SQVI; or critical authorisation objects for users such as S_PROGRAM, S_USER_GRP, S_TABU_DIS, S_RFC, S_USR_RFC). Similar tools for checking are also available from third party manufacturers.

Checking the up-to-dateness of the updates

The up-to-dateness of the updates installed on the SAP system must be checked. The transaction SPAM can be used to perform this check. The current patch status of the system must then be compared to the status of the patches available. This means that the auditor must know which patches are available from SAP.

The examination must also check for errors or warnings occurring during updates. It must be taken into account in this case that warnings may even arise when the update status is set to "green".

Checking the security of the communication interfaces

The security of the various communication interfaces (see also S 5.125 Protection of communication with SAP systems) should be checked. This includes, for example, the RFC, ICF, and ALE interfaces of the ABAP stack and the interfaces of the Java stack.

In particular, it must be determined which users have administrative authorisations and which services and functions are available.

Review questions:

© Federal Office for Information Security. All rights reserved.