S 2.341 Planning the use of SAP

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator, Head of IT

Extensive planning is required in advance for the installation and initial operation of an SAP system. Careful planning is not only necessary for security reasons. In addition, the documentation of the business processes and workflows to be automated and supported by the SAP system must be complete, correct, and contain the necessary level of detail. This is the only way to ensure successful implementation in an SAP system. Even a planning phase of several months may be too short when planning new, large-scale systems.

The Data Protection Officer and the personnel or supervisory board should become involved early on in the conception phase. On the one hand, SAP systems always need to process personal data in general, for example using the HR module or within the framework of logging information (see below). On the other hand, these people are needed to guide the necessary process of converting the business processes and workflows.

Each SAP system must be planned individually, since the operational scenario of each SAP system is different. The testing and approval system and the development system associated with a productive system also must be planned individually, since their intended uses are different. In this case, it must be ensured that the dependencies between the SAP systems must be taken into consideration for each SAP system as well. This applies especially to the dependencies between different variants of an SAP system (development, testing and approval, and production), but also between different SAP systems in a cluster. For these reasons, an overall plan must be drawn up that accounts for the interactions between the individual systems.

The following contains a list of SAP security subconcepts that must be drawn up during the planning phase and maintained continuously in terms of the security of an SAP system. The list is not exhaustive and must be adapted to reflect the local conditions and requirements, but the following SAP security subconcepts are necessary at a minimum:

In general, the security concepts already available in the government agency or company must be taken into account during this conception phase.

Planning the technical configuration

The technical implementation achieved by configuring the SAP system accordingly (customising) must be based on the concepts listed above. For this, it is necessary to define the steps necessary for technical configuration of the ABAP stack within the framework of a project-based Implementation Guide (IMG). The steps necessary to obtain the desired configuration are generally selected from the SAP Reference IMG (see S 4.258 Secure configuration of the SAP ABAP Stack). The IMG mechanism is not available for the Java stack, but the configuration steps necessary to obtain the desired configuration should be planned nevertheless (see also S 4.266 Secure configuration of the SAP Java Stack).

When planning the technical configuration, it must be taken into consideration that feedback processes are necessary to be able to react to any changes arising within the framework of implementation. In the planning phase, the SAP system documentation can be used as a reference when specifying and planning the necessary technical configurations. This documentation can be accessed via the SAP Help Portal at help.sap.com. After installation, the technical configuration can be modified, provided that modification is necessary.

Administration concept

A good concept for the administration of an SAP system is an essential factor for the security of the system. The administration concept must specify who will perform which administrative tasks. The technical implementation must then ensure that a given user is only able to perform the tasks assigned to him/her. In general, the recommendations and aspects described in the following should also be taken into account.

It is always necessary to create a concept for the stacks (ABAP, Java) installed for an SAP system. It must be ruled out that a stack has been installed but there is no administration concept available.

In large companies and government agencies, it is recommended to divide the administrative tasks among several people, and therefore to separate the corresponding functions. In general, the basic administration and the administration of the applications and modules should always be separated.

Furthermore, it is recommended to have separate administrators for user administration, authorisation administration, administration of the system logs, backups, and change management at a minimum. Depending on the personnel resources available, the roles can be further separated, for example based on individual interfaces (e.g. RFC, ICF, or SOAP) or services (e.g. batch processing). The relevant persons responsible for the business processes and information should also be involved when planning the concept. This is the only way to ensure that the concept has been adapted to meet the requirements resulting from the business processes.

When distributing the administrative tasks, it must be remembered that such a detailed separation of tasks is not configured by default for the ABAP stack or for the Java stack.

For this reason, more resources and time must be planned for configuration when a finer separation of tasks is desired.

In small companies and government agencies where only one administrator is employed, it is impossible to separate the functions due to a lack of alternate personnel. In this case, the consequences of an internal attack or of a lack of knowledge about the system must be estimated and given careful consideration. A regular external security check may help to maintain the level of system security in such situations. In general, though, internal security controls also need to be defined to avoid security risks. It must be taken into account that these controls, as well as their implementation and execution, also must be managed.

The ABAP stack of an SAP system must not be administered by a user possessing SAP_ALL authorisation. This administration variant comes with too many security risks. If the basic administration is performed by one administrator only, it may make sense to use the following procedure:

Thus, the administrator will not be automatically granted all application authorisations. Even in cases where only one administrator is used, it is recommended to specify which administrative tasks the administrator is allowed to perform and which ones he/she is not allowed to perform in the administration concept. The remaining authorisation objects must then be modified accordingly. This way, the administrator is only able to execute certain administrative tasks after approval has been obtained through an approval chain, for example.

The administration concept must also specify procedures and approaches for emergency administration.

Concept for user administration

The complexity of the user administration concept depends on whether just one SAP system or several SAP systems are to be administrated. If only one system needs to be administrated, the following must be specified in the user administration concept, amongst other things:

It must be ensured that processes are defined for all administration workflows required (e.g. processes for creating users, changing or assigning roles, etc.) and that these processes are specified in full. In addition, the corresponding responsibilities must be completely specified. This prevents security gaps from arising due to ambiguous responsibilities or incompletely defined processes.

It is possible for the Java stack to set up different user memory areas, but it is generally recommended to use the User Management Engine (UME), since this tool offers more flexibility during configuration. In general, the UME should be configured in such a way that the corresponding ABAP stack is used as user memory. This ensures that identical user accounts with the same name are mapped to the same user master record by the Java and ABAP stacks.

