Sehr viele Konzerne und mittelständische Unternehmen steuern ihre Geschäftsprozesse mit Lösungen von SAP. Datenlecks und Sabotage der SAP-Systeme können für diese Unternehmen katastrophale Folgen haben. Dennoch werden SAP Risiken oft völlig unterschätzt. Dieser Post gibt einen allgemein verständlichen Einblick in einige ausgewählte SAP Sicherheitsrisiken.
SAP-Systeme haben viele spezifische Risiken, die mit "normalen" IT-Sicherheitstests nicht erfasst werden können. Daher bleiben viele dieser Risiken bei Sicherheitskonzepten und konventionellen Penetrationstests unentdeckt. Häufig konzentrieren sich Konzepte und Tests aus Unkenntnis auf das Betriebssystem, die Datenbank, die Verschlüsselung der Datenübertragung und offene Ports. Dies greift jedoch zu kurz.
Was sind nun die SAP-spezifischen Risiken?
Zunächst muss man wissen, dass SAP ein ganzes Arsenal an proprietären Technologien entwickelt hat. Dazu gehören eine eigene Programmiersprache (ABAP), eigene ERP-Server-Lösungen, eigene komplexe Kommunikationsprotokolle, ein eigener Client mit vielen Features, eigene Webserver, eine eigene Datenbank, eine eigene Datenbankarchitektur, eigene Router und vieles mehr. Jede dieser proprietären Technologien birgt spezifische Risiken, die es zu kennen gilt.
Neben den Risiken, die mit der Zusammenstellung und Härtung dieser verschiedenen Technologien verbunden sind, gibt es auch einige organisatorische Herausforderungen.
Jeden zweiten Dienstag im Monat veröffentlicht SAP neue Sicherheitspatches. Anhand der Patches können Angreifer sehr schnell ermitteln, welche Schwachstelle dem Patch zugrunde liegt. Das zeigt sich auch daran, dass nach der Veröffentlichung solcher Patches teilweise innerhalb weniger Stunden Exploits im Internet auftauchen. Unternehmen müssen daher einen Prozess etablieren, der eine schnelle Reaktion ermöglicht. Auf keinen Fall sollten kritische Patches auf die lange Bank geschoben werden. Natürlich sind Patches kein SAP-spezifisches Problem. Aber ein SAP-System kann man nicht (wie das Betriebssystem eines Laptops) mal kurz herunterfahren. Schließlich will das Unternehmen produktiv bleiben. Unternehmen sollten daher einen Patch-Prozess etablieren, der die Verfügbarkeit der Systeme sorgfältig gegen die Risiken aktueller Patches abwägt. Obwohl dies vollkommen offensichtlich und allen Sicherheitsexperten bekannt ist, glaubt man nicht, wie oft wir bei unseren Analysen feststellen, dass eine große Anzahl (älterer) Patches erst kurz vor unserem Projekt eingespielt wurde.
Nicht nur der SAP-Standard, sondern auch Lösungen von Drittanbietern sind anfällig für Schwachstellen, wie wir bei unseren Sicherheitstests immer wieder feststellen. Aufgrund der Vielzahl der Anbieter gibt es in diesem Bereich keinen etablierten Prozess für die regelmäßige Veröffentlichung von Sicherheitspatches. Tatsächlich wissen viele Drittanbieter nicht einmal, welche Schwachstellen ihre Anwendungen aufweisen, bis Kunden einen Penetrationstest in Auftrag geben, der auch ihre Lösungen einschließt. Command Injections, hartcodierte Benutzerkonten und Passwörter, pseudokryptographische Verfahren und Directory Traversal Schwachstellen sind in solchen Lösungen häufig anzutreffen.
Leider prüft kaum ein Unternehmen Lösungen oder Updates von Drittanbietern vor deren Installation sorgfältig auf Sicherheitsrisiken. Supply-Chain-Angriffen auf SAP sind damit Tür und Tor geöffnet.
Eine weitere sehr häufige Quelle von Sicherheitslücken sind Eigenentwicklungen, die Unternehmen teilweise seit Jahrzehnten auf ihren Systemen laufen haben. Kaum ein Unternehmen verfügt über ausreichende Programmierrichtlinien für eine sichere Entwicklung. Die Risiken von Schwachstellen in Eigenentwicklungen sind prinzipiell die gleichen wie bei Lösungen von Drittanbietern. Von einfachen Datenlecks bis hin zu Schwachstellen, die zu einem kompletten Systemabsturz führen, findet man bei Quellcodeanalysen alles. Häufig liegen die Fehler aber nicht nur im Code, sondern auch in der Architektur, insbesondere wenn Schnittstellen involviert sind.
SAP Kunden setzen auch vermehrt Cloud Lösungen ein, da SAP dieses Thema intensiv vorantreibt. Da diese Lösungen jedoch völlig anders funktionieren als klassische On-Premise-ERP-Systeme, schleichen sich leicht Fehler ein, die beispielsweise dazu führen, dass beliebige Benutzerkonten Zugriff auf die Cloud-Anwendungen erhalten oder Quellcode auf GitHub auftaucht.
Die meisten der oben beschriebenen Risiken bestehen unabhängig davon, ob Kunden ihr SAP selbst betreiben, bei Dritten hosten oder von SAP hosten lassen (SAP RISE).
Es empfiehlt sich daher, ein umfassendes Sicherheitskonzept speziell für SAP-Lösungen zu haben und Spezialisten hinzuzuziehen, die sich nachweislich mit SAP-Sicherheit auskennen. Der Einsatz von automatisierten Sicherheitsscannern allein hilft nicht weiter, denn die meisten (mittelständigen) Unternehmen sind allein mit der schieren Masse an Ergebnissen aus verschiedensten SAP Sicherheitsbereichen überfordert.
Wenn Sie mehr über SAP-spezifische Sicherheitsrisiken und Gegenmaßnahmen erfahren möchten, empfehlen wir Ihnen die Teilnahme am Cyber Defense Roundtable im Mai in Frankfurt, den wir mitorganisieren.
Weitere Informationen finden Sie unter https://cdrt.net.
