Gerade wenn Cyberangriffe eine Kette von Schwachstellen ausnutzen, ist ihre rechtzeitige Identifizierung wichtig. Künstliche Intelligenz kann hier mittlerweile effektiv unterstützen. Sie weist auf Probleme hin und leitet Reaktionen darauf automatisch ein. Ein kühnes Versprechen wäre es hingegen zu behaupten, allein mit KI ließen sich bessere Ergebnisse bei der Sicherheit erzielen. Denn damit sie greift, muss vielmehr der Mensch, sprich das Security-Team, ihr die Voraussetzungen bereiten: durch gewissenhaftes Patchen, sicherheitskonforme Systemkonfiguration und geprüfte Eigenentwicklungen.

Die Angriffsfläche eines SAP-Systems ist die Summe aller möglichen Einstiegspunkte oder Angriffsvektoren, über die Unbefugte darauf zugreifen können. Je kleiner sie ist, desto besser lässt sich die Umgebung schützen. Bei SAP ist diese Fläche von Natur aus recht groß. Sie zu reduzieren, dafür gibt es verschiedene, bewährte Verfahren. Wer die folgenden drei Komponenten der Systemhärtung anwendet, hat damit erst die Voraussetzung für eine KI-gesteuerte SAP-Security geschaffen.

Die bekannteste Methode dürfte das Patchen sein. Jeden Monat veröffentlicht SAP Sicherheitshinweise, sogenannte SAP Security Notes beziehungsweise Patches für bekannte Sicherheitslücken in seinen Systemen. Ihren Implementierungsaufwand gilt es dem Schweregrad, der Relevanz und den Auswirkungen der Schwachstelle auf die SAP-Landschaft gegenüberzustellen. Dabei unterstützt eine Sicherheitsplattform wie SecurityBridge. Nach dem Prinzip eines geführten Ansatzes gibt das Werkzeug Empfehlungen für jede gefundene Schwachstelle und automatisiert zugleich die Implementierung von SAP-Hinweisen und Patches.

Die automatisierte Implementierung von SAP-Hinweisen und Patches mag aus einer High-Level-Perspektive offensichtlich sein. SAP-Sicherheitsfachleute wissen jedoch, wie komplex und heterogen das Thema SAP-Patchmanagement ist. Viele Aktualisierungen erfordern eine manuelle Vor- und Nachbearbeitung, die nur geschulte Fachkräfte durchführen können. Das macht die Automatisierung zu einer großen Herausforderung. Nur Patches, die keine manuellen Schritte erfordern und die als sicher für den Einsatz auf dem Zielsystem gelten, sollten automatisiert freigegeben werden.

Mit jeder neu entdeckten Schwachstelle beginnt ein Wettlauf zwischen Angreifern und Verteidigern. Er kann nur dadurch gewonnen werden, dass Unternehmen entweder Gegenmaßnahmen zum Beispiel im Bereich des Security-Monitorings implementieren oder, falls verfügbar, der Patch vor der Ausnutzung installiert wird. Neben der routinemäßigen Wartung müssen Organisationen auch auf Notfallpatches vorbereitet sein, wie zum Beispiel bei Log4j. Leider gibt es für solche Aktualisierungen kein vorgefertigtes Drehbuch. Hier heißt es, sofortige Entscheidungen auf Grundlage einzelner Anwendungsfälle zu treffen, die nicht auf geplante Ausfallzeiten warten können.

Patchmanagement hilft bei der Implementierung der SAP-eigenen Code-Fixes. Daneben verfügen SAP-Systeme aber noch über viele weitere Parameter und Einstellungen, die das Verhalten der Anwendung beeinflussen. Nicht wenige davon sind sicherheitsrelevant, vergrößern die Angriffsfläche und gehören daher ebenfalls gehärtet.

Dazu zählt die Änderung der (oft unsicheren) Standardeinstellungen und -parameter in von Sicherheitsexperten empfohlene Werte und die Konfiguration der Systemprotokollierung, um eine ordnungsgemäße Forensik zu gewährleisten und alle erforderlichen Aufzeichnungen zu erfassen. Ebenso ist die Absicherung der Kommunikation zwischen verschiedenen Systemen und technischen Komponenten über APIs (HTTP, RFC) und die Aktivierung nur der wirklich benötigten Internet-Communication-Framework-Dienste (ICF) zu gewährleisten.

Es gibt darüber hinaus Best-Practice-Sicherheitsempfehlungen für alle Kommunikationskomponenten (SAP-Router, Message Server, Web Dispatcher, Internet Communication Manager). Weitere integrale Bestandteile der SAP-Landschaft (JAVA-Systeme, SAP Business Objects, verbundene cloudbasierte Systeme, Hardware) sind gleichfalls beim Sicherheitskonzept zu berücksichtigen.

