So setzen Sie eine SAP-Strategie zur Reaktion auf Sicherheitsvorfälle um: Ein Schritt-für-Schritt-Leitfaden

Die meisten Security Operations Center (SOCs) arbeiten mit einer gefährlichen Wissenslücke. Zwar verfügen sie über ausgereifte Vorgehensanleitungen zur Isolierung infizierter Endgeräte oder zur Sperrung bösartiger IP-Adressen an der Firewall, doch fehlt ihnen oft ein spezifisches Protokoll für das wichtigste Kapital des Unternehmens: das ERP-System.

Diese Lücke ist existenziell. Man kann nicht einfach den „Stecker ziehen“ bei einem produktiven SAP-System, ohne dass dies zu einem Stillstand der Lieferketten, zu einer Unterbrechung der Finanzabschlüsse und zu Ausfallkosten in Millionenhöhe für das Unternehmen führt. Laut Branchenvergleichen kosten ungeplante Ausfälle bei kritischen Anwendungen Unternehmen zwischen 500.000 und 1 Million US-Dollar pro Stunde.

Um dieses Szenario zu vermeiden, müssen Sicherheitsverantwortliche über allgemeine IT-Protokolle hinausgehen und eine spezialisierte SAP Threat Intelligence einführen. Dieser Leitfaden bietet ein schrittweises Verfahren zur Isolierung eines Angreifers innerhalb der SAP-Anwendungsschicht, um die Bedrohung zu neutralisieren, ohne die Geschäftskontinuität zu beeinträchtigen.

Phase 1: Vorbereitung (Checkliste vor dem Einbruch)

Die Reaktion auf Vorfälle beginnt schon lange vor dem Auslösen eines Alarms; sie erfordert vorab genehmigten „Break-Glass“-Zugriff und eine detaillierte Protokollierung, die Standardkonfigurationen nicht bieten.

Wenn Sie erst dann um Administratorrechte bitten, wenn bereits ein Sicherheitsvorfall eingetreten ist, haben Sie bereits verloren. Der Angreifer wird sich in Ihrem System ausbreiten, während Sie auf die Genehmigung durch die entsprechenden Workflows warten. Stellen Sie sicher, dass die folgenden drei Kontrollmaßnahmen unverzüglich umgesetzt werden:

1. Einrichtung eines Notzugangs

Standard-Administratorkonten sind oft die ersten Ziele bei einem identitätsbasierten Angriff. Wenn Ihr Identitätsanbieter (IdP) kompromittiert wird, kann es sein, dass Single Sign-On (SSO) nicht mehr verfügbar oder nicht mehr vertrauenswürdig ist.

• Maßnahme: Erstellen Sie ein spezielles „Firefighter“-Konto (z. B. FF_ADMIN) mit SAP_ALL-Berechtigungen.
• Einschränkung: Dieses Konto muss von SSO/LDAP ausgeschlossen und durch ein komplexes, statisches Passwort geschützt werden, das in einem physischen oder digitalen Tresor gespeichert ist.
• Richtlinie: Erstellen Sie ein Dokument mit „Einsatzregeln“, das die Verwendung dieser ID bei einem bestätigten Vorfall der Schweregradstufe 1 vorab genehmigt.

2. Detaillierte Protokollierung aktivieren

Die standardmäßige SAP-Protokollierung reicht für forensische Analysen oft nicht aus. Um raffinierte Angreifer aufzuspüren, müssen Sie bestimmte Protokolle aktivieren, die den „Kontext“ des Benutzerverhaltens erfassen.

