Produktiv und sicher

von Christoph Nagy

SAP ist weltweiter Marktführer für Unternehmensanwendungen und der einzige Softwarehersteller aus Deutschland, der auf dem globalen Markt eine Rolle spielt. Weil auf diesen Systemen die geschäftskritischen Prozesse laufen, müssen sie geschützt werden – in Zeiten zunehmender Cyberkriminalität eine immer größere Herausforderung für Unternehmen. Wir beleuchten in diesem Beitrag die gängigen Angriffsvektoren auf SAP-Systeme.

Herzstück und damit auch das zentrale Bindeglied für die geschäftskritischen Unternehmensprozesse sind die Produkte, die auf der sogenannten NetWeaver-Technologieplattform von SAP basieren. Auf diese konzentrieren sich folglich die Sicherheitsmaßnahmen im SAP-Applikationskontext.

NetWeaver ist die Plattform für Geschäftsanwendungen und bildet die Infrastruktur, auf der alle anderen SAP-Anwendungen laufen. Als Entwicklungsund Laufzeitumgebung für die SAP-Applikationen liegt NetWeaver zwischen diesen und der Datenbank.

Die Grundlage für alle Anwendungen auf NetWeaver bildet der NetWeaver Application Server, der sich in einen ABAPund einen Java-EE-Applikationsserver unterteilt (Stacks). Release 7.4 griff erstmals neue Themen wie In-Memory, Cloud sowie Mobile und Social Media auf. Der ABAP-Stack war mit dieser Version SAPHANA- fähig. Damit bildete NetWeaver 7.4 die Basis für die SAP Business Suite powered by SAP HANA. Die Performance der HANA-Datenbank ließ sich optimal auf der ABAP-Ebene ausnutzen.

Die aktuelle Version heißt NetWeaver 7.5 SP 19 und bietet Entwicklungsabteilungen vor allem eine runderneuerte Basis für die SAP Business Suite und S/4HANA. Sie können nun mit Java 8 programmieren sowie die ABAP Core Data Services nutzen. Da Unternehmen verstärkt auf hybride IT-Landschaften setzen, wurde ferner die Anbindung an die HANA Cloud Platform verbessert.

Schutz bei NetWeaver und Datenbanken

Der NetWeaver Application Server lässt sich auf einer großen Anzahl von Datenbanken (Oracle, DB2, MaxDB, HANA) und Betriebssystemen (Windows, Unix, IBMi, z/OS) ausrollen. Netzwerk-, Betriebssystem- und Datenbank- sowie Clientsicherheit gehören zum untersten Layer der sogenannten Secure Operation Map, die die Basis für alle SAP-Securityrelevanten Themen darstellt.

Selbstverständlich muss jede dieser Komponenten regelmäßig gepatcht, gehärtet und überwacht werden. Für individuelle Datenbanken gibt es eigene Konfigurations- Guides; ebenso ist davon auszugehen, dass viele Unternehmen bereits Härtungs- Guidelines für die gängigen Betriebssysteme im Einsatz haben. Somit richtet sich der Sicherheitsfokus auf den Aspekt Applikationssicherheit, sprich die Technologieplattform NetWeaver – denn deren Konfiguration muss in der Regel das Unternehmen selbst durchführen.

Sicherheit On-Premises, in Public und Hybrid Cloud

Beim On-Premises-Betrieb von SAP-Anwendungen ist das Unternehmen selbst zu 100 Prozent für die Sicherheit seiner Systeme verantwortlich. Immer öfter werden Anwendungen und Services heute jedoch in die Cloud verlagert und ein hybrider Betrieb ist inzwischen fast der Normalfall. Entgegen der allgemeinen Meinung führt die Nutzung einer Hyperscaler- Cloud aber nicht automatisch zu reduzierter Komplexität der eigenen Sicherheitsmaßnahmen.

