Ganzheitliche Sicherheit für SAP ERP

Thomas WerthWo sind SAP-Systeme besonders angreifbar, welche Teilbereiche muss man daher unbedingt kontinuierlich und automatisiert prüfen, und wie kann man ein ganzheitliches SAP-Sicherheitsmanagement realisieren?

Diesen Fragen geht Thomas Werth, Geschäftsführer von werth IT und Spezialist für IT- und SAP-Security Services, in seinem Gastbeitrag nach. Er macht auch deutlich, wie potenzielle Angreifer denken und vorgehen. Also versäumen Sie nicht, Ihr zur Abwehr von Angriffen notwendiges Wissen zu vervollständigen.

 

 

SAP-Sicherheitsmanagement ganzheitlich aufbauen

Ein Aufbau des in meinem vorherigen Beitrag „Vision Security 4.0“ skizzierten ganzheitlichen Sicherheitsmanagements ist facettenreich und kann nur in Teilschritten erfolgen: Zunächst ist für die Teilbereiche jeweils ein ganzheitliches Sicherheitsmanagement zu erstellen, um anschließend alles zu einem Ganzen zu verbinden. Der Aufbau eines Teilbereichs wird am Beispiel SAP-ERP Systeme im Folgenden dargestellt.

Zunächst sind die für einen ganzheitlichen Ansatz relevanten Prüffelder bei SAP-ERP Systemen zu identifizieren. Diese lassen sich unter anderem aus Best-Practice Vorgaben ableiten, beispielsweise dem DSAG-Prüfleitfaden, Security-Guides des Herstellers oder Empfehlungen zum BSI-Grundschutz. Zusätzlich sollten dabei auch bekannte erfolgreiche Angriffe und Statistiken anhand veröffentlichter SAP-Security-Notes beachtet werden.

Im weiteren Schritt gilt es dann, eine automatische Überwachung der identifizierten Prüffelder einzurichten, um im letzten Schritt die Daten in ein zentrales Security-Dashboard zu überführen. Idealerweise mit der Option, Sicherheitsdefekte auf Knopfdruck reparieren zu können.

 

„Will man SAP-Security ganzheitlich angehen, benötigt man eine Risikoanalyse, ein Umsetzungskonzept und Echtzeittools mit SIEM-Integration.“

Thomas Werth – Geschäftsführer werth IT

 

Prüfbereiche bei SAP-ERP Systemen

Im ersten Schritt sind alle relevanten Prüfbereiche für einen ganzheitlichen Sicherheitsansatz bei SAP-ERP Systemen zu bestimmen:

 

Prüfung SAP-Berechtigungen

Wenn es um die Sicherheit von SAP-Systemen geht, denken viele zunächst an Berechtigungen. Denn Berechtigungen regeln, auf welche Daten und Funktionen ein gültiger Benutzer zugreifen darf. Berechtigungen sind anhand eines rollenbasierten Berechtigungskonzeptes zu vergeben. Dies soll die Einhaltung der gesetzlichen Vorgaben aus den GoB und HGB sicherstellen. Ebenso greifen hier Anforderungen aus der DSGVO. Im Kern müssen das Identitätsprinzip, Minimalprinzip, Stellenprinzip sowie Funktionstrennungsprinzip im Berechtigungskonzept Anwendung finden.

Ohne ein funktionierendes Berechtigungskonzept ist ein IT-System nicht gegen Missbrauch geschützt. Ein Beispiel hierfür ist der Fall einer Mitarbeiterin des städtischen Service-Zentrums „Kasse.Hamburg“ aus 2017, die über einen privilegierten Account insgesamt 418.000 Euro innerhalb von vier Monaten unterschlagen hat.

Damit ist klar, dass die Berechtigungen als Prüfbereich zu betrachten sind. Dies belegt auch deren hohe Bedeutung bei Wirtschaftsprüfungen eines Betriebes oder die Anzahl der Prüfungen im DSAG-Prüfleitfaden. Findige Angreifer suchen daher nach anderen Wegen in das System, bei denen das Berechtigungskonzept ausgehebelt werden kann. Dieses Vorgehen führt zu den weiteren Prüfbereichen.

 

Prüfung Custom ABAP Code

