Was ist SAP-Cybersicherheit? Es geht um mehr als nur Rollen und Berechtigungen

Ihr GRC-Dashboard zeigt grüne Werte an. Es liegen keine Verstöße gegen die Aufgabentrennung vor. Die Rollenzuweisungen entsprechen dem Prinzip der geringsten Berechtigungen. Ihre Prüfer haben im letzten Quartal ihre Zustimmung erteilt.

Dann verschlüsselt die Ransomware Ihre HANA-Datenbank.

Die Angreifer haben Ihre Autorisierungsebene nie berührt. Sie nutzten eine ungepatchte Kernel-Sicherheitslücke aus. Sie drangen über das Betriebssystem ein. Ihre sorgfältig ausgearbeitete Rollenmatrix spielte keine Rolle.

Das ist der Unterschied zwischen SAP-Sicherheit und SAP-Cybersicherheit. Die meisten Unternehmen verfügen über Ersteres. Nur wenige verfügen über Letzteres.

Der Unterschied: GRC vs. Cybersicherheit

Die Begriffe „SAP Security“ und „SAP Cyber Security“ klingen ähnlich. Sie gehen jedoch mit unterschiedlichen Ansätzen auf unterschiedliche Bedrohungen ein.

SAP-Sicherheit (Classic)

Bei der herkömmlichen SAP-Sicherheit steht im Mittelpunkt, wer innerhalb von SAP welche Aktionen ausführen darf:

• Rollen und Berechtigungen: Welche Benutzer greifen auf welche Transaktionen zu?
• Aufgabentrennung (SoD): Vermeidung schädlicher Zugriffskombinationen
• GRC (Governance, Risk, Compliance): Überwachung und Durchsetzung von Zugriffsrichtlinien
• Benutzerverwaltung: Bereitstellung, Entzug, Zugriffsprüfungen

Diese Ebene beantwortet eine Frage: „Darf dieser Benutzer diese Aktion ausführen?“

Der Fokus liegt auf internen Vorgängen. Das Bedrohungsmodell geht davon aus, dass authentifizierte Benutzer versuchen, unbefugte geschäftliche Aktivitäten durchzuführen. Ein Lagerist, der versucht, seine eigenen Bestellungen zu genehmigen. Ein Auftragnehmer, der auf Gehaltsdaten zugreift, die nicht in seinen Zuständigkeitsbereich fallen.

GRC-Tools eignen sich hervorragend zur Verhinderung von internem Betrug. Sie sind sozusagen der Ausweisleser am Eingang.

SAP-Cybersicherheit (Modern)

SAP-Cybersicherheit konzentriert sich auf externe Bedrohungen, die darauf abzielen, SAP zu kompromittieren:

• Schwachstellenmanagement: Sicherheitslücken identifizieren und beheben
• Erkennung von Bedrohungen: Überwachung auf Angriffssignaturen und Anomalien
• Absicherung: Konfiguration von Systemen zur Minimierung der Angriffsfläche
• Reaktion auf Vorfälle: Erkennung und Eindämmung aktiver Angriffe

Diese Ebene beantwortet verschiedene Fragen: „Versucht jemand, einzudringen? Ist etwas kompromittiert worden? Sind unsere Systeme sicher konfiguriert?“

Der Fokus liegt auf externen Bedrohungen. Das Bedrohungsmodell geht von raffinierten Angreifern aus, die von außen auf Ihre Systeme abzielen. Ransomware-Betreiber suchen nach anfällige SAP-Systeme. Akteure aus dem Umfeld von Nationalstaaten, die Zero-Day-Schwachstellen ausnutzen. Automatisierte Botnets, die nach ungepatchten Kerneln suchen.

Cybersicherheits-Tools sind wie bewaffnete Wachleute und Videoüberwachung. Sie erkennen Bedrohungen, die Ausweise nicht abwehren können.

Die Definitionslücke

Unternehmen benötigen beide Komponenten. GRC ohne Cybersicherheit ist so, als würde man die Haustür abschließen, während das Hinterfenster offen bleibt. Cybersicherheit ohne GRC schützt zwar vor Hackern, aber nicht vor Bedrohungen durch Insider.

Die neue Bedrohungslage für SAP

SAP-Systeme enthalten genau die Daten, auf die es Angreifern ankommt: Finanzdaten, Kundeninformationen, geistiges Eigentum und Daten zur Lieferkette. Die Bedrohungslage hat sich mittlerweile über den internen Missbrauch hinaus weiterentwickelt.

Ransomware nimmt SAP direkt ins Visier

