SAP Security: Wo die meisten SAP-Systeme verwundbar sind

Ohne SAP geht in vielen Unternehmen gar nichts. Und genau da tut sich bereits das erste Problem auf: Security-Patches werden oft zu spät eingespielt, weil die Admins sich scheuen, den Betrieb herunterzufahren. Christoph Nagy erläutert die neun typischen Sicherheitsfehler im Umgang mit SAP-Systemen.

Top-Fehler bei der SAP-Sicherheit und wie man sie vermeidet

Von Christoph Nagy, SecurityBridge

Es ist weniger die Frage, ob ein Unternehmen Opfer eines Cyberangriffs auf seine SAP-Systeme wird, sondern vielmehr wann. Bei Vermeidung folgender Fehlerquellen lässt sich das Risiko allerdings deutlich senken bzw. das Eintreffen des Ernstfalls nach hinten verschieben.

Die 9 häufigsten SAP-Security-Versäumnisse

Standardbenutzer mit bekannten Passwörtern

Eine einfache Aufgabe, könnte man meinen. Schließlich lautet eine Grundregel der IT-Sicherheit, immer das ursprüngliche Kennwort zu ändern. Bekanntes Gegenbeispiel: der berühmt-berüchtigte Equifax-Hack – eine der bisher größten Datenpannen –, der zum Teil darauf zurückzuführen war, dass jemand ein Standardpasswort nicht geändert hatte. Bei SAP verhält es jedoch ein wenig anders. Das beginnt bei der Tatsache, dass es nicht nur ein, sondern mehrere Benutzerkonten mit umfangreichen Rechten gibt, die während des Einrichtungsprozesses eines regulären SAP-Systems angelegt werden.

Außerdem können einige Konten knifflig sein – SAP* zum Beispiel. Das Löschen dieses Benutzers verhindert nicht die Möglichkeit, sich mit ebenjener Benutzerkennung anzumelden – unter Verwendung des bekannten Anfangspassworts. Nichtsdestotrotz sollte das Ändern der Standardpasswörter dieser Benutzer eine der ersten Aktionen sein, die man nach der Installation eines SAP-Systems in Angriff nimmt.

Unsicheres Gateway

Das SAP-Gateway ist für die Verwaltung der Systeme zuständig, die auf SAP zugreifen dürfen. Standardmäßig gewährt es buchstäblich jedem Host Zugriff. Auf diesem Wege ließe sich das dem SAP zugrunde liegende Betriebssystem kompromittieren. Daher gilt es, den Zugriff auf diejenigen Hosts zu beschränken, die wirklich Daten mit dem SAP-System austauschen müssen. In den meisten Produktivsystemen wurde das SAP-Gateway heute bereits entsprechend gehärtet. Man trifft allerdings noch immer auf Entwicklungs- oder Qualitätssicherungssysteme mit nicht konfigurierten SAP-Gateways. Ein solches lässt sich dann als Sprungbrett zu anderen Systemen missbrauchen und gefährdet dadurch die gesamte SAP-Landschaft.

Die Konfiguration des Gateways zur Beschränkung des Zugriffs (auf intern bekannte Hosts) ist somit ein wichtiger Baustein zur Gewährleistung der SAP-Sicherheit.

MW-attack-vectors.jpg
Die typischen Angriffsvektoren bei SAP-Systemen (Bild: SecurityBridge)

Nicht eingespielte kritische Patches

Jeden zweiten Dienstag im Monat ist SAP Patch Day, und kritische Patches sind beileibe keine Seltenheit mehr. Dies zeigt einerseits, dass SAP das Thema Sicherheit ernst nimmt und bestrebt ist, Schwachstellen so schnell wie möglich zu beheben. Andererseits sind kritische Patches dann auch der gesamten Hacker-Community bekannt. Für SAP-Kunden bedeutet dies: Sie müssen – was nicht immer einfach ist – die Patches so früh wie möglich implementieren.

Abgesehen vom manuellen Aufwand, der für einige Sicherheitspatches erforderlich ist, sind nicht selten ein Neustart des Systems und weitere Aktionen notwendig, die das SAP-System vorübergehend abschalten. Werden auf diesem System Produktionslinien gefahren, ist ein Anhalten unter Umständen mit hohen Kosten verbunden. Oft ist es nicht einfach, Sicherheitspatches rechtzeitig zu implementieren. SAP empfiehlt seinen Kunden, alle Patch-Hinweise zu prüfen und festzustellen, ob sie auf eines ihrer Systeme zutreffen.