SAP-Systeme sind und bleiben Standard-Systeme, die somit „out of the box“ nicht passend für ein individuelles Unternehmen vorbereitet sein können. Daher bieten diese Systeme die kundenseitige Erweiterung über Custom ABAP Code an. Genau dort liegt auch schon der erste Weg das Berechtigungskonzept zu umgehen.

In den eigenen Programmen muss lediglich die eigentliche Prüfung der Berechtigungen fehlen – diese muss jeder Entwickler selbst in ein solches Programm einpflegen. Fehlt die Prüfung der Berechtigung, darf das Programm oder der RFC-Baustein von jedem Benutzer verwendet werden, der auf Custom Programme zugreifen kann. Ebenso können ABAP Programme „spezielle“ Funktionen erst bei einem bestimmten Benutzer oder auf einem besonderen System aktivieren. Solche Funktionen können die Schutzmaßnahmen des Systems über einen gezielten mandantenübergreifenden Datenzugriff oder der direkten Modifikation von Daten in der Datenbank umgehen. Selbst eine ausgereifte „Backdoor“, die Code aus einer beliebigen Datei über die SAP-GUI nachlädt und ausführt, ist mit wenigen Zeilen erstellt.

In der Praxis habe ich solche Backdoors bereits in produktiven Systemen entdeckt. Natürlich ohne Authority-check, dafür aber mit <SID>ADM Zugriff bis zum Betriebssystem. Und solche Backdoor-Programme sind nicht neu, teilweise wurden diese bereits im letzten Jahrtausend in den betroffenen Systemen implementiert. Eine Prüfung des Custom ABAP Codes ist damit im Rahmen eines ganzheitlichen Sicherheitsansatzes zwingend erforderlich. Einen kleinen Eindruck vermittelt die TOP 20 Sicherheitsrisiken in ABAP Anwendungen – ohne dabei jedoch in die Tiefe aller notwendigen Prüfungen vorzudringen.

 

Prüfung SAP-System Konfiguration

Die Härtung der SAP-System Konfiguration stellt den nächsten Prüfbereich dar. Hier dreht sich alles um die Konfiguration des Stacks (ABAP/JAVA). Dazu zählen Passwortrichtlinien, Ablauf von Zugangsdaten oder auch Parallelanmeldungen. Letzter Punkt hätte im Fall der Kasse.Hamburg eventuell Schlimmeres verhindern oder aufdecken können.

Sicher ist auch die Nutzung von abgelaufenen Kennwörtern für die RFC-Anmeldung ein brisanter Punkt. Angreifer nutzen gern den automatisierten Weg über RFC und meiden die SAP-GUI. Sofern ungültige Passwörter dort weiterhin funktionieren, bleibt der Weg für den Angreifer offen. Auch die Nutzung des Passworthashverfahrens ist hier einstellbar. Die Nutzung beispielsweise der alten BCode Hashes ist heutzutage nicht mehr sicher. Dies zeigt eindrucksvoll ein Angriff auf den SAP BOCDE Hash. Innerhalb von 10 Minuten sind über 1500 Benutzer Zugangsdaten geknackt!

 

Angriff auf SAP BCODE Hashes (Quelle: werth IT)

 

Bei über 1.500 Zugangsdaten ist sicherlich der ein oder andere Benutzeraccount unter Kontrolle des Angreifers, der einen kritischen Zugriff auf das SAP-System erlaubt.

Die Konfiguration des Systems deckt somit ein weites Feld ab, ohne hier vollständig beschrieben zu sein.

 

Prüfung Schnittstellensicherheit

Doch wie kann ein Angreifer zunächst an die Hashes gelangen? Einfach ist es, wenn er bereits einen privilegierten Account im System hat. Ein anderer Weg ist der Angriff auf eine der vielen Netzwerkschnittstellen des SAP-Systems. Deren Sicherheit bekommt damit eine hohe Bedeutung. Hierzu zählen der SAP-Start Dienst, SAP HostControl, der ICM sowie der J2EE Dienst. Besonderes Augenmerk haben dabei kürzlich das SAP Gateway und der Monitoring Dienst des Message-Servers erhalten. Unter dem Namen 10KBLAZE sind zwei Werkzeuge veröffentlich worden, die einem Angreifer Zugriff auf das SAP-System verschaffen können.