Moderne Ransomware-Kampagnen zielen gezielt auf SAP-Datenbanken ab. Den Angreifern ist bewusst, dass die Verschlüsselung Ihrer HANA-Datenbank Ihren Geschäftsbetrieb lahmlegt. Sie wissen, dass Unternehmen zahlen werden, um ihre Daten wiederherzustellen.

Ransomware dringt über verschiedene Wege ein:

• Nicht gepatchte Betriebssysteme: Sicherheitslücken in Windows Server oder Linux
• Öffentlich zugängliche SAP-Dienste: RFC-, HTTP- oder Datenbankports, die über das Internet zugänglich sind
• Gekompromittierte Anmeldedaten: Gestohlene Passwörter, die zur Authentifizierung verwendet werden
• Angriffe auf die Lieferkette: Kompromittierte Software von Drittanbietern mit SAP-Zugriff

Die Ransomware wird auf Betriebssystemebene ausgeführt. Sie verschlüsselt Dateien auf der Festplatte. Ihre Rollenmatrix kann die Dateiverschlüsselung nicht verhindern. Ihre Berechtigungsprüfungen werden nie ausgelöst, da der Angriff die Anwendungsebene vollständig umgeht.

Die Log4j-Warnung

Die Log4j-Sicherheitslücke hat gezeigt, wie schnell SAP-Umgebungen zur Zielscheibe werden. Eine kritische Sicherheitslücke in einer gängigen Java-Bibliothek betraf SAP-Systeme weltweit. Innerhalb weniger Stunden nach der Veröffentlichung suchten Angreifer im Internet nach anfälligen Instanzen.

Unternehmen mit einem ausgereiften Schwachstellenmanagement konnten betroffene Systeme schnell identifizieren. Sie installierten Patches oder setzten Workarounds ein, bevor die Schwachstellen ausgenutzt werden konnten. Unternehmen ohne diese Fähigkeit hatten Mühe, ihre Sicherheitslücken zu erfassen.

Log4j war eine Sicherheitslücke. SAP veröffentlicht monatlich Sicherheitshinweise. SAP HotNews beheben kritische Sicherheitslücken, die von Angreifern aktiv ausgenutzt werden. Ohne ein systematisches Schwachstellenmanagement vergrößert sich Ihre Angriffsfläche jeden Monat.

Warum Hacker es auf SAP abgesehen haben

SAP-Systeme sind aus mehreren Gründen attraktive Ziele:

1. Wertvolle Daten: Finanztransaktionen, Preisgestaltung, Kundendaten
2. Geschäftskritikalität: Ausfallzeiten kosten Millionen pro Stunde
3. Komplexe Patch-Installation: Viele Unternehmen verschieben Patches aufgrund von Testanforderungen
4. Eingeschränkte Überwachung: SOC-Teams fehlt es oft an Transparenz in Bezug auf SAP
5. Stabile Angriffsfläche: SAP-Versionen bleiben über Jahre hinweg im Einsatz

Angreifer untersuchen SAP-Sicherheitslücken eingehend. Sie wissen, welche Kernel-Versionen welche Fehler enthalten. Sie wissen, welche Profilparameter Sicherheitslücken verursachen. Sie entwickeln automatisierte Tools, die in großem Umfang nach diesen Schwachstellen suchen.

Wesentliche Bestandteile einer SAP-Cyberabwehrstrategie

Eine wirksame SAP-Cybersicherheit erfordert drei miteinander verknüpfte Komponenten. Jede davon befasst sich mit einer anderen Phase des Angriffszyklus.

Komponente 1: Schwachstellenmanagement

Schwachstellenmanagement bedeutet, Patches zu installieren, bevor die Schwachstelle ausgenutzt wird. Man kann sich nicht gegen Angriffe verteidigen, die auf Schwachstellen abzielen, die man noch nicht behoben hat.

SAP-Kernel-Patching

Der SAP-Kernel enthält kritische Sicherheitslücken, die SAP regelmäßig behebt. Kernel-Upgrades sollten in einem vorhersehbaren Rhythmus erfolgen. Die automatisierte Analyse von SAP HotNews hilft dabei, zu priorisieren, welche Patches sofortige Aufmerksamkeit erfordern.

Patches für das Betriebssystem

SAP läuft auf Betriebssystemen, die eigene Patches erfordern. Eine vollständig gepatchte SAP-Anwendung auf einem ungepatchten Windows-Server bleibt weiterhin anfällig. Das Schwachstellenmanagement muss beide Ebenen umfassen.

