Gibt es Plattformen zur Bedrohungserkennung, die SAP-Anwendungen in Echtzeit überwachen können?
Ja. Es gibt drei Arten von Plattformen, die SAP Anwendungen nahezu in Echtzeit auf Angriffe überwachen: SAP Enterprise Threat Detection (ETD) als SAP eigene Lösung, spezialisierte SAP Security Plattformen wie Onapsis, SecurityBridge oder das Xiting SIEM Cockpit sowie SIEM Systeme mit SAP Anbindung, etwa Microsoft Sentinel oder Splunk. Jede dieser Plattformen besteht aus denselben Bausteinen: Logquellen, einem Regelwerk, das Angriffsmuster beschreibt, Alarmen und einer Untersuchungsfunktion (Investigation), mit der aus einem Alarm ein geklärter Vorfall wird. Welche Plattform passt, hängt davon ab, ob bereits ein SIEM und ein Security Operations Center existieren und wie tief die SAP Expertise im Team ist.
Warum brauchen SAP Anwendungen eine eigene Bedrohungserkennung?
Weil klassische Sicherheitswerkzeuge die Anwendungsebene von SAP nicht verstehen. Eine Firewall sieht Netzwerkverkehr, ein Virenscanner Dateien. Ob ein Benutzer über RFC einen kritischen Funktionsbaustein aufruft, Tabellen direkt ändert oder sich eine Debugberechtigung mit Änderungsrecht verschafft, sehen nur Werkzeuge, die SAP Protokolle auslesen und interpretieren.
Welche Plattformen erkennen Angriffe auf SAP Anwendungen?
| Plattformtyp | Beispiele | Stärke | Zu beachten |
|---|---|---|---|
| SAP eigene Lösung | SAP Enterprise Threat Detection (auch als Cloud Edition und als Managed Service) | Tiefe SAP Integration, vorgefertigte Angriffsmuster für SAP | Eigene Plattform neben dem SIEM, SAP Wissen im Betrieb nötig |
| SAP Security Plattformen | Onapsis, SecurityBridge, Xiting SIEM Cockpit | SAP Wissen ist in Regeln und Alarmen schon enthalten, teils kombiniert mit Schwachstellen und Konfigurationsprüfung | Zusätzliches Produkt, Weiterleitung ins SIEM einplanen |
| SIEM mit SAP Anbindung | Microsoft Sentinel solution for SAP applications, Splunk, IBM QRadar | Korrelation von SAP mit Netzwerk, Identitäten und Endgeräten | SAP Use Cases müssen oft erst aufgebaut werden |
Nextado setzt auf der Erkennungsseite das Xiting SIEM Cockpit ein, das SAP Ereignisse überwacht und an ein vorhandenes SIEM übergibt. Details dazu stehen auf der Seite Bedrohungserkennung in Echtzeit für SAP.
Hinweis für Sentinel Nutzer: Microsoft hat den containerbasierten SAP Datenkonnektor am 14. September 2026 eingestellt. Nachfolger ist der agentenlose Konnektor.
Wie funktioniert SAP Bedrohungserkennung für Einsteiger?
Stellen Sie sich eine Alarmanlage für SAP vor. Sie besteht aus vier Bausteinen, die in jeder Plattform vorkommen:
- Logquellen: SAP schreibt auf, was passiert, zum Beispiel im Security Audit Log, in Änderungsbelegen, im Gateway Log oder in den HANA Protokollen. Ohne diese Daten gibt es nichts zu erkennen.
- Regelwerk: Eine Sammlung von Angriffsmustern, die festlegt, welche Ereignisse oder Ereignisfolgen als verdächtig gelten, etwa "SAP_ALL wird vergeben und nach wenigen Minuten wieder entzogen". Gute Plattformen bringen ein vorgefertigtes Regelwerk für SAP mit und erlauben, es an das eigene System anzupassen, zum Beispiel mit Ausnahmen für bekannte Wartungsarbeiten.
- Alarm: Trifft ein Muster zu, entsteht ein Alarm mit Schweregrad, betroffenem Benutzer und System.
- Investigation: Die Untersuchungskomponente. Ein Alarm sagt nur "hier ist etwas auffällig". In der Investigation klärt ein Analyst, ob es ein echter Angriff ist: Was hat der Benutzer davor und danach getan, in welchen Systemen, zu welcher Uhrzeit? Dafür braucht die Plattform eine Suche in den gesammelten Logs, eine zeitliche Abfolge der Ereignisse und die Möglichkeit, zusammengehörige Alarme in einem Vorfall zu bündeln und zu dokumentieren.
Ob eine Plattform wirklich alle vier Bausteine hat, ist ein gutes Auswahlkriterium. Manche Lösungen liefern nur Alarme, und die Untersuchung muss dann mühsam in einem anderen Werkzeug stattfinden.
Welche Stufen der SAP Bedrohungserkennung gibt es?
Einen offiziellen Standard dafür gibt es nicht. In der Praxis hat sich folgende Abfolge bewährt, von der Basis zur Automatisierung:
| Stufe | Was passiert | Typischer Stand |
|---|---|---|
| 1. Daten sammeln | Security Audit Log und weitere Logs sind aktiv, ausreichend groß und werden zentral aufbewahrt | Nachträgliche Analyse ist möglich, Alarme gibt es noch nicht |
| 2. Regeln anwenden | Ein Regelwerk wertet die Logs laufend aus und erzeugt Alarme für bekannte Angriffsmuster | Erkennung nahezu in Echtzeit, Alarme gehen an ein Team |
| 3. Untersuchen und korrelieren | Alarme werden mit Kontext angereichert, über mehrere Systeme und mit SIEM Daten verknüpft und als Vorfälle untersucht | Angriffe über mehrere Systeme werden sichtbar, Vorfälle sind dokumentiert |
| 4. Reagieren und automatisieren | Alarme lösen Tickets oder Gegenmaßnahmen aus, die Regeln werden laufend nachgeschärft, teils kommt Anomalieerkennung dazu | Schnelle, nachvollziehbare Reaktion rund um die Uhr |
Wer zum ersten Mal startet, beginnt mit Stufe 1 und 2 und baut die Untersuchung (Stufe 3) auf, sobald die ersten Alarme sauber laufen.
Was sollte eine gute SAP Bedrohungserkennung erkennen?
Mindestens diese Muster sollten abgedeckt sein:
- Anmeldungen mit SAP Standardbenutzern wie SAP* oder DDIC
- Vergabe und schnelle Rücknahme kritischer Profile, etwa SAP_ALL
- Debugging mit Änderung von Variablen in Produktivsystemen
- Ausführung kritischer Funktionsbausteine über RFC von unbekannten Quellen
- Direkte Tabellenänderungen und Abschalten des Security Audit Logs
- Massenhafte Datenabzüge, etwa über SE16 oder Downloadfunktionen
- Änderungen an Gateway Einstellungen und neuen RFC Verbindungen
Wie wähle ich die passende Plattform aus?
Diese Fragen helfen bei der Entscheidung:
- Gibt es bereits ein SIEM und ein SOC? Dann ist eine Anbindung von SAP an dieses SIEM meist der effizienteste Weg.
- Wer bewertet die Alarme? Ein SOC ohne SAP Kenntnisse braucht gut erklärte Alarme und klare Handlungsanweisungen. Wie SAP technisch an das SIEM kommt, zeigt die Seite zur SAP SIEM Integration.
- Wie viele Systeme und welche Betriebsform? On Premise, RISE with SAP oder hybride Landschaften haben unterschiedliche Logquellen.
- Sollen Schwachstellen und Konfiguration mitgeprüft werden? Dann sind kombinierte Plattformen interessant.
- Gibt es ein SAP Regelwerk und eine Untersuchungsfunktion? Prüfen Sie, wie viele Angriffsmuster mitgeliefert werden, ob Sie eigene Regeln ergänzen können und ob sich Alarme in der Plattform zu Vorfällen untersuchen lassen.
- Welche Nachweise brauchen Prüfer? Berichte für NIS2, ISO 27001 oder die Wirtschaftsprüfung sollten ohne Handarbeit entstehen.
Worauf müssen Einsteiger bei der SAP Bedrohungserkennung achten?
- Erst die Logs, dann die Plattform: Das Security Audit Log muss aktiv und passend konfiguriert sein, sonst fehlen die Daten. Die Logdateien überschreiben sich, wenn sie nicht rechtzeitig weitergeleitet werden.
- Klein anfangen: Zuerst die produktiven Systeme und die wichtigsten Muster abdecken, danach erweitern. Wer alle Regeln auf einmal aktiviert, bekommt zu viele Alarme.
- Regelwerk anpassen: Ein Standardregelwerk kennt Ihre Wartungsfenster und Dienstkonten nicht. Ohne Ausnahmen entstehen Fehlalarme, und das Team gewöhnt sich daran, Alarme zu ignorieren.
- Zuständigkeit klären: Vor dem Start muss feststehen, wer einen Alarm bekommt, wer ihn untersucht und wer entscheidet, was passiert. Eine Plattform ohne Prozess erkennt Angriffe, aber niemand reagiert.
- Datenschutz und Betriebsrat früh einbinden: Die Auswertung von Benutzeraktivitäten betrifft Beschäftigtendaten. Abstimmung, Zugriffsregeln und Aufbewahrungsfristen sollten vor dem Livegang geklärt sein.
- Erkennung testen: Spielen Sie typische Angriffsschritte in einem Testsystem nach und prüfen Sie, ob der Alarm kommt und die Investigation den Ablauf zeigt.
- Mit "Echtzeit" nüchtern umgehen: Gemeint sind meist Sekunden bis Minuten. Ein Alarm hilft nur, wenn jemand zeitnah reagiert.
Reicht Echtzeiterkennung allein aus?
Nein. Bedrohungserkennung zeigt Angriffe, während sie passieren. Wirksamer ist die Kombination mit Prävention: fehlende SAP Security Notes schließen, kritische Berechtigungen bereinigen, unsichere Konfigurationen beheben. Nextado setzt auf der Erkennungsseite das Xiting SIEM Cockpit für die Echtzeiterkennung ein und auf der präventiven Seite Relevan-C für das SAP Schwachstellenmanagement. Bei Auswahl und Anbindung der Plattform unterstützt Nextado im Rahmen von Cybersecurity und Security Monitoring.
Häufige Fragen
Ist SAP Enterprise Threat Detection ein SIEM?
ETD arbeitet ähnlich wie ein SIEM, ist aber auf SAP spezialisiert. Viele Unternehmen leiten ETD Alarme zusätzlich an ihr zentrales SIEM weiter (siehe SAP ETD Integration).
Was bedeutet "Echtzeit" bei SAP Bedrohungserkennung?
In der Praxis spricht man von nahezu Echtzeit: Ereignisse werden innerhalb von Sekunden bis wenigen Minuten ausgewertet.
Brauchen kleine SAP Landschaften eine eigene Plattform?
Nicht immer. Bei einem oder zwei Systemen kann die Anbindung an ein vorhandenes SIEM mit gut gewählten Regeln ausreichen.
Was ist der Unterschied zwischen Alarm und Investigation?
Ein Alarm meldet ein auffälliges Ereignis nach einem Regelwerk. Die Investigation klärt, ob dahinter ein echter Angriff steckt, indem sie das Umfeld des Ereignisses auswertet und zusammengehörige Alarme zu einem dokumentierten Vorfall bündelt.
Fazit
Angriffe auf SAP lassen sich mit SAP ETD, spezialisierten SAP Security Plattformen oder einem angebundenen SIEM nahezu in Echtzeit erkennen. Die beste Wahl richtet sich nach der vorhandenen Sicherheitsarchitektur und danach, wer die Alarme bearbeitet. Entscheidend ist nicht das Werkzeug allein, sondern ein angepasstes Regelwerk, eine Untersuchungsfunktion für die Alarme und ein klarer Reaktionsprozess.