Ziel des Angriffs ist dabei das SAP Gateway, welches in neueren Releases von SAP mit einer Zugriffsliste geschützt ist. Bei dem neuen Angriff lassen sich aber der Message-Server Monitoring Dienst oder ein schlecht konfigurierter SAP-Router benutzen, um diese Zugriffslisten zu täuschen und dennoch Zugriff auf das SAP Gateway zu erhalten. Dort wird dann ein über 10 Jahre alter Angriff platziert und der Angreifer kann sich Zugriff auf das SAP System verschaffen. Auf diesem Wege kann er auch die Passwort-Hashes aus dem System kopieren und anschließend brechen.

Somit ist die Sicherheit der Netzwerkschnittstellen ein weiterer wichtiger Prüfbereich.

 

Prüfung Patchmanagement

Ein älterer Angriff auf die J2EE Schnittstelle führt direkt in den nächsten Prüfbereich. Ein „einfacher“ Aufruf einer bestimmten J2EE URL im Browser kann einem Angreifer die Übernahme des Systems ermöglichen. Da insbesondere SAP Portale anfällig für diesen Angriff sind und waren, hat SAP schnell einen Patch bereitgestellt. Denn gerade die SAP Portale sind oft an das Internet angebunden und extern erreichbar. Seit 2010 ist ein Patch für diese Schwachstelle verfügbar. Zum weiteren Verständnis ist an dieser Stelle der übliche Kreislauf von Schwachstellen und deren Ausnutzung interessant:

  • Zunächst wird eine Schwachstelle entdeckt. Danach wird Sie entweder von einem verantwortungsvollen Sicherheitsforscher an den Hersteller gemeldet oder möglicherweise im Geheimen ausgenutzt. Im zweiten Fall wird früher oder später dennoch der Hersteller aufmerksam.
  • Hat der Hersteller Kenntnis erhalten, so beginnt er mit der Entwicklung eines Patches. Dieser wird anschließend getestet und freigegeben. Ab dann steht er den Kunden zur Verfügung.
  • Und den Angreifern! Diese analysieren den neuen Patch und erkennen so den eigentlichen Angriffsweg und können dafür Angriffswerkzeuge erstellen.
  • Spätestens ab jetzt ist die Schwachstelle allgemein bekannt und es ist zu erwarten, dass Angriffswerkzeuge existieren.
  • Erst mit dem Einspielen des Patches ist der Kunde vor einer Ausnutzung der Schwachstelle geschützt.

Betrachten wir jetzt die genannte Schwachstelle, die über das Internet die Übernahme von SAP Systemen ermöglicht. Hier erschien 2010 ein Patch von SAP. Sechs Jahre später sah es das US-Cert als notwendig an seinen ersten Alarm für SAP-Systeme zu veröffentlichen. Denn die inzwischen seit sechs Jahren „eigentlich“ gestopfte Sicherheitslücke wurde aktiv ausgenutzt und mindestens 36 große Unternehmen wurden aktiv erfolgreich angegriffen.

Dieses Beispiel zeigt deutlich, dass ein effektives Patchmanagement eine wesentliche Komponente der Sicherheit von SAP-Systemen ist.

 

Prüfung Logging

Damit sind bereits einige Prüfbereiche bekannt. Die Prüfung dieser Bereiche sollte an dieser Stelle nicht mehr in Frage stehen. Doch wie sieht es mit der Erkennung von Auffälligkeiten aus? Wie bemerkt man, wenn etwas „Komisches“ passiert? „Was ich nicht weiß, macht mich nicht heiß“ ist hier die falsche Devise. Hierzu ist das Logging in SAP zu aktivieren. In einem SAP-System gibt es verschiedene Stellen an denen die Protokollierung genutzt werden kann. Bekannt ist sicher das Systemlog, welches automatisch aktiv ist. Dieses dient hauptsächlich der Fehlererkennung und Suche der Fehlerquelle.