Bei der Analyse der Patches helfen Tools wie das SAP Security Advisory. Eine Security-Plattform mit Sicherheitsmonitoring, das Informationen über SAP-Sicherheitshinweise enthält, reduziert das Risiko, dass ungepatchte Lücken die SAP-Sicherheitslage schwächen, noch weiter.

Unsichere RFC-Schnittstellen

RFC-Schnittstellen (Remote Function Call) verbinden die SAP-Systeme einer ERP-Landschaft untereinander und sind für Angreifer ein ideales Mittel, um von einem System zum nächsten zu springen – wenn die Schnittstellen nicht abgesichert sind, Benutzernamen und Passwörter in den Verbindungsdetails gespeichert sind oder ein Dialog-Login für einen Benutzer aktiviert ist.

Die Herausforderung liegt in der schieren Anzahl der Schnittstellen; selbst in nur einem System fehlt Administratoren oft der Überblick. Ein gut dokumentierter Zustand aller RFC-Schnittstellen ist daher ebenso wichtig wie deren Absicherung.

Unsicherer kundenspezifischer Code

Das ursprüngliche Konzept von SAP war es, Standardsoftware für Standardprozesse bereitzustellen. Schon früh hat der Hersteller jedoch erkannt, dass kein Unternehmen dem anderen gleicht und Prozesse daher angepasst werden müssen. Dies funktioniert u.a. durch benutzerdefinierte Berichte und Anwendungen – was bei SAP-Kunden ein großer Erfolg war. Tatsächlich enthält jedes SAP-System durchschnittlich zwei Millionen Zeilen benutzerdefinierten ABAP-Code. Historisch gewachsene benutzerdefinierte Anwendungen enthalten erfahrungsgemäß viele Schwachstellen. Eine kritische Schwachstelle pro tausend Codezeilen – ein übliches gutes Maß in der Softwareentwicklung – bedeutet im Klartext: Ein normales SAP-System enthält nicht weniger als 2000 kritische Schwachstellen!

Security Awareness Trainings für SAP-Entwicklungsabteilungen helfen, diese Menge zu reduzieren. Zudem unterstützt der Einsatz eines automatisierten Code-Scanning-Tools.

Aktive ICF-Dienste

Im Whitepaper „Secure Configuration of SAP NetWeaver Application Server using ABAP“ listet SAP eine Reihe von Internet-Verbindungsdiensten (im Wesentlichen ICF-Webservices) auf, die als verwundbar bekannt sind und daher, wo vermeidbar, nicht aktiv sein sollten. Das Dokument ist bereits von 2012; erst einige Jahre später unternahm SAP erste Schritte in Richtung Security by Default und deaktivierte die Dienste bei der Installation eines SAP-Systems.

Unsichere Webservices werden nicht nur „spezialisierte“ SAP-Hacker anlocken. Auch andere Angreifer, die mit der SAP-Technologie weniger vertraut sind, werden aktive ICF-Dienste zu nutzen versuchen, um in SAP einzudringen. SAP-Anwender sollten deshalb immer überprüfen, ob diese (und andere) Webservices tatsächlich aktiviert werden müssen, und dabei äußerst restriktiv vorgehen.

Internet-Verbindung über SAP-Router/Web Dispatcher

Auch wenn die ICF-Dienste deaktiviert sind, sollte man SAP-Systeme nicht ohne Sicherheitsmaßnahmen dem Internet aussetzen. Unter S/4HANA und seinen mannigfaltigen Möglichkeiten, sich mit Kunden und Lieferanten zu verbinden und mit ihnen zu interagieren, werden die meisten SAP-Systeme heute auf die eine oder andere Weise immer mit der Außenwelt verbunden sein. Umso wichtiger ist es, dass dies auf sichere Art und Weise geschieht.

SAP-Router, Web Dispatcher und SAP-Gateway sollten daher so gut wie möglich gehärtet werden. Außerdem empfiehlt es sich, die Systeme zu trennen, damit die nach außen gerichteten Anwendungen nicht auf demselben System Daten austauschen wie die internen. Wertvolle Daten auf einem nach außen gerichteten System sind eine Einladung, die kein Angreifer auslässt.

Unverschlüsselter Client-Zugang

