Kurze Einführung in die Sicherheit von kundeneigenem ABAP-Code
Aus der eigenen Praxis wissen wir, das jeder Einbruch, jeder Hack und jeder SAP-Sicherheitsvorfall etwa mit eingeschleustem SAP ABAP Code beim Kunden einschließt.
Die Folgen sind oft weitreichend.
Wenn alle aktuellen Projekte gestoppt werden, man mehr oder weniger in das Home-Office gesteckt wird und interaktive Arbeit remote stattfindet: Dann ist es Zeit, sich auf klassische Dinge wie Reinigung, Housekeeping und Aufräumen zu konzentrieren.
Gerade bei SAP-Systemen ist das Thema SAP-ABAP Code Security ein Sicherheits-Bereich, der stark vernachlässigt wird. Gerade hier ist es eigentlich wichtig, eine klassische Front der Angriffe auf SAP-Systeme zu eliminieren.
Ein wichtiger Bereich der SAP-Sicherheit, um diese Vorfälle zu verhindern, ist die Analyse der kundeneigenen SAP-Programme, die klassisch in der proprietären SAP-Sprache ABAP geschrieben werden.
Auch hier können, wie in jeder Programmiersprache, klassische Sicherheitslücken programmiert werden – sei es nun bewusst oder unbewusst.
Allerdings sind die Muster selbst deutlich anders gelagert als in einem Java-Stack oder einem Windows-Programm. Ziel bei diesen herkömmlichen Programmen ist es meistens, durch gezielte Falscheingaben das Programm entweder zum Absturz zu bringen (Buffer Overflow) oder künstlich eigenen Code zur Ausführung
zu bringen (Code Injection).
Beides ist in einem ABAP-System nicht möglich, da ein Absturz eines Prozesses nichts anderes bewirkt als das Erzeugen eines Eintrags in der Log-Datenbank (Dump ST22) und ein Beenden des Programms mit Rückkehr an den Menü-Startpunkt.
Eine direkte Manipulation wie in anderen Hochsprachen oder Servern ist so also nicht möglich. Allerdings gibt es andere Manipulationsmöglichkeiten.
Immer mehr Angriffsvektoren auf SAP-Systeme haben mit ABAP Code zu tun, der als Trojaner benutzt wird oder der schon für sich eine Gefahr darstellt. Bei einem meiner letzten Untersuchungen bei einem SAP Kunden habe ich einen ABAP-Report in der Produktionsumgebung gefunden, der kommentarlos alle FI-Tabellen löschte (DROP Table Statements), ohne Warnung. Ein unbeabsichtigtes Ausführen hätte desaströse Folgen gehabt. Es stellte sich heraus, das dieser ABAP bei der Ersteinführung in den 90ern benutzt wurde, um bei Fehlern in der initialen Beladung das System wieder zurück zu setzen. Der ABAP wurde vergessen und nie gelöscht.
Überprüfung auf ABAP Code Sicherheit im Unternehmen
Aber ist das eigene System wirklich sicher? Ähnlich wie bei einem SAP Penetration Test wird hier das kundeneigene SAP-System oder SAP HANA System auf Sicherheit überprüft.
Es gibt Werkzeuge, mit denen sich die kundeneigenen Programme in einem Massenverfahren analysieren lassen. Die daraus gewonnen Ergebnisse und Erkenntnisse müssen dann in ein Projekt zur Schwachstellen-Behebung („Get Clean“) und dann in ein Projekt „Sichere ABAP-Programmierung“ („Stay Clean“) überführen.
Benefit auch für die zukünftige S/4 HANA Migration
Die Bereinigung von kundeneigenem SAP ABAP Code auf Basis eines Security-Projektes ist auch ein Anfang in Bezug auf eine anstehende SAP HANA Migration. Denn die Benutzung des SAP ATC (ABAP Test Cockpit) für die Sicherheitsanalysen und die Bereinigung der betroffenen Programme ist auch der Themenkomplex, wenn es um robusten ABAP Code, Performance und zentrale Verwaltung von Richtlinien geht. Ein SAP Security Projekt ist oft der technologische Wegbereiter, auf dessen Basis sich sowohl technologisch wie organisatorisch die S/4 HANA Migration anschließt. Denn auch die Migration setzt Voraus, das keine Sicherheitslücken mehr existieren, aber auch, dass der kundeneigene Code darüber hinaus allen modernen ABAP-Richtlinien entspricht.
Der ABAP Security Check
Am Ende unseres SAP ABAP Sicherheits-Checks steht auch ein dedizierter Vorschlag zum Vorgehen in solchen Projekten.
Das ganze ist in wenigen Tagen abgewickelt und kann auch schnell in ein Projekt umgesetzt werden, alles zu einem Festpreis.