SAP-Security: Per Gesetz Chefsache – doch das Monitoring endet vor dem Kernsystem?

In den meisten Unternehmen laufen Finanzen, Personalwesen, Einkauf, Produktionssteuerung und viele weitere Geschäftsprozesse über SAP-Systeme. Ausgerechnet diese Systeme bleiben für klassische Sicherheitswerkzeuge weitgehend unsichtbar.

Wo die Gründe dieser Sicherheitslücke zu finden sind, was Sicherheitsvorfälle die Unternehmen kosten können und warum SAP-Security mit NIS2 und dem novellierten BSI-Gesetz zum Haftungsrisiko für die Geschäftsleitung wird, schildert Christian Schuller (Claranet) in seinem Gastbeitrag für das IT-OnlineMagazin.

---

Warum klassische Werkzeuge SAP-Systeme nicht sehen

Managed Detection and Response (MDR) verknüpft Endpoint-, Netzwerk- und Cloud-Signale mit einem Security Operations Center, ein Ansatz aus der Welt von Windows, Linux und Public Cloud, nicht aus der proprietären SAP-Umgebung. Drei strukturelle Hürden sorgen dafür, dass Angriffe auf SAP-Landschaften lange unentdeckt bleiben können:

• Zugänglichkeit: Sicherheitsrelevante Ereignisse entstehen tief im SAP-System, etwa im Security Audit Log, in Change Documents, bei Berechtigungs- und Tabellenzugriffen und weiteren relevanten Log-Quellen. Diese liegen in proprietären Formaten oder direkt in der Datenbank vor und sind für Agenten auf Betriebssystem- oder Endpoint-Ebene nicht erreichbar. Die Informationen müssen mit SAP-spezifischen Mitteln ausgelesen werden.
• Struktur: Jede dieser Quellen folgt einem eigenen Format. Security Audit Log, Change Documents und Tabellenzugriffs-Protokolle sind untereinander nicht kompatibel. Ohne Normalisierung lassen sich diese Daten in einem Standard-SIEM nicht sinnvoll zusammenführen.
• Interpretation: Selbst normalisierte Daten liefern noch keine Erkenntnis. Damit ein SIEM sicherheitsrelevante Muster erkennt, braucht es SAP-spezifische Patterns und Use Cases, die die Daten im richtigen fachlichen Kontext auswerten.

Die Folge ist eine Lücke mit zwei Seiten. Von außen sehen Firewall und Endpoint zwar den SAP-Datenverkehr, können Protokolle wie RFC oder DIAG aber nicht interpretieren. Von innen bleiben Berechtigungswildwuchs, Fehlkonfigurationen und ungenutzte Logs unbeachtet.

Der Ernstfall ist keine Theorie

Allein von Januar bis Juni 2026 hat SAP 15 kritische Security Notes mit CVSS-Werten zwischen 9.0 und 10.0 veröffentlicht. Betroffen waren zentrale Komponenten von SAP NetWeaver und der ABAP-Plattform über SAP S/4HANA bis zu SAP Commerce Cloud. Zwischen dem Bekanntwerden einer Schwachstelle und ihrer aktiven Ausnutzung liegen teils nur Stunden. Das hat einen systematischen Grund: Weil ABAP-Quellcode im System offen einsehbar ist, lassen sich aus den Änderungen eines Patches die zugrunde liegenden Lücken ableiten. Angreifer nutzen den Fix als Bauplan für die Entwicklung von Exploits.

Was wirksame Erkennung leisten muss

Aus den drei zuvor genannten strukturellen Hürden lassen sich zwei Anforderungen ableiten, an denen sich jede Lösung messen lassen muss. Sie braucht erstens eine SAP-fähige Datenbasis, die Zugänglichkeit und Struktur der Quellen löst und sicherheitsrelevante Ereignisse so aufbereitet und normalisiert, dass ein SIEM sie überhaupt verarbeiten kann. Sie braucht zweitens eine Auswertung mit SAP-Kompetenz, weil erst fundiertes SAP-Wissen, von Berechtigungsmodellen über Geschäftsprozesse bis zur technischen Systemarchitektur, aus normalisierten Daten auch belastbare Entscheidungen macht.

Darüber hinaus kann eine verhaltensbasierte Analyse, etwa durch UEBA, die Erkennung zusätzlich schärfen. Sie erkennt Abweichungen vom Normalverhalten, etwa Buchungen außerhalb üblicher Zeiten oder untypische Muster privilegierter Konten, und greift damit dort, wo starre Regeln an ihre Grenzen stoßen. Sie ersetzt die ersten beiden Anforderungen aber nicht, sondern baut auf ihnen auf.

Keine dieser Anforderungen wirkt für sich. Ein aktiviertes Audit Log ohne Auswertung gleicht einer Überwachungskamera, deren Aufnahmen niemand ansieht. Die eigentliche Aufgabe liegt im Zusammenspiel, und genau dort, in der praktischen Integration, entscheidet sich, ob aus Sichtbarkeit auch Schutz wird.

Compliance macht die Lücke zur Chefsache

Mit der Umsetzung der NIS2-Richtlinie in deutsches Recht ist SAP-Security zur Aufgabe der Geschäftsleitung geworden. Das novellierte BSI-Gesetz gilt seit dem 6. Dezember 2025. § 30 BSIG definiert zehn Mindestmaßnahmen für das Risikomanagement, von der Risikoanalyse bis zur Zugriffskontrolle. § 38 BSIG macht die Geschäftsleitung persönlich verantwortlich, diese Maßnahmen umzusetzen und ihre Umsetzung zu überwachen. Diese Pflicht ist nicht delegierbar. Die operative Durchführung lässt sich abgeben, die Leitungs- und Überwachungsverantwortung nicht.

Bei schuldhafter Pflichtverletzung haftet die Geschäftsleitung persönlich nach den Regeln des Gesellschaftsrechts, also nach § 43 GmbHG oder § 93 AktG, unter Umständen mit dem Privatvermögen. Ob die Mindestmaßnahmen überhaupt umgesetzt werden, ist dabei eine Legalitätspflicht. Wer bewusst auf eine SAP-Risikoanalyse verzichtet, dürfte sich dabei kaum auf den unternehmerischen Ermessensspielraum der Business Judgment Rule berufen können. Für den Finanzsektor ist seit dem 17. Januar 2025 die DORA-Verordnung in Kraft, die unter anderem ein dediziertes IKT-Risikomanagement und die Steuerung externer Dienstleister verlangt.

SAP-Security: Vom blinden Fleck zur Transparenz

Der Verweis auf ein vorhandenes MDR genügt hier nicht. Für die Geschäftsführung ist eine schlichte Frage entscheidend: Weiß das eigene SOC, was im SAP-System geschieht? Punktuelle Maßnahmen wie ein einzelner Penetrationstest oder eine isolierte SoD-Analyse erzeugen Momentaufnahmen, aber keine dauerhafte Sichtbarkeit. Der erste Schritt ist, die eigene SAP-Landschaft überhaupt sichtbar zu machen.