Für sicherheitsrelevante Ereignisse ist das Security Audit Log zu nutzen. Die Konfiguration erfordert einige Kenntnis, damit alle relevanten Aspekte auch fälschungssicher protokolliert werden. Hierzu zählen sicherheitsrelevante Änderungen an der SAP-Systemumgebung sowie Transparenz bezüglich erfolgreicher und fehlgeschlagener Anmeldeversuche. Ebenso wie Informationen zur Nachvollziehbarkeit von Ereignissen wie der erfolgreiche oder fehlgeschlagene Versuch eine Transaktion zu starten.

Es stehen in SAP viele weitere Logs zur Verfügung, die für die Kontrolle der Systemsicherheit relevant sein können. Dazu zählen unter anderem das Logging des SAP Gateway, ICM und Web Dispatcher, J2EE, Message Server wie auch die Protokollierung der Änderungsbelege im System.

Die so erhobenen Daten sind dann von Wert, wenn man Ereignisse oder Vorfälle nachvollziehen möchte. So lassen sich beispielsweise folgende Fragen beantworten:

  • Wer hat Daten aus dem System geladen?
  • Wer hat kritische RFC-Zugriffe durchgeführt?
  • Gab es Anmeldungen mit Standardbenutzern?

Solche Fragen sind bei einer forensischen Analyse eines möglichen Sicherheitsvorfalls zu klären.

 

Prüfung Betriebssystem und Datenbank

Da ein SAP-System immer ein Betriebssystem und eine Datenbank für den eigenen Betrieb benötigt, sind diese Komponenten jeweils auch als Prüfbereich zu sehen. Kann ein Angreifer das Betriebssystem übernehmen, dann erhält er auch die Kontrolle über das SAP-System. Eben dieser Umstand macht den 10KBLAZE Angriff so gefährlich, obwohl dieser faktisch „nur“ privilegierten Zugriff auf das Betriebssystem ermöglicht.

In der Vergangenheit hat dies auch die SAP Note „2473454 – Customer Guidance for WannaCrypt attacks“ verdeutlich. Denn SAP musste einen Hinweis für die Sicherheit von Windows veröffentlichen, da die SAP Systeme im Rahmen von WannaCry-Angriffen ausgefallen sind. Das Betriebssystem stellt damit einen weiteren Prüfbereich dar.

Gleiches gilt für die genutzte Datenbank: In der Datenbank liegen sämtliche Kronjuwelen des SAP-Systems. Ist ein unautorisierter Direktzugriff auf diese möglich, kann ein Angreifer vorbei an allen SAP-Sicherheitsmaßnahmen direkt ins Herz des Systems greifen. Diebstahl, Manipulation oder Sabotage von Daten – alles ist möglich. Die Standardtabellen USR02, SSF_PSE_D oder auch UST04 helfen einem Angreifer beispielsweise an Zugangsdaten für das System zu gelangen. Die Sicherheit der SAP HANA Datenbank ist auch hier einzuordnen.

 

Faktor Mensch

Ein relevanter Prüfbereich ist noch zu erwähnen: Der Faktor Mensch, man denke nur an Phishing Angriffe. Dies ist jedoch ein übergreifendes Thema, das eigenständig zu behandeln ist. Auch wenn es natürlich Auswirkung auf SAP-Systeme hat. Dennoch bleibt der Fokus hier auf den technischen Prüffeldern des Teilbereichs.

 

Automatisierte Überwachung der Prüfbereiche

Die zu kontrollierenden Prüfbereiche umgeben das SAP-ERP-System wie ein Schutzwall. Man muss sich bewusst sein, dass eine Schwachstelle in einem der Bereiche ausreicht, damit eine kritische Sicherheitsverletzung gegen das System ausgeführt werden kann.

 

Prüfbereiche für ein ganzheitliches Sicherheitsmanagement bei SAP-ERP Systemen (Quelle: werth IT)

 

Entsprechend ist es notwendig, in allen Bereichen proaktiv zu agieren. Angreifer haben ein Gespür für das schwächste Glied der Kette. Sie nehmen bei ihren Attacken keine Rücksicht, ob ein Prüfbereich nicht zu dem „internen Sicherheitsprojekt“ gehört oder das Zielsystem „zu kritisch zum Patchen“ ist. Sie zeigen auch keine Nachsicht, wenn kein Budget vorgesehen ist oder einfach nur andere Prioritäten gesetzt sind. Jeder Weg ins Ziel ist ihnen recht.

