3 Pillars of SAP Security

Since it became important several years ago that security analyses such as SAP penetration tests be carried out, it has also become apparent that three major topics have repeatedly emerged as security challenges in these tests. These tests show again and again the three basic pillars on which a general SAP security is based and composed.

Pillar I: Remote Function Call

The main attack vector for SAP systems is still the Remote Function Call (RFC) , the calling of SAP systems and their functionalities via remote programs. These RFCs are not subject to the classic end-user SAPGUIS, but are callable interfaces (APIs) that can be called from any remote program, from Java to Python to Microsoft Excel.

These can be such illustrious modules as BAP_USER_CREATE (creating a user in SAP), reading entire database areas, or executing operating system commands with ROOT-like authorizations (keyword SIDadm).

In older systems, it was easy to connect directly to SAP, all you needed was any programming language and the associated SAP RFCLIB, the SAP library for the operating system connection.

What was still missing was a technical user for this interface, a so-called RFC user, who brought along the necessary authorizations and authentications. That usually wasn’t a real problem, as SAP_ALL (full admin rights) were granted to these users as a rule rather than the exception.

Meanwhile, there are more and more protection mechanisms against this type of attack. Above all, SAP has increasingly prevented the anonymous execution of modules, so that there are hardly any corresponding modules that function without authorizations.

The so-called gateway security, which allows monitoring and blacklist/whitelisting of certain RFC calls, also belongs to this topic.

The central protection against RFC attacks which proved effective, was introduced by SAP as UCON technology (Unified Connectivity). All SAP RFC interfaces are logged here and can then also be transferred to blacklist/whitelist scenarios. In parallel, authorization traces are recorded, which together with the whitelist scenarios enable you to assign and control specific authorizations for these interfaces.

A classic RFC security project consists of an initial data collection and quantification of the interfaces, a longer (several months) analysis phase with the SAP tools from UCON and the SAP Gateway. This is followed by a realization phase in which the whitelist is created and the roles and authorizations of the remote users are tailored.

In more recent SAP releases, a transition phase (simulation phase) can follow, in which whitelists, blacklists, and authorizations are simulated. Errors, rejections or blocks of elements are then displayed in only one log. Once the events from the log have been evaluated and corrected over time, the system can be taken live and the blacklist, whitelist, and authorizations can be armed.

As a result of an initial security analysis or a penentration test, an RFC project on the basis of SAP UCON should be carried out if vulnerabilities occur (and this was the case with all my pen tests so far). This includes the phases Assessment, Monitoring and Simulation.

Pillar II: ABAP Code Analysis

A second, large area is the area of code analysis, the evaluation of customer-specific SAP programs for weaknesses. Here, too, as in any programming language, classic security vulnerabilities can be programmed – whether consciously or unconsciously. However, the patterns themselves are significantly different than in a Java stack or a Windows program. The aim of these conventional programs is usually to either crash the program (buffer overflow) or to artificially execute the program’s own code (code injection) by making specific incorrect entries.

Both are not possible in an ABAP system, since a crash of a process has no effect other than creating an entry in the log database (dump ST22) and terminating the program with a return to the menu start point.

Direct manipulation as in other high-level languages or servers is therefore not possible. However, there are other manipulation possibilities.

There are tools with which the customer’s own programs can be analyzed in a batch procedure. The results and knowledge gained from this must then be transferred to a project for eliminating weaknesses (“Get Clean”) and then to a project for “Secure ABAP Programming” (“Stay Clean”).

Perhaps it is important to note at this point that this type of code analysis does not have to be a huge project with a big bang go live. This is mainly about making developers aware of this issue, the evolutionary change in programming through secure programming patterns and the associated continuous training and “awareness” for developers.

Especially combined with SCRUM methods from agile development, excellent project mechanisms and project elements can be created that lead to a continuous improvement of security in customer-specific SAP ABAP developments.

As a result of an initial security analysis, a pen-test, a project for security in the customer’s own developments was to be carried out if weak points occurred (and this was the case with all my pen-tests so far). This includes a Get-Clean-Phase and a Stay-Clean-Phase of a project.

Pillar III: Roles & Authorizations, Segregation of Duty.

The third pillar is the pillar of authorizations and segregation of duty.

It is important to note that the old passwords of technical users and interface users represent a high risk. They are often 6 digits long and also have the universal authorization SAP_ALL. This makes them dangerous options for a successful system hack.

In addition to passwords and their protection, authorizations, the SAP roles, are a very large field of threat vectors. In the SAP module language, these are the “GRC” requirements, the requirements and authorizations resulting from governance, risk and compliance. It describes, so to speak, the “best practice” of how SAP rights assignment should take place from the point of view of legislation, data protection, guidelines and regulations.

Above all, the technical protection of the function modules is the subject of repeated discussions about authorization assignment. Finally, as with UCON projects, a dedicated practice for the analysis and assignment of roles and rights for RFC users must be established.

A further security risk is the assignment of roles and rights to dialog users who perform their daily work. Here, too, you must ensure that all necessary GRC rules are adhered to and, above all, that these users do not have any dangerous accumulations of authorizations due to “wandering” through departments. Purchasers who have authorizations to book incoming goods and who are also allowed to release payments would be a maximum violation of compliance rules, as this would open the door to abuse.

Classic GRC projects, analysis of high-privileged users (administrators) and projects to segregate technical users are labor-intensive projects that run for long periods of time and are usually carried out by and with appropriate tools.