• Maßnahme: Überprüfen Sie, ob das Sicherheitsprotokoll (SM20) aktiv und so konfiguriert ist, dass alle kritischen Ereignisse erfasst werden, darunter erfolgreiche und fehlgeschlagene Anmeldungen, Transaktionsstarts und die Ausführung von Berichten.
• Maßnahme: Aktivieren Sie die Gateway-Protokollierung (SMGW), um externe RFC-Verbindungen zu überwachen. Dies ist entscheidend für die Erkennung von Angriffen, die die Benutzeroberfläche umgehen, wie beispielsweise der 10KBLAZE-Exploit.
• Maßnahme: Stellen Sie sicher, dass die „Read Access Logging“-Funktion (RAL) für sensible Datenfelder (z. B. Kreditkartennummern, Personaldaten) aktiviert ist, um genau festzustellen, welche Daten eingesehen wurden – und nicht nur, welche geändert wurden.

3. Eine forensische Workstation einrichten

• Maßnahme: Richten Sie einen dedizierten „Clean PC“ für das Incident-Response-Team ein. Auf diesem Rechner sollten das SAP GUI installiert sein, Netzwerkzugang zum SAP-Management-Subnetz bestehen und forensische Analyse-Tools vorinstalliert sein. Er muss bis zu seiner Nutzung offline bleiben, um sicherzustellen, dass er nicht kompromittiert wird.

Phase 2: Erkennung und Triage (Ist es echt?)

Das vorrangige Ziel der Triage besteht darin, durch den Abgleich der Benutzeridentität mit dem Verbindungskontext zwischen einer legitimen „Basis“-Verwaltungsaufgabe und einer tatsächlichen Bedrohung zu unterscheiden.

In komplexen SAP-Umgebungen handelt es sich bei „auffälligem“ Verhalten oft lediglich um einen Basis-Administrator, der ein Leistungsproblem behebt. Das Reagieren auf Fehlalarme führt zu einer „Alarmüberflutung“ und stört den Betrieb. Um einen Alarm zu überprüfen, führen Sie die folgenden Triage-Schritte durch:

Schritt 1: Den Nutzertyp analysieren

Unterscheiden Sie zwischen Dialogbenutzern (Menschen) und Systembenutzern (Anwendungen).

• Überprüfung: Überprüfen Sie den Benutzertyp in den Metadaten der Warnmeldung.
• Warnsignal: Wenn sich ein Systembenutzer (wie z. B. DDIC, SAP* oder TMSADM) über das SAP GUI anmeldet (eine „Dialog“-Anmeldung), ist dies ein kritischer Indikator für eine Kompromittierung (IoC). Diese Konten sind fest für die Hintergrundverarbeitung vorgesehen und sollten niemals eine interaktive Sitzung initiieren.

Schritt 2: Überprüfe den Kontext (der „Unmögliche Reise“-Test)

Vergleichen Sie das SAP-Anwendungsprotokoll mit Ihren Netzwerk-/VPN-Protokollen, um die Herkunft der Sitzung zu überprüfen.

• Die Überprüfung: Verwenden Sie die Transaktion SM04 oder Ihre Platform zur Erkennung von Bedrohungen , um die Terminal-ID und die IP-Adresse der verdächtigen Sitzung anzuzeigen.
• Warnsignal: Stimmt die IP-Adresse mit einem bekannten VPN-Knoten überein? Meldet sich der Nutzer von einem Standort aus an, den er zuvor noch nie genutzt hat?
• Der Kontext: Wenn sich ein Benutzer von „Zuhause“ (VPN) und gleichzeitig von „Büro“ (LAN) aus anmeldet, deutet diese gleichzeitige Sitzung häufig auf einen Identitätsdiebstahl hin.

Schritt 3: Transaktionsanalyse (die Kill Chain)

Erfahrene Angreifer nutzen bestimmte Transaktionscodes (T-Codes), um sich erweiterte Zugriffsrechte zu verschaffen oder Daten zu stehlen. Achten Sie auf die Ausführung dieser risikoreichen Transaktionen:

• SM49 / SM69: Dient dazu, Betriebssystembefehle direkt aus SAP heraus auszuführen. Dies ist eine gängige Technik für die laterale Bewegung von der Anwendungsebene auf die Betriebssystemebene.
• SE16 / SE16N: Dient zur Anzeige von Tabellendaten im Rohformat. Angreifer nutzen dies, um die Tabelle USR02 (Passwort-Hashes) oder Kundenstammdaten auszulesen.
• SE80 / SE38: Die ABAP-Entwicklungsumgebung. Die Nutzung durch ein Nicht-Entwickler-Konto in einem Produktionssystem deutet auf den Versuch hin, schädlichen Code (z. B. eine Webshell) einzuschleusen.

Phase 3: Eindämmung (der „Soft Kill“)

Das Ziel der Eindämmung besteht darin, den Zugriff des Angreifers zu isolieren und dessen Verbindung zum System zu unterbrechen, ohne die gesamte SAP-Landschaft offline zu nehmen.

„Den Stecker ziehen“ (den SAP-Anwendungsserver herunterfahren) ist selten die richtige erste Maßnahme. Ein harter Neustart zerstört Daten im Arbeitsspeicher (RAM), die wichtige forensische Beweise enthalten, und verursacht unmittelbare finanzielle Verluste. Führen Sie stattdessen eine gezielte Isolierung durch:

Schritt 1: Identitätsisolierung (Sperren, nicht löschen)

Die sofortige Sperrung des Zugangs hat oberste Priorität.

• Vorgehensweise: Wählen Sie über die Transaktion SU01 (Benutzerpflege) die betroffene Benutzer-ID aus und klicken Sie auf das Symbol „Sperren“.
• Das entscheidende Detail: Löschen Sie das Benutzerkonto nicht. Durch das Löschen der ID werden die mit diesem Benutzer verbundenen Änderungsprotokolle gelöscht, wodurch der Nachverfolgungsnachweis darüber, worauf der Angreifer zugegriffen hat, effektiv vernichtet wird. Sie benötigen diesen Verlauf für die Rechtsabteilung.

Schritt 2: Beenden der Sitzung

Das Sperren eines Benutzers verhindert neue Anmeldungen, unterbricht jedoch keine aktive Sitzung.

• Vorgehensweise: Rufen Sie die Transaktion SM04 (Benutzerliste) auf. Suchen Sie die Terminalsitzung, die mit dem kompromittierten Benutzerkonto verknüpft ist, und wählen Sie „Benutzer abmelden“ / „Sitzung beenden“.
• Überprüfung: Aktualisieren Sie die SM04-Liste, um sicherzustellen, dass der Eintrag nicht mehr vorhanden ist. Sollte die Sitzung weiterhin bestehen, nutzt der Angreifer möglicherweise einen skriptgesteuerten „Keep-Alive“-Mechanismus; fahren Sie mit der Netzwerkisolierung fort.

Schritt 3: Netzwerk- und Schnittstellenblockierung

Wenn der Angriff nicht über eine GUI-Anmeldung, sondern über eine externe API- oder RFC-Verbindung erfolgt, reicht eine Benutzersperre möglicherweise nicht aus.

• Vorgehensweise: Ermitteln Sie mithilfe des SAP-Gateway-Monitors (SMGW) die ID des externen Programms oder dessen IP-Adresse.
• Maßnahme: Aktualisieren Sie die Control (ACLs) für „secinfo“ und „reginfo“, um den Datenverkehr aus diesem bestimmten IP-Bereich ausdrücklich zu blockieren, während die Kommunikation der internen Anwendungsserver weiterhin zugelassen wird.
• Die Infrastruktur: In modernen Umgebungen kann Unified Connectivity (UCON) dazu verwendet werden, bestimmte RFC-Funktionsbausteine (z. B. RFC_READ_TABLE) zu blockieren, ohne die gesamte Verbindung zu unterbrechen.

Phase 4: Beseitigung und forensische Untersuchung (Entfernung von Persistenzmechanismen)

Angreifer nutzen selten nur einen einzigen Zugangspunkt; sie richten Mechanismen zur „Persistenz“ ein (Hintertüren, geplante Aufgaben oder Schadcode), um sicherzustellen, dass sie zurückkehren können, falls das ursprüngliche Konto gesperrt wird.

