Ein neuer Trend in der IT-Security ist Threat Intelligence. Dabei geht es darum, Daten bekannter Schadprogramme, Schwachstellen und Angriffsvektoren in einen Kontext zu stellen und so effektiver auf Bedrohungen reagieren zu können. Viele IT-Security-Anbieter sind dazu übergegangen, Threat Detection als Teil oder zusätzliches Feature Ihrer Lösungen zu verkaufen.
Leider ist Threat Intelligence meistens – wie so oft in der IT-Sicherheit – auf die Infrastruktur beschränkt. Unternehmenskritische Anwendungen werden außen vor gelassen. Dabei ist es einerseits gerade in diesem Bereich erstens enorm wichtig, ungewöhnliche Aktivitäten als solche zu erkennen. Zweitens ist es durch die Fokussierung auf bestimmte Applikationen einfacher, Angriffe zu erkennen. Beispiel SAP.
SAP-Systeme enthalten die sensiblen Daten jedes Unternehmens. Ob Mitarbeiterdaten aus dem SAP HR, Finanzdaten aus SAP FI/CO oder Lieferantendaten aus SAP SRM, für Angreifer stellen SAP-Landschaften ein mehr als lohnenswertes Ziel dar. Das hat die Hacker-Community inzwischen erkannt und Angriffe auf SAP-Systeme werden nicht nur häufiger, sie werden immer professioneller durchgeführt.
Leider werden SAP-Systeme in gängigen Sicherheitslösungen oft ausgeklammert, das gilt auch für Threat Intelligence Lösungen. Das liegt zum einen an der grundlegend anderen Technologie, die der Softwarehersteller aus Walldorf verwendet, zum anderen waren SAP-Systeme in der Vergangenheit sowohl technisch als auch organisatorisch vom Rest der IT getrennt – was oft dazu führt, dass die Sicherheitsabteilung sich mit den Besonderheiten der Technologie nicht auskennt, geschweige denn Angriffe erkennen kann.
SAP-Sicherheit wird immer wichtiger
In den letzten Jahren hat ein Umdenken stattgefunden und sowohl die SAP selbst als auch deren Kunden haben die Sicherheit ihrer SAP-Systeme zur Priorität erklärt. SAP-Systeme werden daher immer häufiger in eine umfassende Überwachung der gesamten IT-Landschaft mit eingebunden.
Das Ziel einer Überwachung von SAP-Systemen sollte natürlich sein, mögliche Bedrohung zeitnah als solche zu erkennen und – viel wichtiger noch - reagieren zu können. Studien zeigen, dass zwischen einem eigentlichen Angriff und der Entdeckung dieses Angriffs im Durchschnitt 146 Tage vergehen. In dieser Zeit kann ein Angreifer natürlich immensen Schaden anrichten. Diesen Zeitraum auf wenige Tage oder Stunden zu verkürzen ist daher oberstes Gebot.
Es lohnt sich, den Begriff „Threat Intelligence“ in diesem Zusammenhang näher zu beleuchten. Wenn es um SAP-Systeme geht, werden Angriffe von Hackern zunehmend professioneller. In der Realität werden Angriffe oft orchestriert von langer Hand vorbereitet. Wer eine Analogie bemühen möchte: Hackerangriffe ähneln selten dem klassischen Banküberfall, bei dem ein maskierter Räuber mit der Pistole wedelt und schon nach wenigen Minuten mit einem Sack voller Geld die Bank verlässt. Ein passender Vergleich wäre eher ein Film wie „Oceans Eleven“, bei dem eine ausgeklügelte Vorbereitung dem eigentlichen Clou vorausgeht.
Aus Anomalien mögliche Angriffe erkennen
In IT-Systemen – und damit auch für SAP-Landschaften gültig – erkennt man diese Vorbereitung durch bestimmte Hinweise. Korreliert man diese Hinweise mit anderen auffälligen Aktivitäten, kann ein möglicher Angriff vorliegen. Die Indizien, die auf einen Angriff hinweisen, liegen dabei in der Regel zeitlich deutlich auseinander. Es ist also nicht notwendig, die Protokolldateien, die solche Indizien enthalten können, sekundengenau auswerten zu können. Das hat oft sogar den Nachteil, dass für die Auswertung der meist enorm großen Mengen von Log-Daten enorme Ressourcen benötigt werden. Wichtiger ist eine Korrelationsanalyse, die mögliche Bedrohungen zielsicher entdeckt.
Um eine solche Analyse durchführen zu können, sind vor allem zwei Dinge notwendig: SAP-spezifisches Wissen, um ungewöhnliche Aktivitäten überhaupt erst erkennen zu können. Zweitens müssen diese Daten überhaupt erst einmal erhoben werden.
In der IT-Sicherheit haben sich für diese Art des Security Monitorings in den vergangenen Jahren sogenannte SIEM-Lösungen etabliert (Security Information and Event Management), wie beispielsweise splunk, Q-Radar oder ArcSight. Eingesetzt werden diese SIEM-Lösungen im Rahmen einer kontinuierlichen Überwachung vor allem in Security Operation Center (SOCs). SIEM-Lösungen erkennen auffällige Verhaltensweisen und sind mit Hilfe komplexer Korrelationsregeln dazu in der Lage, sicherheitsrelevante Vorfälle zeitnah zu identifizieren. Allerdings fokussieren sich die SIEM-Lösungen ebenfalls fast ausschließlich auf die Infrastruktur, also Netzwerkkomponenten, Firewalls oder Router. Für die komplexen SAP-Systeme und die Daten, die innerhalb der verschiedenen Anwendungskomponenten anfallen, sind die meisten SIEM-Systeme blind.
Kontinuierliche Überwachung ist wichtig
Für eine umfassende und lückenlose Überwachung von SAP-Landschaften ist eine Lösung notwendig, welche die Aufgaben eines SIEM für SAP-Systeme übernimmt oder eine Schnittstelle zu vorhandenen SIEM-Lösungen anbietet. Um dies zu realisieren müssen alle Vorgänge innerhalb der SAP-Systeme kontinuierlich im Hintergrund überwacht werden, um auffällige Vorgänge jederzeit erkennen zu können. Diese Vorgänge müssen dann miteinander korreliert werden. Dazu ist ein SAP-spezifisches Regelwerk erforderlich, das auch das Nutzerverhalten laufend analysiert. Des Weiteren müssen diese Informationen nicht nur an die Sicherheitsabteilung beziehungsweise an ein angeschlossenes SIEM-System weitergeleitet werden, sie müssen auch so aufbereitet werden, dass es kein SAP-Know- How erfordert, mögliche Bedrohung umgehend als solche zu erkennen.
Hier kommt die SAP-spezifische Threat Intelligence ins Spiel. SAP-Systeme sind extrem komplex, die meisten SAP-Landschaften bestehen aus mehreren, teils gar dutzenden oder hunderten einzelnen Systemen, die unterschiedliche Geschäftsprozesse wie Logistik, Personalwesen oder Produktion abdecken. Hinzu kommt, dass schon ein einziges SAP-System ein Vielfaches an Codezeilen enthält als beispielsweise ein Betriebssystem. Dementsprechend ist es wichtig, alle Schwachstellen innerhalb der SAP-Landschaft zu kennen. Dazu gehören Systemparameter, die Passwortregeln definieren, aber auch potentiell ungesicherte Schnittstellen oder – gerade im SAP-Bereich – von Kunden selbst erstellte Programmierungen. Eine Identifizierung und Absicherung dieser möglichen Schwachstellen ist nicht nur aufgrund der Komplexität der SAP-Systeme eine Herausforderung. Durch laufende Änderungen der Systemkonfiguration, dem Hinzufügen neuer Benutzer oder Berechtigungen und das Transportieren von Änderungen innerhalb der Systemlandschaft sind die Einstellungen zudem hoch dynamisch.
Alle SAP-Bereiche sollten abgedeckt sein
Ein großes Problem stellen auch die umfangreichen und komplexen Berechtigungen innerhalb eines SAP-Systems dar. Zu großzügig vergebene Berechtigungen führen oft dazu, dass ein Nutzer unwissentlich die Möglichkeit hat, kritische Einstellungen zu ändern – ein nicht zu unterschätzendes Sicherheitsrisiko. Und nicht nur das: auch das Thema Compliance ist im Berechtigungswesen ein wichtiger Faktor. Ein gutes Beispiel ist der sogenannte Trainee-Effekt: ein Trainee durchläuft während seiner Ausbildung viele Abteilungen. Auf diese Weise kann es passieren, dass der Trainee am Ende der Ausbildung alle Rechte aller Abteilungen kumuliert hat – was nicht nur zu einem Sicherheitsrisiko führt, sondern auch den Wirtschaftsprüfern auffallen wird.
Um die Schwachstellen in den oben genannten Bereichen frühzeitig zu identifizieren ist ein Scanner erforderlich, der alle Bereiche wie Systemparameter, Schnittstellen aber auch Rollen und Berechtigungen auf mögliche Sicherheitsund Compliance-Probleme überprüft. Bedingt durch die hohe Komplexität schon eines einzelnen SAP-Systems sollte bei der Auswahl einer solchen Vulnerability Management-Lösung zwei Dingen besonders Beachtung geschenkt werden: Einerseits sollte eine Prüfung möglichst umfangreich sein. Die Sicherheitsleitfäden der SAP selbst sowie der Prüfleitfaden der DSAG bieten hier einen guten Anhaltspunkt. Zum anderen sollte ein solcher Scanner in die Echtzeitüberwachung möglichst nahtlos integriert sein, um Änderungen am System frühzeitig zu erkennen und an die verantwortlichen Stellen weiterleiten zu können.
Threat Intelligence im SAP Umfeld besteht dementsprechend aus mehreren Schritten: Schwachstellen müssen zunächst identifiziert werden, die Systeme müssen durch Härtung und passgenaue Berechtigungen geschützt werden und ein kontinuierliches Monitoring muss Anomalien erkennen und einordnen können. Mit diesen Schritten folgt eine SAP-Sicherheitsstrategie weitgehend dem NIST-Framework für Cybersecurity, das vom Nationalen Institut für Standard und Technologie der USA bereitgestellt wird und sich als de-facto-Standard etabliert hat.
Ohne Kontext keine Intelligenz
Für die Threat Intelligence wiederum ist entscheidend, dass diese separaten Schritte in einen anwendungsspezifischen Kontext gestellt werden. Es genügt nicht, eine Datenbank mit standardisierten Schwachstellen eines SAP-Systems vorzuhalten. Vielmehr müssen diese Daten miteinander korreliert werden, unter Berücksichtigung der von Angreifern verwendeten Vorgehensweise. Ein gutes Beispiel ist der 2019 entdeckte Expoit 10KBLAZE. Dieses „Werkzeug“ versucht, über bekannte Schwachstellen und Fehlkonfigurationen in ein SAP-System einzudringen. Das Absichern einzelner Schwachstellen im Visier des Exploits bedeutet nicht notwendigerweise, dass es einem Angreifer nicht gelingen kann, die Systemlandschaft tatsächlich zu kompromittieren. Vielmehr sollte eine Lösung zur Absicherung Schwachstellen und Log-Einträge mit dem notwendigen Hintergrundwissen korrelieren. Nur so kann ein Angriff effektiv erkannt und abgewehrt werden.
Bei der Auswahl einer solchen Lösung sollten zwei Kriterien im Vordergrund stehen. Für die Identifizierung und Beseitigung von Schwachstellen sollte ein möglichst umfassender Katalog an Prüfungen bereitstehen, der sich nach etablierten Standards richtet. Für die Analyse der Aktivitäten wiederum ist eine intelligente Korrelationslösung wichtiger als eine Lösung, die eine sekundengenaue Auswertung verspricht. Anders gesagt: es ist schlauer, die Nadel im Heuhaufen mit einem Magnet herauszuziehen als eine Datenbank zu betreiben, die jeden einzelnen Grashalm separat untersucht.