Endpoint Security ist in der Cybersicherheitsbranche ein Markt für sich. Anders ist das bei der SAP-Sicherheit, die sich mit der Sicherheit eines SAP-Systems als Ganzem beschäftigt. Zwar sind es im Grunde „nur“ GUI und Browser, die gesichert werden müssen, aber diese Endpunkte sind zugleich die schwächsten Punkte. Benutzernamen, Passwörter, Lieferanten- oder Rechnungsdaten – ein erheblicher Teil der Informationen wird immer noch manuell über ein Terminal eingegeben. Sind diese Daten nicht verschlüsselt, haben Angreifer leichtes Spiel. Vor allem dann, wenn Benutzernamen und Passwörter betroffen sind, können diese Daten noch mehr Schaden im angegriffenen SAP-System anrichten.

Um dies zu verhindern, hat SAP schon vor geraumer Zeit eine eigene Technologie zur Verschlüsselung des Datenaustauschs zwischen Client und Servern entwickelt, die jedoch leider noch immer längst nicht alle Kunden nutzen: SNC (Secure Network Communications). Wir empfehlen die Verwendung von SNC in allen Fällen, ob zwischen Client und Server oder zwischen zwei SAP-Systemen im Allgemeinen.

Die sogenannten vertrauenswürdigen Verbindungen zwischen Entwicklungs- und Produktivsystem sind eigentlich eine gute Idee. Sie ermöglichen den Zugriff auf Remote-fähige ABAP-Funktionen, ohne dass man sich jedes Mal neu anmelden muss – das Zielsystem vertraut darauf, dass das Quellsystem den Benutzer zuvor autorisiert hat. Bei der Verwendung von vertrauenswürdigen Verbindungen muss jedoch unbedingt sichergestellt werden, dass Systeme mit einer hohen Sicherheitsstufe nicht von solchen mit niedrigerer Sicherheitsstufe aufgerufen werden können. Vertrauenswürdige Verbindungen sollten daher nur punktuell eingesetzt werden.

Ungeeignete Berechtigungsvergabe

Einer der größten Sicherheitsfehler liegt schließlich im Bereich der Berechtigungen. SAP erlaubt ein sehr granulares Rollen- und Berechtigungskonzept, mit dem SAP-Systeme perfekt auf die Unternehmensprozesse angepasst werden können. Die Kehrseite dieser Flexibilität ist Komplexität. Aufgrund der zahlreichen Möglichkeiten gehören Rollen- und Berechtigungsprojekte oft zu den komplexesten Projekten in der SAP-Welt.

Aus der Sicherheitsperspektive noch wichtiger ist, dass diese Projekte anfällig für Abkürzungen sind. Anstatt detaillierte Berechtigungen für jeden Benutzer einzurichten, wird der Zugriff auf bestimmte Transaktionen und Prozesse oft großzügig vergeben. Die Gefahr von derart großzügigen Berechtigungen und oft historisch gewachsenen Rollen: Es handelt sich dabei um potenziell schädliche Rollenkombinationen. Ein gutes Beispiel sind Auszubildende: Sie durchlaufen alle Abteilungen, von denen jede ihnen eine Rolle zuweist, die sie für ihre Tätigkeit benötigen. Diese Berechtigungen werden jedoch oft nicht widerrufen, wenn die Auszubildenden die Abteilung verlassen. So erreichen einige gegen Ende ihrer Ausbildung ein – was ihre Befugnisse betrifft – verwaltungsähnliches Niveau.

Die Kontrolle über Rollen und Berechtigungen ist daher einer der wichtigsten Punkte, wenn es um die Sicherheit von SAP-Systemen geht. Tatsächlich war sie einige Jahre lang ein Synonym für die SAP-Security insgesamt.

Bessere Cyberhygiene, bessere Sicherheitslage

Wer die hier beschriebenen Fehler vermeidet, wird Cyberattacken nicht ausschließen können. Der Zeitpunkt ihres Eintreffens wird sich allerdings nach hinten verschieben, und die Folgen eines Angriffs werden zumindest abgemildert. Der SAP-Security-Standard verbessert sich dadurch insgesamt erheblich.

MW-Christoph Nagy, Geschäftsführer von SecurityBridge 1 -Bild SecurityBridge.jpg

Christoph Nagy ist Geschäftsführer und Mitgründer von SecurityBridge. Das Unternehmen mit Hauptsitz in Ingolstadt existiert seit 2011 und ist ganz auf SAP-Sicherheit spezialisiert. Der Ansatz ist dabei auf Bedrohungs- und Anomalieerkennung durch Monitoring in Echtzeit ausgerichtet, denn SAP-Systeme werden immer irgendwann kompromittiert – egal wie gründlich die Cyberhygiene ist.


NCMI GmbH – SecurityBridge, Münchener Str. 49, 85051 Ingolstadt, Tel.: (0841) 93 91 48 40, securitybridge.com

Nützliche Links