Sichtbarkeit des Patch-Status

Was man nicht sieht, kann man auch nicht beheben. Für das Schwachstellenmanagement ist ein kontinuierlicher Überblick über folgende Bereiche erforderlich:

• Aktuelle Versionen des Kernels und der Support-Pakete
• Fehlende SAP-Sicherheitshinweise
• Stand der Betriebssystem-Patches auf allen SAP-Servern
• Versionen von Komponenten von Drittanbietern (Java, Browser-Plugins usw.)

Komponente 2: Erkennung von Bedrohungen

Das Schwachstellenmanagement beugt bekannten Angriffen vor. Die Bedrohungserkennung deckt laufende Angriffe auf, einschließlich solcher, die unbekannte Schwachstellen ausnutzen.

Überwachung von Konfigurationsänderungen

Angreifer ändern Systemkonfigurationen, um eine dauerhafte Präsenz zu etablieren oder ihre Berechtigungen zu erweitern. Die Überwachung von Sicherheitsparametern erkennt unbefugte Änderungen an:

• Profilparameter, die sich auf die Sicherheit auswirken
• ICM-Konfiguration (Web-Präsenz)
• RFC-Zielkonfiguration
• Benutzerstammsätze (insbesondere SAP* und DDIC)

Anomalieerkennung

Manche Angriffe lösen keine bestimmten Signaturen aus. Die Anomalieerkennung identifiziert ungewöhnliche Muster:

• Fehlgeschlagene Anmeldeversuche auf mehreren Systemen
• Ungewöhnliche RFC-Aufrufmuster
• Massen-Datenexporte
• Verwaltungsaufgaben außerhalb der Geschäftszeiten

Protokollanalyse

SAP erstellt detaillierte Protokolle, die Hinweise auf Angriffe enthalten. SM21-Systemprotokolle, Sicherheitsüberwachungsprotokolle und Gateway-Protokolle zeichnen Ereignisse auf, die auf eine Kompromittierung hindeuten. Die meisten Unternehmen werten diese Protokolle nicht systematisch aus.

Komponente 3: Härten

Durch Hardening wird die Angriffsfläche verringert, indem Systeme so konfiguriert werden, dass sie möglichst wenig angreifbar sind.

Profilparameter-Härtung

SAP-Systeme werden mit Standardkonfigurationen ausgeliefert, bei denen Kompatibilität Vorrang vor Sicherheit hat. Sicherheitsoptimierung passt die Profilparameter an, um:

• Deaktivieren Sie nicht benötigte Dienste
• Passwortkomplexität erzwingen
• Zugriffsmethoden für den Fernzugriff einschränken
• Sicherheitsprotokollierung aktivieren

Netzwerksegmentierung

Auf SAP-Systeme sollte kein direkter Zugriff über das Internet möglich sein. Eine geeignete Netzwerkarchitektur begrenzt das Risiko:

• RFC nur aus vertrauenswürdigen Quellen
• HTTP/HTTPS über Reverse-Proxys
• Datenbank-Ports sind von außen niemals zugänglich
• Jump-Hosts für den administrativen Zugriff

Sichere Standardeinstellungen

Zur Absicherung gehört das Entfernen oder Sichern von Standardkonten (SAP*, DDIC, SAPCPIC), das Deaktivieren von Beispielanwendungen sowie das Entfernen nicht benötigter ICF-Dienste. Jeder aktivierte Dienst stellt eine potenzielle Angriffsfläche dar.

Die Lücke schließen: Wie Basis und InfoSec zusammenarbeiten müssen

Die SAP-Cybersicherheit fällt in eine organisatorische Lücke. Das SOC kümmert sich um die Unternehmenssicherheit, verfügt jedoch nicht über SAP-Fachwissen. Das Basis-Team kümmert sich um SAP, verfügt jedoch nicht über die erforderliche Integration in die Sicherheitsabläufe.

Das Silo-Problem

In den meisten Organisationen:

• Basis-Team: Verwaltet die technische Konfiguration von SAP. Verfügt über Kenntnisse zu Profilparametern, Kernel-Versionen und SAP-spezifischen Sicherheitsrisiken. Es fehlt die Integration in unternehmensweite SIEM- und Incident-Response-Prozesse.

• SOC (Security Operations Center): Überwacht Unternehmensbedrohungen. Nutzt Splunk, Sentinel oder andere SIEM-Plattformen. Untersucht Warnmeldungen und koordiniert die Reaktion auf Vorfälle. Ist gegenüber SAP-spezifischen Bedrohungen blind, da SAP keine Daten an diese Tools übermittelt.

