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:

Wie ETD funktioniert

Der Weg vom Ereignis zum Alarm läuft in vier Stufen:

  1. 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. Allerdings hatten wir hier interessante Effekte, nicht alle Daten kamen an. Ferner gibt es kein Caching, wenn ein System ausfällt werden die erzeugten Logdaten nicht nachgeliefert. Daher ist das klassische Monitoring via Job besser, da es die Logdaten bei Ausfall/Restart sauber nachliefert da es weiß was zuletzt übertragen wurde.
  2. Normalisieren. ETD übersetzt die unterschiedlichen Logformate in ein einheitliches semantisches Datenmodell. Erst dadurch lassen sich Vorgänge aus verschiedenen Systemen überhaupt vergleichen und verketten und das recht leicht. Konkret kann man so semantisch fragen, gab es einen Admin Logon, dies zeigt das ETD an, dann für alle Systeme (HANA, AS ABAP, AS JAVA) da das Event ja in allen gleichermaßen auftreten kann. Macht die Entwicklung der Patterns deutlich einfacher.
  3. 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. Hier kann. man sich schöne Sachen bauen, man filtert wirklich soweit runter bis man meint relevantes zu bekommen, spart einen viele false-positives oder true-positives.
  4. Alarmieren und untersuchen. Trifft ein Pattern, entsteht ein Alert. Dieses kann man sich anzeigen lassen, mit Trigger, Original-Log, normalisierten Log (semantisches Modell). Es erleichtert die Analyse, man benötigt hier aber nach wie vor Skill in der SAP-Technik.

Patterns: kurzer Durchflug

Patterns sind die Regeln über die Alerts ausgelöst werden. ETD bringt einen Satz vordefinierter Patterns mit, gruppiert in thematische Workspaces. Typische Beispiele:

Erfahrungsgemäß sind diese Patterns sehr generisch, bspw. kennt SAP nicht die eigenen produktiven Systeme. Es empfiehlt sich daher diese zu kopieren und auf die eigenen Bedürfnisse anzupassen. Hier gerne ein paar eigene Value Lists anlegen (mit den produktiven Systemen, privilegierten Usern) um die Filterung zu verfeinern. 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, meiner Einschätzung nach hat man aber genug damit zu tun seine eigenen Patterns erstmal sauber zu pflegen und einzurichten.

Stärken

Was ETD gegenüber einem generischen SIEM auszeichnet:

Grenzen, ehrlich betrachtet

Hier der Teil, den Produktfolien gern weglassen, der aber über Erfolg oder Frust entscheidet:

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.

Achtung. Die Alerts müssen verstanden werden, es bringt nichts einen ETD Alarm ins zentrale SIEM zu speißen, ohne Personal mit Knowledge für SAP zu haben. Woher soll ein SOC Analyst wissen, ob eine Anmeldung von DDIC im Mandant 066 in Ordnung ist oder nicht?

Praxis: woran ein gutes ETD-Setup hängt

Wenn ich das Wichtigste auf wenige Punkte eindampfe:

ETD hilft eine Transparenz in die SAP-Landschaft zu bringen, die man sonst nicht hätte. Auch Betriebsprobleme, Fehleranalysen können unterstützt werden. Zusätzlich kann man auf bekannt gewordene Vulnerabilities im SAP-Patchday schnell reagieren, indem man bspw. ein verwundbaren RFC Baustein ins Monitoring nimmt, prüft ob dieser im letzten Monat überhaupt ausgeführt wurde -> so kann man recht schnell sagen, ob man betroffen war, ob man es einfach patchen kann (da es keiner nutzt) und parallel noch sehen, ob es einer nutzt. Schon genial, oder?

Quellen