Zur Systemkonfiguration gehört des Weiteren das Thema Zugriffsrechte. Least-Privilege-Prinzip befolgen, die Gruppe der Anwender mit erweiterten Rechten (insbesondere SAP_ALL) klein halten und die Einstellungen der RFC-Destinationen der SAP-Landschaft überprüfen wären hier die wichtigsten Schritte. Wenn jemand über einen ungesicherten RFC-Aufruf von einem weniger kritischen auf ein kritisches System zugreift (sogenannte Directory-Traversal-Attacken), schützt auch ein KI-basiertes Sicherheitsüberwachungssystem die SAP-Anwendung nicht mehr.

SAP-Konfiguration ist keine Neuerfindung des Rads. Es gibt zahlreiche umfangreiche Richtlinien wie die SAP Security Baseline oder Checklisten der deutschsprachigen Anwendergruppe DSAG. Weil es recht mühsam ist, diese Systeme abzusichern und in der Folge auch sicher zu halten, ist eine Automatisierung dieser Sicherheits- und Compliance-Prüfungen ein wichtiger Erfolgsfaktor für die Härtung.

Patchmanagement schließt bekannte Schwachstellen im SAP-Code, aber was ist mit benutzerdefiniertem ABAP-Code? Dort finden sich haufenweise Passagen, die Datenverletzungen ermöglichen oder Cyberkriminellen einen einfachen Weg bieten, in das SAP-System einzudringen. SAP-Teams mögen sich sicher wähnen, da der größte Teil des benutzerdefinierten Codes ungenutzt ist. Doch selbst dann vergrößert er die Angriffsfläche der Anwendung, da er jederzeit reaktiviert werden kann.

SAP-Nutzer dürften angesichts der großen Angriffsfläche durch angesammelte Code-Schwachstellen erschrecken, wenn sie ihre Eigenanwendungen erstmals durch den SAP Code Inspector oder Produkte von Drittherstellern wie den SecurityBridge Code Vulnerability Analyzer jagen. Wie gehen IT-Verantwortliche damit um? Alle Schwachstellen auf einmal zu beheben, würde alle Entwicklungsressourcen auffressen. Hinzu käme der gigantische Testaufwand, der erforderlich ist, um die Korrekturen auf einmal in der Produktion einzusetzen.

Notwendig ist daher ein neues Bewusstsein für sichere Programmierpraktiken. Das Entwicklungsteam muss wissen, wie man eine benutzerdefinierte ABAP-Anwendung ohne Schwachstellen erstellt. Ergebnisse eines Code Vulnerability Analyzers geben dafür Empfehlungen und helfen bei der Kategorisierung der Ergebnisse. Diejenigen, die behoben werden müssen, sind ein Showstopper für jeden Codeeinsatz in der Produktion. Befunde, die sich beheben lassen, geben dem Entwicklungsteam die Flexibilität, auf der Grundlage von Projektzeitbeschränkungen oder Anwendungsauswirkungen im Einzelfall zu entscheiden.

ABAP-Codebereinigung ist ein langwieriger Prozess. Anstelle eines großen Projekts beginnen Unternehmen besser mit der Einrichtung eines einfachen, aber effektiven Sicherheitsgateways innerhalb des Entwicklungsprozesses: Jeder Transport wird vor seinem Import in Testsysteme auf Schwachstellen überprüft. Als Nächstes lässt sich dann die Anzahl der Schwachstellen in den Legacy-Anwendungen Schritt für Schritt reduzieren.

Die Konzentration sollte sich dabei auf den verwendeten Code richten; der nicht verwendete wird eliminiert oder auskommentiert, wenn er als Referenz behalten werden soll. Dadurch kommt er nicht mehr zur Ausführung und hat keine Auswirkungen auf die Angriffsfläche.

Und wenn benutzerdefinierter Code immer noch kritische Schwachstellen aufweist, sollte das SAP-Security-Monitoring darüber informieren, wenn er im System Anwendung findet. Dies geschieht automatisch mit der SecurityBridge Threat Detection, sodass SAP-Teams doppelt überprüfen können, ob es sich um eine beabsichtigte Aktion und nicht um einen Cyberangriff handelt.

Wenn am Ende die drei Härtungsphasen durchlaufen wurden und obendrein noch KI-Praktiken etwa zur Anomalie-Erkennung zum Einsatz kommen, dann haben Unternehmen auf dem Weg zum sicheren SAP-System schon einen bedeutenden Schritt getan.

Es bleibt jedoch weiterhin reine Fantasie, dass die KI selbstständig SAP-Systeme patchen, konfigurieren oder von unsicheren ABAP-Code-Altlasten bereinigen wird. Die Verantwortung für einen sicheren Betrieb bleibt beim Administrator.