T 2.108 Lack of, or inadequate, planning of the use of SAP

A number of problems may arise when an SAP system is used without adequate planning. In such cases, security problems will always arise, in addition to other problems. The following presents only some of these problems, but should make it clear that proper planning is necessary before using an SAP system:

• A medium-sized company wants to introduce an SAP system. The company decided to use a configuration in which the SAP system is installed on a single computer (single-host installation). Due to a lack of time, no resource planning was performed. In addition, the computer purchased was bought at a sale held by a computer manufacturer. After installation, it was determined that the computer was not equipped with enough main memory and could not be equipped with much more memory due to hardware restrictions. Delays and significant additional costs arose from the necessity to purchase new, more suitable hardware.
• Since the separation of the roles was not planned while drawing up the administration concept, an administrator is capable of accessing all HR data on an R/3 system.
• The responsibilities and procedures for change management and the business continuity concept for an SAP system were not specified during the planning phase. For this reason, developers have full access to the production system, since access "is absolutely necessary to make emergency repairs". It is therefore possible for the developers to access all account and credit card data belonging to the company's customers.
• If a person has developer access capabilities to productive SAP systems (these rights are assigned using the S_DEVELOP authorisation object), this person may bypass the security mechanisms of the SAP system and access functions and data without authorisation.
• The consequences of being able to call transactions in an SAP system without authorisation can be extensive. In general, it is possible to access functions and data not meant to be available to the person accessing them in such cases. If this also applies to administrative transactions, the security of the system can be completely undermined under some circumstances.
• If an attacker is able to access the operating system level of an SAP system, the attacker may perform changes to the configuration of the SAP system. For example, it could be possible to access the profile parameters, which could then be changed to lower the access barriers (e.g. account lock settings), amongst other things. It would also be possible to access and change the configuration files of the Java stack. The level of security may be reduced drastically as a result. If the computer the database of the SAP system runs on is affected, the contents of the database could be obtained simply by copying the corresponding files. This would then undermine the security mechanisms of the SAP system.
• The default settings in standard installations are generally not adequate to meet the security requirements of productive operations. If components are nevertheless operated in the production environment using their default configurations, there is a high risk of the security of the system and data being threatened. Possibilities for attacks are provided by the various unconfigured interfaces and range from unauthorised access to functions and data to the ability to execute operations on the operating system using the authorisations of the SAP system.
• If the (publicly known) default passwords of important users such as "SAP*" or "DDIC" in the ABAP stack or "administrator" or "system" in the Java stack are not changed, attackers are able to obtain administrator access privileges. In this case, an attacker would have access to all data of the SAP system and would be able to execute administrative functions.
• If an SAP system is taken out of operation and its identity (IP, SID) is not assumed by a replacement system, the incomplete decommissioning may result in an attacker adding his/her own SAP system to the network, which assumes the identity of the system taken out of operation. Access to the attacker's system by other SAP systems through existing destinations would then be accepted by the attacker's system. This means that data could be retrieved and stored on the attacker's system. This data also includes authentication information required for the login procedure. In many cases, technical users are set up simultaneously on several systems, which means that it would also be possible to gain access to other systems.
  If the HTTP-based RFC SOAP interface is enabled on an SAP system (ABAP ICF service or JAVA Stack SOAP service), it is possible for users to call RFC-enabled modules via the HTTP interface. In general, this is not desirable in scenarios in which the SAP system is accessed using a browser. However, it is possible in this case to execute RFC calls, which means it could be possible to access data without authorisation, depending on the authorisation settings.
• If important system events are not logged or the entries in the log are not evaluated, it is impossible to detect attacks or security violations. It is impossible to react to successful attacks or track down the source of an attack. For this reason, unobtrusive unauthorised accesses to data or functions is possible.