Das Ergebnis: SAP-Bedrohungen bleiben unentdeckt. Denjenigen, die sie erkennen könnten, fehlt das SAP-Wissen. Denjenigen mit SAP-Wissen fehlen die entsprechenden Erkennungswerkzeuge.

SAP in SOC übersetzen

Um diese Lücke zu schließen, ist eine Übersetzung erforderlich. SAP generiert sicherheitsrelevante Ereignisse in SAP-spezifischen Formaten. Das SOC benötigt diese Ereignisse in seiner Sprache und für seine Tools.

Zu einer erfolgreichen Integration gehören:

SIEM-Integration

SAP-Sicherheitsereignisse sollten an Ihr Unternehmens-SIEM weitergeleitet werden (ServiceNow, Splunk, Microsoft Sentinel usw.). Dadurch werden SAP-Warnmeldungen zusammen mit Netzwerk-, Endpunkt- und Cloud-Warnmeldungen angezeigt. Das SOC erhält so einen vollständigen Überblick.

Übersetzung der Meldung

Rohe SAP-Ereignisse benötigen einen Kontext. „Der Profilparameter login/fails_to_user_lock wurde von 5 auf 99 geändert“ sagt einem SOC-Analysten nichts. „Brute-Force-Schutz für Passwörter auf dem SAP-Produktionssystem deaktiviert“ löst die entsprechende Dringlichkeit aus.

Avantra wandelt technische SAP-Ereignisse in sicherheitsrelevante Warnmeldungen um, die für SOC-Teams verständlich sind. Die Ausgabe erfolgt in der Sprache des SOC, nicht in der Sprache von SAP.

Zentrale Dashboards

Der Sicherheitsstatus sollte an einem zentralen Ort einsehbar sein. Der Status der SAP-Sicherheitslücken, die Einhaltung von Hardening-Vorgaben und Warnmeldungen zu Bedrohungen sollten neben anderen Sicherheitskennzahlen des Unternehmens angezeigt werden.

Modell des gemeinsamen Eigentums

Eine wirksame Cybersicherheit bei SAP erfordert Zusammenarbeit:

Keine der beiden Teams ist allein für die SAP-Cybersicherheit zuständig. Das Basis-Team bringt SAP-Fachwissen ein. InfoSec steuert die Sicherheitsmethodik bei. Gemeinsam schließen sie die Lücke.

Die Rolle von Avantra: Die Cybersicherheitsschicht im Rahmen von GRC

GRC-Plattformen verwalten die Berechtigungsebene. Sie beantworten die Frage „Wer darf was tun?“. Sie befassen sich nicht mit den Fragen „Sind wir anfällig?“ oder „Werden wir angegriffen?“.

Avantra stellt die Cybersicherheitsschicht bereit, die GRC zugrunde liegt:

Sicherheitslücken-Transparenz

Kontinuierliche Überwachung von Kernel-Versionen, Patch-Ständen und der Anwendbarkeit von Sicherheitshinweisen. Sie sehen auf einen Blick, wo in Ihrer gesamten Infrastruktur Patches erforderlich sind.

Verschärfung der Compliance-Anforderungen

Automatisierte Überprüfungen anhand von Sicherheitsrichtlinien. Abweichungen lösen Warnmeldungen aus. Konfigurationsabweichungen werden sichtbar, bevor sie ausgenutzt werden können.

Erkennung von Bedrohungen

Echtzeitüberwachung sicherheitsrelevanter Änderungen und Anomalien. Verdächtige Aktivitäten werden sofort erkannt, nicht erst beim nächsten Audit.

SOC-Integration

SAP-Sicherheitsereignisse werden in SOC-fähige Warnmeldungen umgewandelt. Durch die Integration mit SIEM-Plattformen stehen Ihrem Sicherheitsteam die SAP-Daten direkt dort zur Verfügung, wo es arbeitet.

Die Kombination aus GRC (Berechtigungen) und Avantra (Abwehr) sorgt für umfassende Sicherheit. Fehlt eines von beiden, entstehen Lücken, die Angreifer ausnutzen werden.

Fazit: Sicherheit ist Teamarbeit

SAP-Cybersicherheit ist keine Erweiterung Ihres GRC-Programms. Es handelt sich um einen eigenständigen Bereich, der sich mit spezifischen Bedrohungen befasst.

GRC beugt internem Betrug vor. Cybersicherheit schützt vor Angriffen von außen. Beides ist notwendig. Keines von beiden reicht allein aus.

