SAP ABAP – security of custom code
From our own practice we know that every intrusion, every hack and every SAP security incident involves usually infiltrated SAP ABAP code at the customer’s site.
The consequences are far-reaching.
With SAP systems in particular, SAP-ABAP code security is an area of security that is often overlooked. Attack patterns in SAP ABAP code was never taken seriously.
An important area of SAP security to prevent these incidents is the analysis of the customer’s own SAP programs.
Here, as in any programming language, classic security loopholes can be programmed – whether consciously or unconsciously.
However, the patterns themselves are significantly different than in a Java stack or a Windows program. The goal of these conventional programs is usually to either crash the program (buffer overflow) or to artificially cause the program to execute its own code (code injection).
Both is not possible in an ABAP system, since a crash of a process causes nothing else than the creation of an entry in the log database (Dump ST22) and a termination of the program with return to the menu starting point.
A direct manipulation as in other high-level languages or servers is not possible. However, there are other manipulation possibilities.
More and more attack vectors on SAP systems have to do with ABAP code that is used as a Trojan or that is a threat by itself. During recent investigations at an SAP customer, we found an ABAP report in the production environment that deleted all FI tables without comment (DROP Table Statements), without warning. An unintended execution would have had disastrous consequences. It turned out that this ABAP was used during the initial implementation in the 90s to reset the system in case of errors in the initial loading. The ABAP was forgotten and never deleted.
Checking for ABAP code security in the company
But is your own system really secure? Similar to an SAP penetration test, the customer’s own SAP system or SAP HANA system is her checked for security.
There are tools that can be used to analyze the customer’s own programs in a mass procedure. The results and findings gained from this must then be transferred to a vulnerability remediation project (“Get Clean”) and then to a “Secure ABAP Programming” project (“Stay Clean”).
Benefit also for future S/4 HANA migration
The cleanup of customer-specific SAP ABAP code on the basis of a security project is also a good start with regards to an upcoming SAP HANA migration. This is because the use of the SAP ATC (ABAP Test Cockpit) for the security analyses and the cleanup of the affected programs is also the subject matter when it comes to robust ABAP code, performance and central policy management.
An SAP security project is often the technological precursor on the basis of which the S/4 HANA migration follows, both technologically and organizationally. This is because the migration also presupposes that no more security gaps exist, but also that the customer’s own code also complies with all modern ABAP guidelines.
The ABAP Security Check
The whole process is completed in a few days and can also be quickly implemented in a project, all at a fixed price.