Neue Anforderungen der Fachbereiche und Kundenmärkte führen dazu, dass die unternehmenseigenen SAP-Systeme immer komplexer werden und zahlreiche Einstellungen bieten, die sich jedoch auch auf die Betriebssicherheit auswirken können. Zugleich ergänzen die Anwender viele SAP-Lösungen um Eigenentwicklungen, die oft nur unzureichend auf Qualitäts- und Sicherheitsaspekte geprüft wurden, wie ein aktueller ABAP Quality Benchmark zeigt. Darüber hinaus bietet die zunehmende Vernetzung von SAP-Systemen, zum Beispiel in internationalen Lieferketten, potenziellen Hackern und Cyber-Kriminellen verstärkt zusätzliche Angriffspunkte.

Auf Rollen und Berechtigungen beschränkt

Trotzdem beschränken sich die meisten Anwenderunternehmen noch auf klassische Rollen- und Berechtigungskonzepte, um ihre SAP-Systeme vor fremden Zugriffen zu schützen. Sie lassen dabei außer Acht, dass es für gewiefte Angreifer ein Leichtes ist, auch über kleinste Schwachstellen in der Systemarchitektur, der Konfiguration oder den Programmen in die SAP-Anwendungen einzudringen. Hier können Penetrationstests Abhilfe leisten, indem sie die Hintertüren in den SAP-Systemen entdecken und die Unternehmen für die Notwendigkeit einer ganzheitlichen SAP-Sicherheitsstrategie sensibilisieren.

Penetrationstests empfehlen sich aber auch für Betriebe, die bereits einen umfassenden SAP-Sicherheitsprozess etabliert haben. In diesem Fall bieten die Tests die Möglichkeit, Lücken oder Fehler in bestehenden Sicherheitsprozessen und -maßnahmen zu identifizieren und zu beseitigen, also die SAP-Sicherheit weiter zu steigern. Ebenso lässt sich damit prüfen, ob durch die ständig weiterentwickelten Hackermethoden neue Risiken für die vorhandenen SAP-Anwendungen entstanden sind.

Welche Arten von Penetrationstests gibt es?

Bei den Penetrationstests ist zwischen drei Arten zu unterscheiden:

Black Box - Diese Variante umfasst das Testen einer funktionsfähigen Anwendung ohne interne Kenntnisse des Quellcodes. Obwohl viele Unternehmen dies als realistischen Vergleich zum Vorgehen eines Angreifers sehen, ist zu bedenken, dass ein Angreifer in der Regel deutlich mehr Zeit als ein Penetrationstester hat, um eine Anwendung zu knacken. Darüber hinaus werden Angriffe auch von Innentätern ausgeführt, die im Gegensatz zum Tester sehr wohl über interne Kenntnisse verfügen. Die Folge: Insbesondere Hintertüren werden bei Black Box-Tests oft übersehen.

White Box - Mit White Box wird das Testen einer Anwendung mit vollem Zugriff auf Interna - also den Quellcode - bezeichnet. Diese Methode eignet sich, um Hintertüren vor allem im kundeneigenen ABAP-Code zu finden und komplexe Funktionen effizient zu testen. Allerdings ist dagegen einzuwenden, dass sich das Gesamtsystem unter Umständen anders verhält. So kann ein Reverse Proxy verwundbare Services überdecken, ebenso lassen sich Probleme mit dem TLS-Zertifikat einer Webanwendung ausschließlich am System erkennen, nicht am Quellcode.

Grey Box - Grey Box umfasst das Testen einer funktionsfähigen Anwendung mit vollem Zugriff auf Interna, den Quellcode, und kombiniert damit Black Box- und White Box-Tests. Für Anwender ergeben sich damit folgende Vorteile:

• Gerade beim Einsatz von Tools für automatische Quellcode-Analysen können "Low Hanging Fruit"-Fehler erkannt werden.

• Die Tests verlaufen effizient, da nicht nach dem "Trial & Error"-Prinzip gearbeitet werden muss.

• Daher können auch mehr Tests im gleichen Zeitraum durchgeführt werden.

• Versteckte Funktionen werden erkannt, darunter Hintertüren oder festprogrammierte Passwörter.

Wie sollte ein Penetrationstest ablaufen?

Dreh- und Angelpunkt ist eine gute Abstimmung zwischen SAP-Anwenderunternehmen und dem Dienstleister, der die Penetrationstests ausführt. Dazu sollte gleich zu Projektbeginn ein gemeinsames Verständnis über die zu testenden Unternehmensrisiken und die Aggressivität der Tests hergestellt werden. Denn nicht jedes Unternehmen dürfte erfreut sein, wenn es einem findigen Tester gelingt, die Festplatte seines SAP-Systems zu formatieren. Wichtig ist auch, einen Systemzugang zur Verfügung zu stellen, die Ansprechpartner im Unternehmen zu benennen und die Intervalle der Abstimmungs-Meetings zwischen Kunden und Penetrationstestern zu klären.