Das Gegenteil ist der Fall: Es gilt, zusätzliche Netzwerkverbindungen zu sichern, andere Verantwortungen zu berücksichtigen (Shared-Responsibility-Modell) und zusätzliche Angriffsvektoren zu antizipieren. Full-Cloud-Betrieb führt auch nicht dazu, dass sich das Unternehmen nicht mehr selbst um Sicherheit im Application Stack kümmern muss. Wer SAP auf einem Server etwa in der AWS-Cloud laufen lässt, ist nach wie vor für dessen Sicherheit verantwortlich. Selbst beim Application-Management-Servicemodell (bei dem auch der Betriebsaspekt outgesourct wird) verbleibt die Verantwortung für Cybersecurity noch immer voll beim Unternehmen.

Wer sich zum ersten Mal mit Cybersecurity befasst, etwa im Rahmen eines Assessments, steht fast immer zunächst vor einer Wand. Die Probleme scheinen sich zu türmen, doch welches zuerst angehen? Und selbst wenn Unternehmen viel Geld für Security ausgeben – völlige Sicherheit wird es nie geben. Die Antwort kann nur lauten: Weg von den einmaligen Assessments, hin zu kontinuierlichem Vulnerability- und Patchmanagement. Hierbei gilt es zu priorisieren und diejenigen Punkte zu thematisieren, die unternehmensspezifisch das größte Risiko ausmachen oder auch einfach zu beheben sind.

Resilienz gegen Cyberangriffe

Neben der Betriebssicherheit gewinnt zunehmend auch die Resilienz gegen Cyberangriffe an Bedeutung. Deutschland gerät verstärkt ins Visier der Angreifer, weil es ein lukratives Ziel darstellt. Angreifer organisieren sich immer besser und wenden zunehmend professionellere Methoden an. Durch Ransomware entsteht in Deutschland mittlerweile ein jährlicher Schaden von rund 24 Milliarden Euro, demgegenüber steht eine Aufklärungsquote des LKA von gerade einmal 29 Prozent.

SAP informiert auf seinem monatlichen Security Patch Tuesday über die neuesten, von SAP selbst, aber auch Kunden, Partnern und Security-Fachleuten (im Rahmen von Bug-Bounty-Programmen) aufgedeckten Schwachstellen.

Die dazugehörigen Patches, wie die Lücken zu schließen sind, werden gleich mit bekanntgegeben. Ab dann beginnt der Wettlauf zwischen Angreifern und Verteidigern, den Letztere nur gewinnen können, wenn sie den Patch schnell genug installieren.

So gut und sinnvoll der Patch Day ist: Kein Anwenderunternehmen sollte allein darauf vertrauen. Denn es ist davon auszugehen, dass unter dem Radar sogenannte Zero-Days existieren – Schwachstellen, die noch nicht allgemein bekannt sind und für die es kein Sicherheitsupdate durch den Hersteller gibt.

Wie also das Problem angehen? Die Antwort ist in ihrer Grundaussage recht einfach: Je besser IT-Experten die eigene SAP-Angriffsfläche kennen, desto eher verringern sie das Risiko der Ausnutzung der unbekannten Schwachstelle.

Unternehmen müssen davon ausgehen, dass jede Anwendung (und damit auch jedes SAP-System) schwerwiegende Sicherheitslücken enthält, die sich nicht schließen lassen, da kein Patch verfügbar ist. Auf den nächsten Patch Day zu warten, kann hier keine Lösung sein, da Kriminelle die offene Lücke bereits kennen und ausnutzen können.

Eigene Schwachstellen kennen

Schwachstellen verändern sich in komplexen Umgebungen permanent, insbesondere unter dem Vorzeichen anstehender S/4HANA-Migrationen und dem Cloud-first-Ansatz von SAP. Das ERPSystem ist keine Box, deren Sicherheit sich durch Anschluss an ein Security Information and Event Management (SIEM) herstellen lässt. SIEM-Systeme sammeln Logdaten, Alarme und sonstige Meldungen und werten sie aus. So erkennen sie außergewöhnliche Muster in IT-Systemen und alarmieren bei einem Angriff.

