SAP Enterprise Threat Detection (ETD) ist das SIEM für die SAP-Welt. Was nüchtern klingt, ist in der Praxis ein mächtiges, aber auch anspruchsvolles Werkzeug. Dieser Beitrag erklärt, wie ETD vom Rohlog zum Alarm kommt, was es gut macht und wo die ehrlichen Grenzen liegen.
Kurzfassung
ETD sammelt sicherheitsrelevante Logs aus der SAP-Landschaft in Echtzeit, normalisiert sie zu einheitlichen Ereignissen und prüft sie gegen Patterns, also Erkennungsregeln. Trifft ein Pattern, entsteht ein Alert. Die Stärke liegt im SAP-spezifischen Verständnis (Anwendungs- und Datenbankebene, manipulationssichere Loglieferung). Die Schwäche liegt nicht im Produkt, sondern im Aufwand: Ohne gepflegte Logquellen, getunte Patterns und Menschen, die Alerts auch ansehen, bleibt ETD ein teurer Datensammler.
Was ETD ist, und was nicht
ETD ist ein Security Information and Event Management speziell für SAP. Es versteht SAP-Semantik, also was ein Debug-Zugriff, eine kritische Berechtigungsänderung oder ein Tabellenzugriff bedeutet, statt nur Textzeilen zu zählen. Genau das unterscheidet es von einem generischen SIEM, dem die SAP-Bedeutung fehlt.
Was ETD nicht ist: kein Selbstläufer und kein Ersatz für einen SOC. Es liefert Alerts, aber die Bewertung, Eskalation und Reaktion bleibt menschliche Arbeit.
Das Produkt gibt es in drei Ausprägungen, die sich in Betrieb, Funktionsumfang und Preis unterscheiden:
- ETD (on-premise): klassische Installation im eigenen Rechenzentrum, aktuell als Version 2.0. Volle Kontrolle, voller Eigenbetrieb.
- ETD, private cloud edition: als SAP-gemanagter Service, Teil der erweiterten Security- und Compliance-Angebote.
- ETD, cloud edition: das SaaS-Angebot, auf S/4HANA zugeschnitten, inklusive Managed-Security-Komponente durch SAP.
Wie ETD funktioniert
Der Weg vom Ereignis zum Alarm läuft in vier Stufen:
- Sammeln. Quellsysteme liefern ihre Sicherheitslogs an ETD. Ein wichtiges Detail: ABAP-Systeme können Logs über eine eigene Kernel-Schnittstelle direkt senden, was Manipulation deutlich erschwert. Ein Angreifer, der seine Spuren im Log verwischen will, kommt an diesem Kanal schwerer vorbei.
- Normalisieren. ETD übersetzt die unterschiedlichen Logformate in ein einheitliches Ereignismodell. Erst dadurch lassen sich Vorgänge aus verschiedenen Systemen überhaupt vergleichen und verketten.
- Korrelieren und prüfen. Die normalisierten Ereignisse laufen gegen die Patterns. Hier entscheidet sich, ob aus tausenden harmlosen Vorgängen das eine verdächtige Muster herausgefiltert wird.
- Alarmieren und untersuchen. Trifft ein Pattern, entsteht ein Alert. Daran hängen Werkzeuge für die forensische Analyse, Threat Hunting und die Nachverfolgung, wer wann was getan hat.
Patterns: das Herz der Erkennung
Patterns sind die Regeln, an denen sich die ganze Erkennung entscheidet. ETD bringt einen Satz vordefinierter Patterns mit, gruppiert in thematische Workspaces. Typische Beispiele:
- wiederholte fehlgeschlagene Anmeldungen (Brute Force)
- verdächtige oder ungewöhnliche Logins
- Zugriffe auf kritische Ressourcen
- unautorisiertes Debugging
- verdächtige Datenmanipulation
Die mitgelieferten Patterns speisen sich aus mehreren Quellen, unter anderem dem ERP-Auditing-Leitfaden der DSAG, SAPs Anomaly Detection Lab und den SAP Security Notes. SAP aktualisiert diesen Content laufend, was gerade gegen neue Angriffstechniken wichtig ist.
Der eigentliche Hebel liegt aber bei den eigenen Patterns. ETD erlaubt es, ohne eine Zeile Code maßgeschneiderte Erkennungsregeln zu bauen, etwa für firmenspezifische kritische Transaktionen oder Tabellen. Genau hier entscheidet sich, ob ETD zu deiner Landschaft passt oder nur Standardware abdeckt.
Stärken
Was ETD gegenüber einem generischen SIEM auszeichnet:
- SAP-Semantik nativ. Es weiß, was ein Ereignis im SAP-Kontext bedeutet, nicht nur, dass eine Logzeile existiert.
- Anwendungs- und Datenbankebene. Erkennung greift sowohl auf dem Application Server als auch auf HANA-Ebene.
- Manipulationssichere Loglieferung über die Kernel-Schnittstelle.
- Pseudonymisierung von Nutzerdaten mit gesonderter Berechtigung zur Auflösung, wichtig für Betriebsrat und Datenschutz.
- Echtzeit statt nachgelagerter Auswertung.
Grenzen, ehrlich betrachtet
Hier der Teil, den Produktfolien gern weglassen, der aber über Erfolg oder Frust entscheidet:
- Pattern-Qualität ist gleich Erkennungsqualität. Schlecht getunte Patterns produzieren entweder eine Alarmflut oder übersehen das Wesentliche. Ohne kontinuierliches Tuning ersäufst du in False Positives.
- Logabdeckung ist die Achillesferse. Was nicht als Log geliefert wird, sieht ETD nicht. Lücken in den Quellsystemen sind blinde Flecken, egal wie gut die Patterns sind.
- Es braucht Menschen. Alerts ohne Analysten sind wertlos. ETD ersetzt keinen SOC, es füttert ihn.
- Sizing und Kosten. Die Datenmengen sind erheblich, das schlägt sich in Infrastruktur und Lizenz nieder. Das gehört vorab realistisch geplant.
Keiner dieser Punkte ist ein Argument gegen ETD. Es sind die Stellen, an denen ein Projekt scheitert, wenn man sie ignoriert.
ETD und das übrige SIEM
ETD muss kein Inselsystem sein. Im Gegenteil, der sinnvollste Aufbau in vielen Häusern ist: ETD als SAP-Sensor, der ins zentrale SIEM einspeist. ETD versteht die SAP-Welt, das zentrale SIEM hat den Gesamtblick über die IT.
Für die Anbindung gibt es etablierte Wege, unter anderem eine native Integration mit Microsoft Sentinel sowie Anbindungen an Splunk und ArcSight. Damit landen SAP-Alerts dort, wo deine Analysten ohnehin hinschauen, statt in einer separaten Oberfläche zu verstauben. Genau dieser Punkt, Alerts an den Ort bringen, an dem reagiert wird, entscheidet oft über den praktischen Nutzen.
Praxis: woran ein gutes ETD-Setup hängt
Wenn ich das Wichtigste auf wenige Punkte eindampfe:
- Logquellen vollständig anbinden. Erst Abdeckung, dann Feintuning. Ein blinder Fleck nützt dem besten Pattern nichts.
- Patterns iterativ tunen. Mit den Standard-Patterns starten, Fehlalarme analysieren, eigene Patterns für die wirklich kritischen Vorgänge bauen.
- Pseudonymisierung sauber regeln. Wer darf Klarnamen auflösen, unter welchen Bedingungen? Das früh mit Datenschutz und Betriebsrat klären, nicht erst im Ernstfall.
- Alert-Routing festlegen. Dorthin, wo reagiert wird (zentrales SIEM, Ticketing, Chat-Kanal des Teams), nicht in ein totes Postfach.
- Content aktuell halten. Neue Angriffstechniken brauchen neue Patterns. Die regelmäßigen SAP-Updates einspielen, nicht liegen lassen.
ETD ist kein Knopf, den man drückt. Es ist ein Sensor, den man baut, pflegt und an die eigene Landschaft anpasst. Wer das akzeptiert, bekommt eine Sichtbarkeit auf SAP-Angriffe, die ein generisches SIEM so nicht liefern kann.
Quellen
- SAP Help Portal: SAP Enterprise Threat Detection
- SAP Help Portal: SAP Enterprise Threat Detection, Cloud Edition
- SAP Produktseite: Enterprise Threat Detection
- SAP Community: Enterprise Threat Detection Topic Page
- SAP Community: ETD cloud edition und Microsoft Sentinel