Sobald die akute Bedrohung eingedämmt ist, müssen Sie diese versteckten Einfallstore aufspüren, bevor Sie das System für sicher erklären.

Schritt 1: Die „Ghost-User“-Prüfung

Angreifer richten oft unmittelbar nach dem Zugriff Ersatzt-Administratorkonten ein.

• Die Maßnahme: Überprüfen Sie die Tabelle USR02 (Anmeldedaten) auf alle Benutzer, die innerhalb von 24 Stunden nach der ersten Warnmeldung angelegt oder geändert wurden.
• Das Warnsignal: Achten Sie auf Benutzer vom Typ „System“, denen das Profil SAP_ALL zugewiesen wurde. Diese werden oft so benannt, dass sie wie legitime Dienstkonten aussehen (z. B. SAP_SUPPORT_01), um einer Entdeckung zu entgehen.

Schritt 2: Die „Code“-Prüfung (Webshells)

In SAP handelt es sich bei „Malware“ oft lediglich um ABAP-Code. Angreifer schleusen „Webshells“ (kleine Programme, mit denen sie über einen Webbrowser Betriebssystembefehle ausführen können) in das System ein.

• Die Aktion: Suchen Sie nach ABAP-Reports oder „Z-Programmen“, die in den letzten 24 Stunden erstellt oder geändert wurden.
• Die Tools: Die manuelle Codeüberprüfung ist zeitaufwändig und fehleranfällig. Verwenden Sie Onapsis Control , um benutzerdefinierte Code-Repositorys automatisch nach bekannten Webshell-Signaturen zu durchsuchen (z. B. COMMAND-Injection oder CALL ‘SYSTEM’).

Schritt 3: Die Transportprüfung

Falls der Angreifer Zugriff auf die Entwicklungsumgebung erlangt hat, könnte er seinen Schadcode von der Entwicklungs- in die Produktionsumgebung „übertragen“ haben, sodass dieser wie eine legitime Änderung aussah.

• Die Maßnahme: Überprüfung des Transportmanagementsystem (STMS) auf alle Transportaufträge, die während des Vorfallszeitraums freigegeben wurden.
• Die Überprüfung: Überprüfen Sie den „Eigentümer“ des Transports. Wenn ein Transport unter der kompromittierten Benutzer-ID freigegeben wurde, muss er unverzüglich zurückgesetzt werden.

Schritt 4: Die Überprüfung des Hintergrundjobs

Angreifer programmieren häufig „Zeitbomben“, damit Schadprogramme erst Stunden oder Tage nach ihrer Entdeckung ausgeführt werden.

• Vorgehensweise: Verwenden Sie die Transaktion SM37 (Einfache Jobauswahl), um alle Hintergrundjobs anzuzeigen, deren Ausführung in den nächsten 7 Tagen geplant ist.
• Das Warnsignal: Achten Sie auf Prozesse, die unter Benutzern mit hohen Berechtigungen (wie SAP* oder DDIC) laufen und externe Betriebssystembefehle ausführen (Programme wie RSCOMMAND oder RSBDCOS0).
• Die Überprüfung: Brechen Sie alle unbekannten Aufträge sofort ab und ermitteln Sie die Benutzer-ID, die sie geplant hat.

Phase 5: Ursachenanalyse

Bei der Wiederherstellung des Betriebs geht es nicht nur darum, die Benutzer wieder freizuschalten. Es muss nachgewiesen werden, dass die Sicherheitslücke geschlossen und das System sicher ist.

Sie können den Vorfall erst dann als behoben betrachten, wenn Sie den Einstiegspunkt des „Patient Zero“ ermittelt haben. Wenn Sie die Ursache nicht verstehen und die Sicherheitslücke nicht schließen, wird der Angreifer einfach wieder eindringen.

Schritt 1: Den Einstiegspunkt patchen

