APP.4.2 SAP ERP Systems

The SAP ABAP stack MUST be configured securely. For this purpose, the respective profile parameters MUST be set (e.g. for password security, authentication, and encryption). The system change option and the clients MUST also be configured, IMG customising carried out, and the operating system commands saved.

The SAP Java stack MUST be configured securely if it is used. Security mechanisms and concepts that are different from the SAP ABAP stack MUST be created for this. Administrators MUST therefore know the architecture of the Java stack and how it is administered. In addition, unnecessary services MUST be shut down, standard content removed, HTTP services protected, and access to administration interfaces restricted.

To guarantee network security, appropriate concepts MUST be created that factor in the SAP ERP system and the settings made therein.

Furthermore, the SAP router and SAP Web Dispatcher SHOULD be used to implement and maintain a secure SAP network.

In order to avoid vulnerabilities due to misinterpretations or misunderstandings, the IT Operation Department, firewall operations, portal operations, and SAP operations MUST be coordinated.

Immediately after installing an SAP ERP system, the default passwords for the standard user IDs MUST be changed. Suitable safeguards MUST also be taken to secure the standard SAP user IDs that have been set up. Certain standard user IDs MUST NOT be used (e.g. for RFC connections and background jobs).

SAP user administration for ABAP systems MUST be undertaken in a secure and careful manner. Activities such as creating, changing, and deleting users; resetting and unlocking passwords; and assigning roles and profiles MUST be part of user administration.

A user and access control policy MUST be developed and implemented for SAP ERP systems. The following points MUST be considered:

• the identity principle, minimum principle, job principle, document principle of accounting, document principle of authorisation administration, segregation of duties principle (SoD), approval principle, standard principle, written form principle, and control principle MUST be taken into account.
• User, authorisation, and profile administrators MUST have separate responsibilities and authorisations.
• Procedures MUST be defined within authorisation administration for creating, changing, deleting, and transporting roles, as well as for transporting SU24 default values. Authorisation roles SHOULD be created and maintained in the development system. They SHOULD be transported using the Transport Management System (TMS). Authorisations SHOULD be created, saved, and assigned to the users in authorisation roles (PFCG roles) in a role-based access control policy. Since individual critical actions in the roles cannot always be avoided, they SHOULD be covered by mitigation controls.
• Within the framework of the access control policy, procedures MUST be defined for the request, approval, modification, and deletion of users and authorisations.
• Naming conventions MUST be defined for user IDs and technical role names.
• Default values and check indicators SHOULD be maintained in transaction SU24. The corresponding procedure SHOULD be described in the user and access control policy.
• Legal and internal framework conditions such as the German Generally Accepted Accounting Principles (German GAAP), the German Commercial Code (HGB), and the organisation's internal specifications MUST be taken into account. The user and access control policy SHOULD also cover the operation of technical accounts, including the authorisation of background and interface users.

Appropriate control mechanisms SHOULD be applied to check for SoD conflicts in roles and monitor the assignment of critical authorisations to users.

If components such as SAP HANA and SAP NetWeaver Gateway (for Fiori applications) are used in addition to the ABAP back end, the design of the authorisations among the components MUST be coordinated and synchronised.

Access to SAP databases MUST be secured. Whenever feasible, administrators SHOULD only be able to access the databases with SAP tools. If third-party software is used for this purpose, additional security safeguards MUST be implemented. The users SAPR3 or SAP<SID> MUST NOT be used to connect to databases. In addition, the default passwords (e.g. for SAPR3 or SAP<SID>) MUST be changed and certain database tables (such as USR* tables) placed under special protection.

To protect the Remote Function Call (RFC) interface, RFC connections, RFC authorisations, and RFC gateways MUST be configured securely.

Uniform administrative guidelines MUST be created and implemented for all RFC connections. For this purpose, the required RFC connections SHOULD be defined and documented. Connections with a stored password SHOULD not be configured from lower- to higher-privileged systems (e.g. from Dev to Prod). RFC connections that are no longer used MUST be deleted.

All RFC gateways MUST be securely administered and suitable profile parameters MUST be set (e.g. gw/monitor, gw/reg_no_conn_info and snc/permit_insecure_start). All connections that are established via a gateway MUST be analysed and evaluated in terms of their security. Furthermore, logging MUST be enabled. Access control lists (ACLs) MUST be defined.

The message server MUST be secured by appropriate settings in the profile parameters. Among other things, it MUST be decided whether ACLs are to be set up for the internal message server. The message server MUST be monitored using appropriate mechanisms so that system failures on the message server are detected quickly (for example).

When installing an SAP ERP system, current SAP security guides and documentation SHOULD be taken into account. In addition, the security policy of the organisation at hand SHOULD be observed. It SHOULD also be ensured that the SAP ERP system is to be installed on a secure operating system.

Technical authorisations SHOULD be developed on the basis of technical specifications. Furthermore, SAP authorisations SHOULD be adapted or created anew on the development system of the SAP landscape under consideration. In cases involving S/4HANA, this SHOULD also include authorisation development on HANA databases. Repository roles SHOULD be set up and transported, as well. Database privileges SHOULD NOT be assigned directly to users.

For software developed in-house (e.g. for transactions or authorisation objects), transaction SU24 SHOULD be maintained (assignments of authorisation objects to transactions). Full authorisation (*) or intervals in object values SHOULD be avoided.