Mit SAP Enterprise Threat Detection hat SAP ein solches Werkzeug entwickelt, das sich ergänzend zu herkömmlichen SIEMSystemen einsetzen lässt. SAP ist aber ein sich wandelndes Ökosystem aus technischen Komponenten, die permanent aktualisiert werden. Kunden brauchen deshalb ein Dashboard, das dem Security-, Netzwerk- und SAP-Basisteam gleichermaßen einen Überblick über die aktuelle SAP-Sicherheitslage vermittelt.

SAP-Nutzer müssen sich heute auf ein quasi permanentes Patching unvermittelt auftretender Sicherheitslücken einstellen. Sie brauchen dafür ein zeitgemäßes Security- Mindset, um auch Zero-Days jederzeit habhaft zu werden und SAP-Datenbanken und -Applikationen sicher vor Angriffen zu schützen. Wer seine Einfallstore kennt und insbesondere die eigene Angriffsfläche möglichst klein hält, kann mit verhältnismäßig wenig Aufwand schon viel erreichen.

Wichtige Angriffsvektoren verkleinern

Die Angriffsfläche ist die Summe aller möglichen Eintrittspunkte oder Angriffsvektoren, über die ein unbefugter Angreifer auf ein System oder eine Anwendung zugreifen kann, um zum Beispiel Daten zu extrahieren oder sensible Informationen zu manipulieren. Je kleiner sie ist, desto besser lässt sie sich schützen. Im SAP-Kontext sollten webbasierte Zugriffe, für die der Internet Communication Manager (ICM) und der SAP Web Dispatcher zuständig sind, sowie das Internet Communication Framework (ICF) (über die Transaktions-SICF) besonders beobachtet und abgesichert werden. Der Verbindungsaufbau über die RFC Schnittstelle (Remote Function Calls) ist ebenfalls anfällig und kann Datenlecks nach außen verursachen.

Grundsätzlich gilt es, alle exponierten Dienste (HTTP, HTTPS, SOAP, WebService, APIs) kontinuierlich zu bewerten und inventarisieren. Jeder Systemdienst, der nicht genutzt wird oder nicht einem bestimmten SAP-Geschäftsszenario dient, sollte deaktiviert werden, um die Angriffsfläche zu verringern. SAP-Dienste, die keine Authentifizierung erfordern, gilt es ganz besonders im Auge zu behalten.

In SAP liegen sie im Namensraum "/public/" (zu finden in der Transaktions- SICF). Dienste wie "/public/system_info" sind die erste Anlaufstelle für Angreifer, um in der Erkundungsphase einer Attacke Informationen über das SAP-System zu sammeln.

Härtung des Gateways

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. Dies lässt sich nutzen, um das SAP zugrundeliegende Betriebssystem zu kompromittieren. Daher gilt es den Zugriff auf diejenigen Hosts zu beschränken, die auch wirklich Daten mit dem SAP-System austauschen müssen.

In den meisten Produktivsystemen wurde das SAP-Gateway heute bereits entsprechend gehärtet. Es sind allerdings noch immer Entwicklungs- oder QA-Systeme mit einem unkonfigurierten SAP-Gateway anzutreffen. Diese lassen sich dann als Sprungbrett zu anderen Systemen missbrauchen und gefährden potenziell 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.

Kritische Patches einspielen

Patches sollten Organisationen nach dem Patch Day so früh wie möglich implementieren. Das ist nicht immer einfach. Abgesehen vom manuellen Aufwand, der für einige Sicherheitspatches erforderlich ist, sind nicht selten ein Neustart des Systems oder weitere Aktionen notwendig, die die SAP-Umgebung vorübergehend lahmlegen. Laufen auf dieser Produktionslinien, ist ein Anhalten mit zum Teil hohen Kosten verbunden.