Die forensische Untersuchung sollte Aufschluss darüber geben, wie sich der Angreifer Zugang verschafft hat. War es ein schwaches Passwort? Ein bekannter Exploit wie ICMAD? Oder ein fehlender Patch?

• Die Maßnahme: Führen Sie eine vollständige Schwachstellenanalyse für den jeweiligen Anwendungsserver durch, um fehlende Sicherheitshinweise zu identifizieren.
• Die Lösung: Wenden Sie den entsprechenden SAP-Sicherheitshinweis an oder setzen Sie die Abhilfe unverzüglich um. Warten Sie nicht bis zum nächsten Wartungsfenster.

Schritt 2: Regelmäßiger Wechsel der Anmeldedaten

Gehen Sie davon aus, dass alle während des Vorfallszeitraums verwendeten Administratorzugangsdaten kompromittiert wurden.

• Maßnahme: Zurücksetzen der Passwörter für alle Benutzer mit der Rolle „SAP_ALL“, einschließlich der vom Incident-Response-Team verwendeten „Firefighter“-ID.
• Maßnahme: Falls der Angriff eine externe Schnittstelle betraf, generieren Sie die API-Schlüssel und technischen Benutzerkennwörter, die mit dieser Verbindung verknüpft sind, neu.

Schritt 3: Die „Alles in Ordnung“-Überprüfung

Legen Sie konkrete Kriterien für die Rückkehr zum Normalbetrieb fest.

• Die Überprüfung: Überwachen Sie den jeweiligen Indikator für eine Kompromittierung (IoC) 24 Stunden lang. Wenn der Angriff beispielsweise von der IP-Adresse 1.2.3.4 ausging, stellen Sie sicher, dass im Gateway-Protokoll (SMGW) einen ganzen Tag lang keinerlei Verbindungsversuche verzeichnet werden.
• Überprüfung: Stellen Sie sicher, dass seit Beginn der Eindämmungsphase keine neuen „Z-Programme“ oder Benutzer angelegt wurden.

Häufige Fallstricke, die es zu vermeiden gilt

In der Hitze des Gefechts führt Panik oft zu Fehlern, die Beweismittel vernichten oder den Ausfall verschlimmern.

Vermeiden Sie diese drei häufigen Fehler bei Ihrer Antwort:

1. Der „Neustart“-Reflex: Starten Sie den SAP-Server nicht neu. Ein Neustart löscht den Inhalt des Arbeitsspeichers (RAM), der wichtige forensische Beweise wie aktive Benutzersitzungen und noch nicht gespeicherte Daten enthält. Außerdem wird der Angreifer dadurch darauf aufmerksam gemacht, dass er entdeckt wurde.
2. Das „Silo“-Problem: Die Reaktion auf Vorfälle scheitert oft daran, dass das SOC-Team (das den Alarm sieht) und das Basis-Team (das für das System verantwortlich ist) nicht dieselbe Sprache sprechen. Das SOC sieht „Netzwerkverkehr“, während das Basis-Team „RFC-Aufrufe“ sieht. Überbrücken Sie diese Kluft, indem Sie einen Basis-Techniker fest dem IR-Team zuweisen.
3. Der „Lösch“-Fehler: Löschen Sie niemals einen kompromittierten Benutzer oder eine schädliche Datei. Wählen Sie stattdessen immer „Sperren“ oder „In Quarantäne verschieben“. Das Löschen von Beweismitteln unterbricht die für rechtliche Schritte oder Ansprüche aus Cyberversicherungen erforderliche Beweiskette.

Fazit

Ein Sicherheitsvorfall bei SAP muss keine Katastrophe sein. Mit einer festgelegten Strategie zur Reaktion auf Vorfällekönnen Sie eine potenzielle Katastrophe in ein kontrolliertes Ereignis verwandeln.