If it is necessary to administrate more than one SAP system, hen the concept for user administration is the main factor determining how much administration work will be necessary to administrate the users. It must be decided whether user administration will be performed locally or at a central location. In this case, the decision depends on the operational scenario of the SAP system and the requirements of all other systems used.

In addition to the aspects described above, the user administration concept must also address the following aspects:

Central user administration makes sense whenever the users are highly homogeneous (e.g. when they are all internal users in a government agency or a company) and access several SAP systems. In this case, the security requirements of each access scenario differ only slightly. If the users are not homogeneous (e.g. when there are internal users in a government agency or a company, users from partner companies or government agencies, and customers with some connection to the government agency or company), it may make sense to set up several administration islands (i.e. separate systems, each with its own central user administration), which administrate the users in the various operational scenarios.

Technical restrictions must also be considered when making the decision for or against a central user administration system. For example, when the central user administration (CUA) of an SAP system is to be used, a functioning ALE landscape is required as a prerequisite (see also S 5.128 Protection of the SAP ALE (IDoc/BAPI) interface).

In this case, it is also possible to administrate the authorisations granted to users centrally and to transport them to other SAP systems.

Additional information on user administration security can be found in S 4.259 Secure use of the ABAP Stack user management and S 4.267 Secure use of the SAP Java Stack user management.

Reference to additional documentation for user administration in SAP systems can be found in S 2.346 Use of the SAP documentation.

Authorisation concept

Authorisations control who is allowed to access which functions and data. The authorisation concept is therefore very important for maintaining security when accessing the functions and data of an SAP system. It is therefore essential to plan the authorisations using a well-thought authorisation concept. Safeguard S 2.342 Planning of SAP rights contains information to be considered when planning the authorisations.

Resource planning

An SAP system can only provide optimal support for a company or government agency if the computer resources available are appropriate for the operational scenario, meet the requirements of the SAP software, and provide the resources required by the SAP software.

The hardware configuration must therefore be planned exactly when performing resource planning. The items to plan include, amongst other things:

The SAP documentation relevant to resource planning is listed in safeguard S 2.346 Use of the SAP documentation.

Planning the SAP system landscape

An SAP system always consists of many components that perform a variety of different tasks and that communicate with each other using the network infrastructure. This means the architecture used for the system landscape may have a positive influence on the security of an SAP system. However, an inadequately planned and installed system landscape may lead to security problems.

Since a favourable (from a security perspective) system landscape depends highly on the operational scenario of the SAP system and the protection requirements of the data it stores, an IT-Grundschutz module can only provide basic recommendations. However, SAP generally provides recommendations for optimal system designs for different products and operational scenarios.

In general, planning should be conducted so that only those accesses to components and between components absolutely needed are possible. In particular, the separation of the productive system, test and approval system, and the

development system must be planned. It must be ensured through appropriate planning that the productive data of an SAP system cannot be transmitted unchanged to systems for testing and approval or for development and then used in these systems. If this cannot be guaranteed, the test and approval systems must be protected in such a way that the confidentiality of the data is guaranteed on these systems as well.

The definition of the system landscape must also specify the following, amongst other things:

Additional information for special operational scenarios can be found in 2.343 Protection of SAP systems in a portal scenario and S 2.344 Secure operation of SAP systems on the Internet.

SAP documentation containing detailed information on the recommended system landscape can be found in S 2.346 Use of the SAP documentation.

Audit and logging concept

The audit and logging concept must specify which activities of the SAP system and which activities of the users need to be recorded in a log. In addition, the following aspects must be taken into account:

An SAP system possesses extensive capabilities for logging internal procedures and user activities. The most important aspects in terms of logging are handled in S 4.270 Logging of SAP events.

In addition to monitoring the system, which must be implemented using the logging functionality, the security of the SAP system must be checked regularly within the framework of audits. Audits can be performed in this case by administrators (self-monitoring) or by other auditors. The audits can be performed by people from other departments (Information Security or Audit department) or they can be performed by external third parties (IT auditors, external auditors, or monitoring and control organisations). Additional information on this subject can be found in S 2.347 Regular security checks of SAP systems. It must be noted that self-monitoring by the administrators themselves is not adequate to judge the security of an SAP system.

Change management concept

It is important to maintain the security of an SAP system by keeping the system up to date, i.e. by installing patches, hot fixes, and updates. Programming errors can only be eliminated when the system is updated regularly. Since the change management processes for ABAP and Java stacks differ technically, two separate concepts must be drawn up for these stacks. The following questions must be answered in the concepts:

Changes are installed in the ABAP stack using the so-called transport system. In this case, several SAP systems can be integrated into a transport system group (referred to as a transport domain). For this reason, a transport concept must be created when planning the change management concept. The following issues and aspects must be clarified in this:

Additional information and recommendations can be found in S 2.221 Change management, S 4.272 Secure use of the SAP transport system, and S 4.273 Secure use of the SAP Java Stack software deployment.

Information from the SAP documentation can be found in S 2.346 Use of the SAP documentation.

Backup concept

There are no unusual requirements placed on an SAP system in terms of the backup concept (see S 6.97 Contingency planning for SAP systems).

The SAP backup concept should be integrated into the existing backup procedure so that separate, special procedures are not necessary. Emphasis should be placed on defining and implementing the responsibilities and procedures for data backups.

Contingency concept

The contingency concept for SAP systems and the corresponding business continuity procedures must be defined for business-critical emergencies (see S 6.97 Contingency planning for SAP systems).

Review questions:

© Federal Office for Information Security. All rights reserved.