Ein wirksamer Sicherheitsprozess ist damit unabdingbar. Daher ist der Security Prozess mit einem Werkzeug zur Automatisierung zu unterstützen, um in Anbetracht der Komplexität und des Fachkräftemangels handlungsfähig zu bleiben. Eine manuelle Kontrolle der Prüfbereiche ist nicht dauerhaft zu leisten.

 

Anforderungen an SAP-Sicherheitswerkzeuge

Die Anforderungen an ein solches Werkzeug leiten sich aus den Prüfbereichen und dem Ziel der Automatisierung ab. Es muss alle Prüfbereiche wirksam analysieren und bewerten können, sowie die gemessenen Daten inklusive Bewertung und Handlungsempfehlung an ein zentrales Dashboard senden.

Zudem sollte ein Werkzeug mit Zero-Footprint-Ansatz gewählt werden. Dies aus zwei Gründen: Der Fall Stuxnet hat gezeigt, dass im Fall einer Kompromittierung auch die Sensoren und damit die Anzeigedaten manipuliert werden können. Befindet sich die Kontrollinstanz auf den zu überwachenden Systemen, so kann auch die Kontrolllogik manipuliert werden. Zudem reduziert sich deutlich der Aufwand, wenn keine zusätzliche Software auf den zu testenden Systemen installiert werden muss. Oder haben Sie schon einmal erlebt, dass in Ihr Auto für die TÜV Prüfung extra etwas eingebaut wird?

 

Security-Monitoring in der Praxis

Ist ein passendes Werkzeug gefunden und zur kontinuierlichen Prüfung in Betrieb genommen, so wird das angeschlossene Dashboard automatisch mit Daten gefüttert. Ein solches Dashboard bietet verschiedene Möglichkeiten zur Datenvisualisierung und zur Arbeitserleichterung.

 

Security Dashboard Visualisierung (Quelle: werth IT)

 

Der Screenshot zeigt eine Variante: Für den Sicherheitsverantwortlichen bietet dieser Ansatz eine enorme Entlastung. Ohne Zeitaufwand kann er bei Bedarf auf einen Blick den Sicherheitslevel seiner Systeme erfassen. Aktuelle Alarme sind sofort im Blick. Zudem hat er den Nachweis über die Sicherheit der Systeme direkt im Zugriff. Entsprechende Anfragen der IT-Revision, des Datenschutzbeauftragten oder IT-Auditors kann er damit schnell beantworten.

Der ganzheitliche Ansatz bei der Überwachung von SAP-Systemen und die damit einhergehende Automatisierung des Security Management Prozesses funktioniert auf dem hier beschriebenen Weg für SAP-ERP-Systeme.

In der Praxis hat sich dies bereits im Rahmen des Lauffeuers von 10KBLAZE für die Sicherheitsverantwortlichen als sehr nützlich erwiesen. Diese konnten ihre aufgeschreckten Manager schnell durch die grün leuchtenden Anzeigen der 10KBLAZE-Prüfungen im Dashboard wieder beruhigen – ohne jeglichen Aufwand. Wie in vielen Bereichen ist auch auf diesem Gebiet die Automobilindustrie als Vorreiter zu nennen und profitiert bereits heute von deutlich mehr Transparenz und spürbarer Entlastung bei schneller Handlungsmöglichkeit.

 

Wir danken Ihnen, wenn Sie diesen Artikel jetzt weiterempfehlen:

Anzeige

Anzeige

Über die Redaktion IT-Onlinemagazin

SAP-Community Nachrichten, die Entscheider kennen sollten: Abonnieren Sie jetzt unseren IT-Onlinemagazin Newsletter. Lesen Sie Umfrageergebnisse, Insights aus dem SAP-Ecosystem, Interviews und Artikel ... und Sie bleiben kompakt informiert.

Lesetipp für Sie:

SAP Sicherheit erhöhen

SAP Sicherheit: Vier schnelle Möglichkeiten zur besseren Absicherung

Wie kann man in SAP-Landschaften RFC-Schnittstellen, Netzwerkschnittstellen und ABAP-Code sicherer machen, und warum sollte man …