Der Unterschied zwischen einer geringfügigen Störung und einem Ausfall, der Schlagzeilen macht, liegt selten in der Schwere des Angriffs. Es kommt vielmehr auf die Schnelligkeit und Präzision der Reaktion an. Indem Sie Ihre „Break-Glass“-Konten vorbereiten, eine detaillierte Protokollierung aktivieren und dieses Playbook einüben, stellen Sie sicher, dass Ihr Team bereit ist, wenn der Alarm losgeht.

Nächster Schritt: Ist Ihr Team bereit, defend wichtigsten Ressourcen zu defend ? Warten Sie nicht auf einen Sicherheitsvorfall, um Ihre Bereitschaft zu testen. Kontaktieren Sie uns , um mit einem SAP-Sicherheitsexperten zu sprechen, oder Fordern Sie eine Demo an , um zu sehen, wie die Onapsis Platform Ihre Reaktion auf Sicherheitsvorfälle automatisieren Platform .

Häufig gestellte Fragen (FAQ)

Warum können wir den SAP-Server während eines Angriffs nicht einfach abschalten? 

Das Herunterfahren eines SAP-Produktionsservers („den Stecker ziehen“) führt zur Löschung der im Arbeitsspeicher befindlichen Daten, die für die forensische Analyse von entscheidender Bedeutung sind. Zudem werden dadurch zentrale Geschäftsprozesse – wie Versand, Rechnungsstellung und Gehaltsabrechnung – unterbrochen, was dem Unternehmen potenziell Kosten in Millionenhöhe pro Stunde verursachen kann. Das Ziel von SAP Incident Response ist es, die Bedrohung zu isolieren („Soft Kill“), während der Geschäftsbetrieb aufrechterhalten bleibt.

Was ist die wichtigste Protokollquelle für die SAP-Forensik? 

Das Sicherheitsprotokoll (SM20) ist die wichtigste Quelle für Informationen zum Benutzerverhalten (Anmeldungen, Transaktionsstarts). Bei externen Angriffen, die die Benutzeroberfläche umgehen, ist jedoch das Gateway-Protokoll (SMGW) entscheidend für die Erkennung böswilliger RFC-Verbindungen. Beide müssen aktiviert und an Ihr SIEM weitergeleitet werden, um eine effektive Erkennung zu gewährleisten.

Inwiefern unterscheidet sich die SAP-Incident-Response von der herkömmlichen IT-Incident-Response? 

Standardmäßige IT-Maßnahmen konzentrieren sich oft auf Endgeräte (Laptops) und basieren auf der Neuinstallation infizierter Rechner. Bei SAP-Maßnahmen liegt der Schwerpunkt auf der Anwendungsebene. Ein ERP-System kann nicht einfach „gelöscht und neu installiert“ werden, ohne dass es zu erheblichen Datenverlusten kommt. SAP IR erfordert ein Verständnis der Geschäftslogik (z. B. „Warum ändert dieser Benutzer die Bankverbindung eines Lieferanten?“) und nicht nur die Erkennung von Malware-Signaturen.

Benötigen wir eine eigene „Firefighter“-ID, wenn wir Single Sign-On (SSO) verwenden? 

Ja. Wenn ein Angreifer Ihren Identitätsanbieter (IdP) kompromittiert, wird Ihr SSO-Mechanismus unzuverlässig oder nicht mehr verfügbar. Sie müssen über ein vorab eingerichtetes lokales Administratorkonto (z. B. FF_ADMIN) mit einem komplexen Passwort verfügen, das in einem sicheren Tresor gespeichert ist, um sicherzustellen, dass Sie im Falle einer Identitätskrise auf das System zugreifen können.

Wie oft sollten wir unseren SAP-Notfallplan testen? 

Sie sollten mindestens einmal jährlich eine speziell auf SAP ausgerichtete Tabletop-Übung durchführen. Darüber hinaus sollten Sie Ihre „Break-Glass“-Verfahren sowie die Protokollierung der Sichtbarkeit bei jeder größeren Infrastrukturänderung – wie beispielsweise der Migration auf SAP S/4HANA oder dem Umstieg auf die cloud RISE with SAP) – erneut überprüfen.