Während der eigentlichen Tests sollten Konfiguration und Code zunächst auf typische Risiken hin überprüft werden, die Hackern gängige Einfallstore bieten könnten. Auch empfiehlt es sich, kritische Risiken auszuleuchten und den Anwendern konkret am System zu demonstrieren, welche Attacken dadurch möglich sind. Solche Live-Demos ausgewählter Risiken empfehlen sich auch für den Abschlussbericht und die Abschlussbesprechung am Projektende. Gerade "hartnäckige Zweifler" werden von der Notwendigkeit einer ganzheitlichen SAP-Sicherheitsstrategie überzeugt, wenn sie zum Beispiel vorgeführt bekommen, wie ein Hacker eine vorhandene Schwachstelle nutzen könnte, um Bilanzdaten aus einem SAP-System zu ziehen.

Mit dem Abschlussbericht sollten Kunden eine Liste aller erkannten Fehler einschließlich ihrer Nachvollziehbarkeit erhalten. Damit eine geeignete Priorisierung zur Fehlerbehebung erfolgen kann, darf eine Einschätzung der Kritikalität nicht fehlen. Für die Techniker sollten Lösungsvorschläge enthalten sein, wie sie diese Fehler in der Konfiguration oder im Code effizient beseitigen können. Für das Management hingegen ist relevant, Informationen zu den betriebswirtschaftlichen Risiken sowie Empfehlungen zu erhalten, was auf Prozessebene zu tun ist, um solche Fehler künftig zu vermeiden.

Da die SAP-Systemkonfigurationen sich laufend ändern und die Systeme um Eigenentwicklungen ergänzt werden, ist es wichtig, dass die Penetrationstests regelmäßig stattfinden, zumal sich die Cyber-Angreifer immer neuer, ausgeklügelterer Methoden bedienen. Zahlreiche Praxisbeispiele zeigen: Als Momentaufnahmen der Qualität von Konfiguration und Code sind Penetrationstests wichtige Bau- und Meilensteine eines ganzheitlichen SAP-Sicherheitsprozesses, mit dem sich Unternehmen nachhaltig vor Hackern, Cyber-Angreifern und Innentätern schützen können. Diese Tests entfalten allerdings den meisten Nutzen, wenn sie durchgeführt werden, bevor die SAP-Anwendungen produktiv geschaltet werden.

Beispiele für Hintertüren im ABAP-Kundencode

Hard-codierte Benutzer
Bei der Analyse einer BSP-Anwendung (Business Server Pages) in einem Maschinenbau-Unternehmen entdeckten die Penetrationstester von Virtual Forge eine Webseite, die beim Aufruf nur einen leeren Bildschirm anzeigte. Im Quellcode zeigte sich, dass die Seite eine ABAP-Logik hatte, die prüfte, ob einer von drei hart codierten Nutzern (die wohl die Seite programmiert hatten) am System angemeldet war. Falls nein, wurde ein leerer Bildschirm angezeigt. Falls ja, wurde ein Programm dargestellt, mit dem man sich den Inhalt von Tabellen in der SAP-Datenbank ansehen konnte. Faktisch war dadurch eine Hintertür offen, die es via Internet ermöglichte, jederzeit beliebige Geschäftsdaten auszulesen. Bevor der Maschinenbauer den Penetrationstest beauftragte, war die Anwendung bereits vier Jahre online…

Versteckte E-Mail-Adresse
Bei einer großflächigen Quellcode-Analyse der ABAP-Anwendungen eines Finanzdienstleisters fiel dem Tester-Team auf, das eine hart codierte Google Mail-Adresse verwendete. Bei genauerem Hinsehen zeigte sich, dass dieses Programm als Hintergrunddienst lief und einmal pro Quartal ausgeführt wurde, um die Unternehmensbilanz zu ermitteln - kurz bevor das Unternehmen seine Zahlen veröffentlichte. Vorbei an allen Schutzkonzepten, die das Unternehmen installiert hatte, wurden die Zahlen regelmäßig automatisch an die Google Mail-Adresse übermittelt. Wie sich herausstellte, gehörte sie zu einem Mitarbeiter, der schon seit längerem nicht mehr bei dem Finanzdienstleister beschäftigt war.

Programm ohne Berechtigungsprüfung
Eine fortgeschrittene Variante des generischen Zugriffs auf SAP-Daten fand das Team bei der Quellcode-Analyse bei einem anderen Maschinenbauer. Auf dem Produktivsystem gab es einen selbst entwickelten Report, der bei seiner Ausführung keinerlei Berechtigungsprüfungen durchführte und es dem Aufrufer ermöglichte, den Inhalt beliebiger SAP-Tabellen herunterzuladen. Hinzu kam ein Extra, nämlich die Fähigkeit, die Daten wieder zurück ins SAP-System zu laden und damit beliebige Geschäftsdaten zu löschen oder zu manipulieren. Jeder Nutzer mit Zugriff auf die Transaktionen SE38 oder SA38 konnte diesen Bericht ganz einfach ausführen - in diesem Fall mehr als 750 Personen.