S 2.349 Secure software development for SAP systems

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator, Developer

In order to adapt an SAP system to the specific requirements of a company or government agency, the functionality of the system can be changed or extended by software developed in-house. The following must be taken into consideration from a security perspective when developing software for SAP systems:

Software development process

The recommendations in safeguard S 2.378 System development should be implemented and used as a basis for the software development process.

Developers in productive systems

Since productive systems contain system and business data requiring protection, developers must not be granted access to the productive systems. In particular, no debugging must be performed in the productive system. Debugging must be performed in the development system. For the ABAP stack, this means that no users should be granted the S_DEVELOP authorisation. The CATT and eCATT tools (ABAP stack) and the remote debugging capabilities of the engine (Java stack) must not be used in productive systems. Their use must be prohibited by configuring the client and/or Java stack accordingly.

In exceptional, justified cases when developers are only able to analyse errors in the productive systems, the developers may be granted display authorisations and debugging authorisations temporarily, but should not be granted any change authorisations. The security must be increased accordingly by implementing additional organisational safeguards.

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

The direct installation of new software to the productive system by developers must be prohibited using a multi-stage software deployment concept (see S 4.272 Secure use of the SAP transport system and S 4.273 Secure use of the SAP Java Stack software deployment).

Security requirements for software developed in-house

The developers should be supported by suitable security specifications. Developers can only take specific requirements or general conditions into account when programming if they are aware of such requirements and conditions. It is recommended to implement the following specifications, amongst other things:

• ABAP code must always check the authorisations.
• The authorisation objects programmed and used in the ABAP code must be documented and must be installed for the Profile Generator using transaction SU24 (see also S 2.342 Planning of SAP rights).
• The services used must be documented for Java code.
• The roles used and specifications regarding the so-called security constraints (i.e. which roles are needed to access application functions) must be documented for Java applications.
• For ABAP programs, the ABAP Code Inspector (transaction SCI) should be used to check, amongst other things, the security of the programs developed in-house and to check whether they follow the SAP naming conventions. This is especially true if no other tools are used to perform security-relevant checks on ABAP programs.

Security for third-party applications

Software developed by third parties may only be installed on the SAP system after a meticulous approval process. Security checks must be conducted as well during the approval process, amongst other checks. The security requirements must be described in detail in the requirements specification. This is the only way to ensure the applications are adequately secure.

Review questions:

• Has it been ensured that the developers are not granted access to the productive SAP system?
• Is there a staged software approval concept preventing the direct installation of new software to the productive SAP system by developers?
• Are there suitable security specifications for developing SAP programs (specific requirements and general conditions) supporting the developer?