Organisationen, die ihre SAP-Systeme wirksam schützen, weisen gemeinsame Merkmale auf:

1. Sie unterscheiden GRC von Cybersicherheit. Unterschiedliche Teams, unterschiedliche Tools, unterschiedliche Kennzahlen.

2. Sie führen systematisch Reparaturen durch. Kernel-Updates, Sicherheitshinweise und Betriebssystem-Patches erfolgen nach einem vorhersehbaren Zeitplan.

3. Sie härten proaktiv aus. Es gibt Konfigurations-Baselines. Abweichungen lösen Warnmeldungen aus.

4. Sie erkennen Bedrohungen. Die Überwachung umfasst nicht nur die Verfügbarkeit der Anwendungen, sondern auch Sicherheitsereignisse.

5. Sie integrieren SAP in die Unternehmenssicherheit. Das SOC überwacht SAP. Die Reaktion auf Vorfälle umfasst SAP.

Ihr GRC-Dashboard kann grün leuchten, während sich Angreifer in Ihren Systemen bewegen. Lassen Sie sich von den grünen Lichtern nicht in falscher Sicherheit wiegen.

Richten Sie beide Ebenen ein. Stellen Sie die Berechtigungen mit GRC sicher. Sichern Sie die Systeme durch Cyberabwehr. Schützen Sie Ihre SAP-Landschaft vor Bedrohungen, die Ihre Rollenmatrix nicht berühren.

4. Häufig gestellte Fragen

F: Was ist der Unterschied zwischen SAP-Sicherheit und SAP-Cybersicherheit?

A: SAP Security (Classic) konzentriert sich auf Rollen, Berechtigungen, GRC und die Aufgabentrennung. Es beugt internem Betrug vor, indem es regelt, wer welche Aufgaben ausführen darf. SAP Cyber Security konzentriert sich auf Schwachstellenmanagement, Bedrohungserkennung und Systemhärtung. Es beugt externen Angriffen wie Ransomware vor, indem es das System vor Ausnutzung schützt.

F: Kann Ransomware die SAP-Autorisierungsprüfungen umgehen?

A: Ja. Moderne Ransomware greift direkt auf das Betriebssystem und die Datenbank ab. Sie verschlüsselt Dateien auf Betriebssystemebene, ohne sich bei der SAP-Anwendung zu authentifizieren. Ihre Rollenmatrix spielt keine Rolle, wenn der Angriff die Autorisierungsebene gar nicht erst erreicht.

F: Warum übersehen SOC-Teams häufig SAP-Bedrohungen?

A: SOC-Teams verfügen in der Regel nicht über SAP-Fachwissen, und ihre Überwachungstools (SIEM) erhalten nur begrenzte SAP-Daten. Basis-Teams kennen sich zwar mit SAP aus, arbeiten jedoch nicht eng genug mit dem Sicherheitsbetrieb zusammen. Dadurch entsteht eine Lücke, in der SAP-spezifische Bedrohungen unentdeckt bleiben.

F: Was ist SAP HotNews und warum ist es für die Cybersicherheit von Bedeutung?

A: SAP HotNews sind kritische Sicherheitshinweise, die sich auf aktiv ausgenutzte Sicherheitslücken beziehen. Sie erfordern sofortige Maßnahmen. Die automatisierte Analyse von HotNews-Patches hilft Unternehmen dabei, kritische Sicherheitslücken zu erkennen und zu beheben, bevor Angreifer sie ausnutzen können.

F: Inwiefern ergänzt Avantra GRC-Plattformen?

A: GRC-Plattformen verwalten die Autorisierungsebene (wer darf was tun). Avantra stellt die darunterliegende Cybersicherheitsschicht bereit: Transparenz bei Schwachstellen, Einhaltung von Sicherheitsstandards, Erkennung von Bedrohungen und SOC-Integration. Zusammen decken sie sowohl die interne Betrugsbekämpfung als auch die Abwehr externer Angriffe ab.

F: Sollten die Basis-Teams oder die InfoSec-Abteilung für die Cybersicherheit bei SAP zuständig sein?

A: Keines der beiden Teams allein. Cybersicherheit bei SAP erfordert Zusammenarbeit. Die Basis-Teams bringen das technische SAP-Fachwissen für die Implementierung von Patches und Sicherheitsmaßnahmen ein. InfoSec steuert die Sicherheitsmethodik für Erkennungsregeln, die Reaktion auf Vorfälle und die SIEM-Integration bei. Eine gemeinsame Verantwortung schließt die Lücke zwischen den Disziplinen.