Authorisation development SHOULD be carried out as part of change management.

It SHOULD be ensured that the production system in question is adequately protected against authorisation changes and that no developer keys are assigned. The respective quality assurance system SHOULD be operated in the same way as the production system when assigning authorisations and adding settings.

To ensure secure logins to an SAP ERP system, profile parameters, customising switches, or a security policy SHOULD be configured appropriately.

The hash algorithms used for the stored hash values of the passwords in an SAP ERP system SHOULD comply with the current security standards. Access to tables with hash values SHOULD be restricted.

The handling of critical authorisations SHOULD be strictly controlled. These authorisations, roles, and profiles SHOULD be assigned restrictively. This SHOULD also be ensured for critical role combinations and additive effects, such as cross authorisations.

Critical authorisations SHOULD be regularly identified, reviewed, and evaluated. The SAP profiles SAP_ALL and SAP_NEW* and the SAP authorisation object S_DEVELOP (with change authorisations ACTVT 01 and 02) SHOULD not be assigned in a production system. Emergency users SHOULD be excluded from this requirement.

The SAP router SHOULD regulate access to the network and complement the existing firewall architecture appropriately. It SHOULD also control access to the SAP ERP system.

The SAP ERP system SHOULD NOT be installed on a Windows domain controller. The SAP-specific users, such as <sid>adm or SAPService <sid>, SHOULD be secured. After installation, the user <db><sid> SHOULD be locked.

The user SAPService <sid> SHOULD NOT have any interactive login rights. With respect to these authorisations, the system resources associated with the SAP ERP system (such as files, processes, and shared memory) SHOULD be protected.

Appropriate settings SHOULD be used to secure the specific authorisations of the users Guest, System, SAP system users = <sapsid>adm, SAPService<SAPSID> and Database users = <database-specific users>, as well as user groups created by the SAP ERP system.

Access authorisations SHOULD be defined for the SAP ERP system directories in Unix. The passwords of the system-specific users <sid>adm and <db><sid> SHOULD also be changed. After installation, the user <db><sid> SHOULD be locked.

Communications with and among SAP ERP systems SHOULD be secured with SNC. If the database and the SAP application server are operated on different systems, the database connection SHOULD be encrypted appropriately. The internal services of the SAP application server SHOULD ONLY communicate with each other using TLS.

Specific security policies for passwords and login restrictions SHOULD be created for specific users and user groups. For example, users with critical authorisations SHOULD be protected by strong password rules (SECPOL transaction). Security policies SHOULD be correctly assigned to users and checked regularly.

SAP GUI SHOULD be installed on all clients and updated regularly. SAP GUI ACLs SHOULD also be activated and appropriate administration rules distributed and activated.

It SHOULD be ensured that data from sequential data processing such as spool or print can only be accessed to a limited extent. Unauthorised users SHOULD also be prevented from accessing the TemSe data store used by the SAP spool system. The authorisations granted SHOULD be checked regularly.

SAP background processing SHOULD be protected against unauthorised access. For batch jobs, various system user IDs SHOULD be defined and created according to their functional areas. Dialogue users SHOULD NEVER be authorised for this purpose.

It SHOULD be ensured that only necessary ICF services are activated. All ICF services that are under an ICF object SHOULD only be activated individually. Authorisations SHOULD be assigned restrictively. Communications SHOULD be encrypted.

The SAP Web Dispatcher SHOULD not be the first entry point from the Internet into an SAP ERP system. The SAP Web Dispatcher SHOULD always be up to date. It SHOULD be configured securely.

A custom code management process SHOULD be defined so that a customer’s own code is removed if it can be replaced by standard SAP code or is no longer used. The requirements from the guideline for the development of ABAP programs SHOULD also be taken into account.

To ensure that all internal and external guidelines and requirements are being met, all SAP ERP systems SHOULD be audited regularly. The Security Optimization Service in SAP Solution Manager SHOULD be used for this purpose. The results of audits SHOULD be evaluated and documented.

A contingency concept SHOULD be created and followed for SAP ERP systems. It SHOULD secure business activities and meet the requirements of crisis management or business continuity management. The following points SHOULD be described and defined in the contingency concept:

• Incident detection and response
• Data backup and recovery
• Business continuity management

The contingency concept SHOULD be updated at regular intervals.

User IDs SHOULD be created for emergency users. The IDs and authorisations that have been set up SHOULD be strictly controlled and precisely documented. In addition, all activities performed by emergency users SHOULD be logged.

The correctness of all SAP ERP system security settings SHOULD be constantly monitored. The proper application of all patches and updates SHOULD also be monitored. SAP monitoring SHOULD be integrated into an organisation’s general system monitoring.

If multiple SAP ERP systems exist, users SHOULD access the systems with SAP Single Sign-On (SAP SSO). The SAP ERP systems that will be included in the SSO mechanism SHOULD be determined in the planning phase. SSO SHOULD be configured and operated securely.

The most important security recording functions in SAP ERP systems, such as the security audit log or system log, SHOULD be continuously monitored. An employee in charge SHOULD be automatically alerted in the event of suspicious transactions. To analyse SAP-specific security incidents and differentiate false reports from actual security incidents, employees SHOULD either be trained or third-party services should be used.