SAP empfiehlt seinen Kunden, die eigenen Gefahrenhinweise zu prüfen und festzustellen, ob sie auf eines ihrer Systeme zutreffen. Bei der Analyse der Patches helfen Tools wie das SAP Security Advisory. Ein Sicherheitsmonitoring wie beispielsweise die SecurityBridge-Plattform, die Informationen über SAP-Sicherheitshinweise enthält, reduziert das Risiko nochmals, dass ungepatchte Systeme die SAP-Sicherheitslage schwächen.

RFC-Schnittstellen und kundenspezifischer Code

Remote-Function-Call-Schnittstellen (RFC) verbinden die SAP-Systeme einer ERP-Landschaft untereinander und sind damit ein ideales Mittel für Angreifer, um von einem System zum nächsten zu springen – wenn die Schnittstellen nicht abgesichert sind, indem zum Beispiel 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.

Ursprüngliches Konzept von SAP war es, Standardsoftware für Standardprozesse bereitzustellen. Schon früh jedoch hat der Hersteller erkannt, dass kein Unternehmen dem anderen gleicht und Prozesse daher anpassbar sein müssen. 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 Maß in der Softwareentwicklung – bedeutet im Klartet aber auch: Ein normales SAP-System enthält nicht weniger als 2000 kritische Einfallstore.

Aktive ICF-Dienste, SAP-Router und Web Dispatcher

Im Whitepaper "Secure Configuration of SAP NetWeaver Application Server using ABAP" listet SAP eine Reihe von Internetverbindungsdiensten (im Wesentlichen ICF-Webservices) auf, die als verwundbar bekannt sind und daher, wo vermeidbar, nicht aktiv sein sollten. Das Dokument ist bereits von 2012, aber erst einige Jahre später unternahm SAP einen der ersten 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 sein müssen und dabei äußerst restriktiv vorgehen.

Auch wenn die ICF-Dienste deaktiviert sind, sollten IT-Verantwortliche SAPSysteme nicht ohne Sicherheitsmaßnahmen dem Internet aussetzen. Unter S/4HANA und seinen mannigfaltigen Möglichkeiten, sich mit Kunden und Lieferanten zu verbinden und zu interagieren, dürften die meisten SAP-Systeme heute auf die eine oder andere Weise immer mit der Außenwelt verbunden sein. SAP-Router, Web Dispatcher und SAPGateway gilt es daher so gut wie möglich zu härten. 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.

Clientzugang und Berechtigungsvergabe

Endpunktsicherheit ist in der Branche Cybersicherheit ein Markt für sich. Nicht so bei der SAP-Sicherheit, die sich mit der Sicherheit eines SAPSystems als Ganzem beschäftigt.

Zwar sind es im Grunde "nur" GUI und Browser, die abzusichern sind, aber diese Endpunkte sind zugleich die schwächsten Punkte in der SAP-Sicherheit. 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, auf sie zuzugreifen. Vor allem, 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 langer 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).

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

Noch wichtiger aus der Sicherheitsperspektive 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 großzügigen Berechtigungen und oft historisch gewachsenen Rollen:

Es handelt sich dabei um potenziell schädliche Rollenkombinationen. 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.

Fazit

Neben der Betriebssicherheit gewinnt für SAP-Nutzer zunehmend auch die Resilienz gegen Cyberangriffe an Bedeutung. Schwachstellen ändern sich in komplexen Umgebungen permanent, insbesondere unter dem Vorzeichen anstehender S/4HANA-Migrationen und dem Cloud-first-Ansatz von SAP.

Anwenderunternehmen müssen sich daher auf ein quasi-permanentes Patching unvermittelt auftretender Sicherheitslücken einstellen. Unter dem Radar laufen dann noch sogenannte Zero- Days. Ein zeitgemäße und sichere SAP-Aufstellung muss so beschaffen sein, dass sich auch Zero-Days habhaft werden lassen. Nur dann sind SAP-Datenbanken und -Applikationen sicher vor Angriffen geschützt.

Angriffsflächen in SAP-Umgebungen erkennen