APP.4.2 SAP ERP System
Enterprise Resource Planning systems from SAP (SAP ERP systems for short) are used to automate and technically support internal and external business processes...
Description
Introduction
Enterprise Resource Planning systems from SAP (SAP ERP systems for short) are used to automate and technically support internal and external business processes. SAP ERP systems therefore typically process confidential information, so all components and data must be adequately protected.
SAP ERP systems are currently available on the market under the product names SAP Business Suite and SAP S/4HANA. An SAP ERP system consists of various modules that can be used to map the organizational structure of an institution. The modules of an SAP ERP system include, among others, accounting, human resources, and logistics. The core components of the SAP ERP system are SAP NetWeaver (application server middleware) and SAP HANA (application server and database). SAP NetWeaver makes it possible to connect SAP ABAP and SAP JAVA applications and to control processes across the entire system. SAP HANA can analyze large volumes of data in real time across all business areas.
Objective
This building block describes what threats must be considered for SAP ERP systems and how these systems can be securely installed, configured, and operated. It is aimed at information security officers and administrators responsible for planning and implementing SAP ERP systems.
Scope and Modeling
The building block APP.4.2 SAP ERP System must be applied to every SAP ERP system.
This building block is limited to the core installation of an SAP ERP system and focuses on the specific characteristics of the underlying SAP NetWeaver application server. Not all available SAP products are described in detail in this building block. The following descriptions are limited to the configuration of the SAP basis and do not address modules or applications.
Requirements for the development of ABAP programs can be found in the building block APP.4.6 SAP ABAP Programming. Beyond that, adjacent IT systems, operating systems, or databases are not examined in detail. For these, the relevant specific building blocks such as SYS.1.2.2 Windows Server 2012, SYS.1.3 Server under Linux and Unix, or APP.4.3 Relational Databases must be applied. Likewise, this building block does not address SAP HANA. Current product names are deliberately omitted, as these change frequently.
Threat Landscape
Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to represent the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block APP.4.2 SAP ERP System:
Failure to Follow SAP Security Recommendations
If an SAP ERP system is set up without taking into account SAP’s recommended security guidelines, this can lead to serious security problems in the system. This is the case, for example, when SAP recommendations for account and authorization management are not correctly implemented. Vulnerabilities can also arise when SAP recommendations that protect communication or interface operations via RFC and web services are ignored. This can make the entire system vulnerable to attack.
Missing or Delayed Application of Patches and SAP Security Notes
SAP ERP systems consist of various modules and components and are complex systems that usually process sensitive data. SAP therefore regularly publishes patches and security notes to fix software errors and known vulnerabilities. If new patches or SAP security notes are not applied promptly or not at all, open security vulnerabilities could be exploited by attackers. Attackers could then manipulate SAP ERP systems, potentially causing confidential data to leak, services to fail, or entire business processes to halt.
Inadequate Planning, Implementation, and Documentation of an SAP Authorization Concept
SAP authorization concepts are technically and substantively complex. Due to these high demands, they are often barely or only insufficiently planned and implemented in many institutions. However, without a well-thought-out authorization concept, accounts are often assigned more permissions than necessary. These accounts could then intentionally manipulate or accidentally damage the SAP ERP system. This puts integrity, confidentiality, and availability at risk.
Furthermore, in S/4HANA systems, the authorization design between the integrated components ABAP, HANA, and NetWeaver Gateway (for Fiori applications) must be precisely coordinated and synchronized to avoid conflicting authorizations being assigned.
If the SAP authorization concept is not sufficiently documented, assigned authorizations can no longer be traced and thus maintained. For example, employees who have already left or have been assigned new tasks may still be able to access SAP ERP systems.
Missing SAP Documentation and Missing Emergency Concepts
If there is no documentation for the SAP ERP system, or if it is not maintained, it is no longer possible to understand how the SAP ERP system was set up and with which settings. This can delay recovery times in an emergency and critical business processes may fail entirely. This risk also exists when there are no emergency plans that describe in detail how those responsible should proceed in an emergency.
Requirements
The following are the specific requirements of the building block APP.4.2 SAP ERP System. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.
Further roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is reasonable and appropriate.
| Responsibilities | Roles |
|---|---|
| Primarily responsible | IT Operations |
| Additional responsibilities | Specialist Department, Emergency Officers, Developers |
Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, this role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many people should fill these roles.
Basic Requirements
The following requirements MUST be fulfilled with priority for this building block:
APP.4.2.A1 Secure Configuration of the SAP ABAP Stack (B)
The SAP ABAP stack MUST be securely configured. For this purpose, the relevant profile parameters MUST be set, e.g. for password security, authentication, and encryption. System changeability and clients MUST also be configured, IMG customizing MUST be performed, and operating system commands MUST be secured.
APP.4.2.A2 Secure Configuration of the SAP JAVA Stack (B)
The SAP JAVA stack MUST be securely configured, if it is used. Different security mechanisms and concepts MUST be created for this than for the SAP ABAP stack. For this reason, administrators MUST be familiar with the architecture of the JAVA stack and know how to administer it. In addition, unneeded services MUST be disabled, default content removed, HTTP services protected, and access to administration interfaces restricted.
APP.4.2.A3 Network Security (B)
To ensure network security, appropriate concepts MUST be developed taking the SAP ERP system into account, and settings MUST be applied to the system.
Furthermore, the SAP Router and SAP Web Dispatcher SHOULD be used to implement and maintain a secure SAP network.
To avoid security vulnerabilities due to misinterpretations or misunderstandings, the areas of IT Operations, firewall operations, portal operations, and SAP operations MUST coordinate with one another.
APP.4.2.A4 Securing Delivered SAP Standard Accounts (B)
Immediately after installing an SAP ERP system, the preset passwords of the SAP standard accounts MUST be changed. The established SAP standard accounts MUST also be secured using appropriate measures. Certain SAP standard accounts MUST NOT be used, e.g. for RFC connections and background jobs.
APP.4.2.A5 Configuration and Securing of SAP Account Management (B)
The SAP account management for ABAP systems MUST be administered carefully and securely. Activities such as creating, modifying, and deleting accounts, resetting and unlocking passwords, and assigning roles and profiles MUST be among the responsibilities of account administration.
APP.4.2.A6 Creation and Implementation of an Account and Authorization Concept (B) [Specialist Department, Developers]
For SAP ERP systems, an account and authorization concept MUST be developed and implemented. The following points MUST be considered:
- The identity principle, minimum principle, position principle, voucher principle of accounting, voucher principle of authorization management, segregation of duties principle (SoD), approval principle, standard principle, written form principle, and control principle MUST all be considered.
- Account, authorization, and where applicable profile administrators MUST have separate responsibilities and therefore separate authorizations.
- Procedures within authorization administration for creating, modifying, deleting, and transporting roles, and transporting SU24 default values MUST be defined. Authorization roles SHOULD only be created and maintained in the development system. They SHOULD be transported using the Transport Management System (TMS). Authorizations SHOULD be created in authorization roles (PFCG roles), stored, and assigned to accounts (role-based authorization concept). Since individual critical actions in roles cannot always be avoided, they SHOULD be covered by compensating controls (mitigation controls).
- Procedures within authorization assignment for requesting, approving, modifying, and deleting accounts and authorizations MUST be defined.
- Naming conventions for account identifiers and technical role names MUST be defined.
- Default values and check indicators SHOULD be maintained in transaction SU24. The procedure for doing so SHOULD be described in the account and authorization concept.
- Legal and internal framework conditions such as the principles of proper accounting (GoB), the German Commercial Code (HGB), or internal institution guidelines MUST be considered. The account and authorization concept SHOULD also cover the operation of technical accounts, including the authorization of background and interface accounts.
Appropriate control mechanisms SHOULD be applied to monitor SoD conflict-freedom of roles and the assignment of critical authorizations to accounts.
If components in addition to the ABAP backend are used, such as SAP HANA and SAP NetWeaver Gateway (for Fiori applications), the authorization design MUST be coordinated and synchronized between the components.
APP.4.2.A7 Securing SAP Databases (B)
Access to SAP databases MUST be secured. Administrators SHOULD, where possible, only access the databases using SAP tools. If software from external institutions is used for this, additional security measures MUST be implemented. No schema account of the SAP system MAY then be used for the connection to the database. In addition, default passwords MUST be changed and certain database tables (e.g. USR* tables) MUST be specially protected.
APP.4.2.A8 Securing the SAP RFC Interface (B)
To protect the Remote Function Call (RFC) interface, RFC connections, RFC authorizations, and RFC gateways MUST be securely configured.
Uniform administration guidelines MUST be created and implemented for all RFC connections. For this purpose, the required RFC connections SHOULD be defined and documented. Connections with stored passwords SHOULD NOT be configured from less privileged to more 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. For this purpose, appropriate profile parameters MUST be set, e.g. gw/monitor, gw/reg_no_conn_info and snc/permit_insecure_start. All connections via a gateway MUST be analyzed and evaluated from a security perspective. Logging MUST be active. Access control lists (ACLs) MUST be defined.
APP.4.2.A9 Securing and Monitoring the Message Server (B)
The message server MUST be secured through appropriate settings in the profile parameters. A decision MUST be made, among other things, as to whether ACLs should be built for the internal message server. The message server MUST be monitored using appropriate mechanisms so that, e.g., system failures of the message server are quickly detected.
APP.4.2.A10 DISCONTINUED (B)
This requirement has been discontinued.
Standard Requirements
Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be fulfilled.
APP.4.2.A11 Secure Installation of an SAP ERP System (S)
When installing an SAP ERP system, current SAP security guidelines and documentation SHOULD be taken into account. In addition, the institution’s security policies SHOULD be followed. It SHOULD also be ensured that the SAP ERP system is installed on a hardened operating system.
APP.4.2.A12 SAP Authorization Development (S) [Specialist Department, Developers]
Technical authorizations SHOULD be developed based on functional requirements. Furthermore, SAP authorizations SHOULD be adapted or newly created on the development system of the SAP landscape. For S/4HANA, this SHOULD also include authorization development on HANA databases. Repository roles SHOULD be built and transported there. Database privileges SHOULD NOT be assigned directly to accounts.
For custom developments such as transactions or authorization objects, transaction SU24 SHOULD be maintained (assignment of authorization objects to transactions). Full authorization *** or intervals in object expressions SHOULD be avoided.
Authorization development SHOULD be carried out within the framework of change management.
It SHOULD be ensured that the production system is sufficiently protected against authorization changes and that no developer keys are issued. The quality assurance system SHOULD be operated with the same authorization assignments and supplementary settings as the production system.
APP.4.2.A13 SAP Password Security (S)
To ensure secure logon to the SAP ERP system, profile parameters, customizing switches, or security policies SHOULD be set appropriately.
The hash algorithms used for stored hash values of passwords in an SAP ERP system SHOULD meet current security standards. Access to tables containing hash values SHOULD be restricted.
APP.4.2.A14 Identification of Critical SAP Authorizations (S) [Specialist Department]
The handling of critical authorizations SHOULD be strictly controlled. Care SHOULD be taken that these authorizations, roles, and profiles are only assigned restrictively. This SHOULD also be ensured for critical role combinations and additive effects such as cross-authorizations.
Critical authorizations SHOULD be regularly identified, reviewed, and assessed. The SAP profiles SAP_ALL and SAP_NEW as well as the SAP authorization object S_DEVELOP (with modification authorizations ACTVT 01 and 02) SHOULD NOT be assigned in the production system. Emergency accounts SHOULD be exempt from this requirement.
APP.4.2.A15 Secure Configuration of the SAP Router (S)
The SAP Router SHOULD regulate access to the network and appropriately supplement the existing firewall architecture. It SHOULD also control access to the SAP ERP system.
APP.4.2.A16 Implementation of Security Requirements for the Windows Operating System (S)
The SAP ERP system SHOULD NOT be installed on a Windows domain controller. SAP-specific accounts such as
The account SAPService
The specific authorizations of the accounts created by the SAP ERP system — Guest, System, SAP system users =
APP.4.2.A17 Implementation of Security Requirements for the Unix Operating System (S)
Access permissions SHOULD be defined for SAP ERP system directories under Unix. The passwords of the system-specific accounts
APP.4.2.A18 Disabling Insecure Communication (S)
Communication with and between SAP ERP systems SHOULD be secured using SNC. If the database and SAP application server are operated on different systems, the database connection SHOULD be encrypted in an appropriate manner. The internal services of the SAP application server SHOULD ONLY communicate with each other using TLS.
APP.4.2.A19 Definition of Security Policies for Accounts (S)
Specific security policies for passwords and logon restrictions SHOULD be created for the respective accounts and account groups. For example, accounts with critical authorizations SHOULD be secured by strong password rules (transaction SECPOL). Security policies SHOULD be correctly assigned to accounts and regularly reviewed.
APP.4.2.A20 Secure SAP GUI Settings (S)
The SAP GUI SHOULD be installed on all clients and regularly updated. SAP GUI ACLs SHOULD also be activated, and appropriate administration rules SHOULD be distributed and activated.
APP.4.2.A21 DISCONTINUED (S)
This requirement has been discontinued.
APP.4.2.A22 Protection of the Spool in the SAP ERP System (S) [Developers]
It SHOULD be ensured that access to data from sequential data processing, such as spool or printing, is restricted. It SHOULD also be prevented that unauthorized accounts can access the data store TemSe used by the SAP spool system. The authorizations granted for this purpose SHOULD be regularly reviewed.
APP.4.2.A23 Protection of SAP Background Processing (S) [Developers]
SAP background processing SHOULD be protected against unauthorized access. For this purpose, different system accounts SHOULD be defined and created for batch jobs according to their functional areas. The so-called user type Dialog SHOULD generally NOT be permitted for this.
APP.4.2.A24 Activation and Securing of the Internet Communication Framework (S)
Care SHOULD be taken to ensure that only necessary ICF services are activated. All ICF services under an ICF object SHOULD only be activated individually. ICF authorizations SHOULD be assigned restrictively. Communication SHOULD be encrypted.
APP.4.2.A25 Secure Configuration of the SAP Web Dispatcher (S)
The SAP Web Dispatcher SHOULD NOT be the first entry point from the internet to the SAP ERP system. The SAP Web Dispatcher SHOULD be kept up to date. It SHOULD be securely configured.
APP.4.2.A26 Protection of Custom-Developed Code in the SAP ERP System (S)
A custom code management process SHOULD be defined so that custom-developed code is exchanged or removed if it can be replaced by SAP standard code or is no longer used. Furthermore, the requirements from the ABAP programming development policy SHOULD be observed.
APP.4.2.A27 Audit of the SAP ERP System (S) [Specialist Department]
To ensure that all internal and external policies and requirements are complied with, all SAP ERP systems SHOULD be regularly audited. For this purpose, the Security Optimization Service in the SAP Solution Manager SHOULD be used. The results of the audit SHOULD be evaluated and documented.
APP.4.2.A28 Creation of an Emergency Concept (S) [Emergency Officers]
An emergency concept SHOULD be created and operated for SAP ERP systems. It SHOULD safeguard business activities and be consistent with requirements from crisis management or business continuity management. The following points SHOULD be described and defined in the emergency concept:
- Detection of and response to incidents,
- data backup and recovery concept, and
- emergency administration.
The emergency concept SHOULD be regularly updated.
APP.4.2.A29 Setting Up Emergency Accounts (S)
Emergency accounts SHOULD be created. The established accounts and authorizations SHOULD be strictly controlled and precisely documented. In addition, all activities carried out by emergency accounts SHOULD be logged.
APP.4.2.A30 Implementation of Continuous Monitoring of Security Settings (S)
It SHOULD be continuously monitored whether all security settings of the SAP ERP system are correct. It SHOULD also be monitored whether all patches and updates have been properly applied. SAP monitoring SHOULD be integrated into the institution’s general system monitoring.
APP.4.2.A31 Configuration of SAP Single Sign-On (S)
If multiple SAP ERP systems are present, users SHOULD access the systems using SAP Single Sign-On (SAP SSO). A decision SHOULD be made in the planning phase as to between which SAP ERP systems the SSO mechanism will be used. SSO SHOULD be securely configured and operated.
Requirements for High Protection Needs
The following are exemplary proposals for requirements for this building block that go beyond the level of protection that corresponds to the state of the art. The proposals SHOULD be considered when there are high protection needs. The specific determination is made within the context of an individual risk analysis.
APP.4.2.A32 Real-Time Detection and Alerting of Irregular Incidents (H)
The most important security logging functions of the SAP ERP systems, such as Security Audit Log or System Log, SHOULD be continuously monitored. In the event of suspicious incidents, the responsible employees SHOULD be automatically alerted. To be able to analyze SAP-specific security incidents and distinguish false alarms from actual security incidents, employees SHOULD either be trained or corresponding services from third-party providers SHOULD be used.
Additional Information
Good to Know
The SAP Help Portal (https://www.help.sap.com/viewer/index) is the central entry point to SAP help. It offers extensive information and instructions on a wide variety of topics. The following is a selection of topics relevant in the context of SAP ERP systems:
- SAP Audit Management, https://help.sap.com/saphelp_fra110/helpdata/de/ab/ce1b52bd543c3ae10000000a441470/frameset.htm and https://help.sap.com/saphel_erp60_sp/helpdata/de/f9/558f40f3b19920e10000000a1550b0/content.htm
- User Management with AS Java, https://help.sap.com/saphelp_nw73/helpdata/de/45/b90177cf2252f8e10000000a1553f7/content.htm?no_cache=true
- Central User Administration (ZBV), https://help.sap.com/doc/erp2005_ehp_07/6.07/de-DE/8d/270bea613d2443bad6ce0524f08ca0/frameset.htm
Detailed best practice recommendations for audits of SAP ERP systems are provided in the SAP ERP 6.0 Audit Guide: Best Practice Recommendations from the German-speaking SAP User Group (DSAG).