NIS2 und SAP: Welche Sicherheitsmaßnahmen müssen Unternehmen umsetzen?

Der aktualisierte Rahmen der Europäischen Union für die Cybersicherheit kritischer Infrastrukturen NIS2 verpflichtet Unternehmen zu deutlich höheren IT-Sicherheitsstandards. Er betrifft öffentliche wie private Einrichtungen in kritischen Sektoren und damit naturgemäß viele SAP-Kunden.

Abhängig von Größe, Branche und bestehendem Sicherheitsniveau müssen die Unternehmen unterschiedliche NIS2-Anforderungen erfüllen, will heißen: ein definiertes Bündel von Risikomanagementmaßnahmen umsetzen und diese den Aufsichtsbehörden auf Verlangen nachweisen.

Artikel 21 von NIS2 legt zehn Kategorien von Maßnahmen fest, Artikel 20 überträgt der Geschäftsleitung die persönliche Verantwortung für deren Überwachung, Artikel 23 verpflichtet Organisationen, schwerwiegende Vorfälle innerhalb von 24 Stunden zu melden. Die Strafen bei Nichteinhaltung sind erheblich, und die zuständigen Behörden in den EU-Mitgliedstaaten gehen zunehmend von der Sensibilisierung zur aktiven Durchsetzung über. Das Thema dürfen und sollten SAP-Anwenderunternehmen also nicht auf die leichte Schulter nehmen. Leichter gesagt als getan, denn NIS2 erwähnt SAP nicht mit einer Silbe.

Dieser Umstand hat, so die Beobachtung von SecurityBridge, schon das eine oder andere Sicherheitsteam dazu verleitet, das ERP-System in Sachen NIS quasi als Nebensache zu behandeln. Ein Trugschluss, der von Prüfern zunehmend korrigiert wird. Schließlich steuern SAP-Systeme Finanztransaktionen, Personalakten, Lieferkettenprozesse, Fertigungsabläufe und damit sämtlichst Vorgänge, die das eigentliche Kerngeschäft eines Unternehmens ausmachen. Jede Verpflichtung gemäß Artikel 21 gilt demnach auch für sie.

SAP agiert auf einer anderen Ebene

Die meisten Cybersicherheitsprogramme wurden rund um das Netzwerk und die Endgeräte entwickelt. SAP arbeitet auf einer anderen Ebene, nutzt andere Protokolle und generiert Ereignisdaten in Formaten, die von Standard-Sicherheitstools nicht nativ ausgewertet werden können. Es wird in der Regel von einem Basis-Team verwaltet, von SAPs GRC-Modul geprüft und selten vom SOC abgedeckt. Genau diese Lücke deckt NIS2 auf. Unternehmen, die SAP auf „RISE with SAP“ betreiben, unterliegen denselben Verpflichtungen wie On-Premises-Anwender. „RISE with SAP“ ändert lediglich, wer die Infrastruktur verwaltet, nicht jedoch, wer für die Compliance verantwortlich ist. . Die Tatsache, dass SAP die zugrunde liegende Umgebung verwaltet, überträgt die Verantwortung gemäß Artikel 21 nicht auf SAP.

Was Artikel 21 auf SAP bezogen vorschreibt

Die zehn Risikomanagementmaßnahmen sind auf dem Papier technologieneutral. In der Praxis lässt sich jede einzelne auf spezifische SAP-Funktionen beziehen. Wichtig: NIS2 akzeptiert keine punktuellen Bewertungen, sondern verlangt nach kontinuierlichen, nachweisbaren Kontrollen sowie Belegen über deren Umsetzung. Eine SAP-native Security-Plattform, die den gesamten Geltungsbereich von Artikel 21 abdeckt, ohne dass externe Infrastruktur oder SAP-Fachwissen seitens des Sicherheitsteams erforderlich ist, kann das leisten.

Incident-Handling, sichere Entwicklung

Standard-SIEM-Tools erfassen SAP-Sicherheitsprotokolle nicht nativ und den meisten SOC-Analysten fehlt das Fachwissen, um die erhaltenen Daten zu interpretieren. SAP-Securitylösungen mit integrierter Threat Detection bieten vorgefertigte Erkennungsszenarien für SAP-spezifische Angriffsmuster, RFC-Missbrauch, Privilegien-Eskalation, unbefugte Transportbereitstellung und verdächtige Batch-Job-Ausführung. Strukturierte Warnmeldungen leiten sie direkt an SIEM- und SOAR-Plattformen weiter.

Eine Code-Schwachstellenanalyse (CVA) überprüft benutzerdefinierten ABAP-Code auf SQL-Injection, fehlende Berechtigungsprüfungen und unsichere Funktionsmodulaufrufe. Sie ist in den Transportlebenszyklus integriert, sodass Schwachstellen erkannt werden, bevor sie in die Produktion gelangen.

Cyberhygiene, Patching, Zugriffskontrolle

Patch-Management automatisiert die Überprüfung der Anwendbarkeit von SAP-Sicherheitshinweisen in der gesamten Landschaft. Es stellt sicher, dass „HotNews“ und Hinweise mit hoher Priorität nachverfolgt sowie umgesetzt und nicht im vierteljährlichen Überprüfungszyklus übersehen werden.

Das Privileged Access Management betreibt eine kontinuierliche SoD-Regel-Engine mit Protokollen zu Verstößen, Zuordnung zu Verantwortlichen und Nachverfolgung von Abhilfemaßnahmen. Identity Protection kümmert sich um inaktive Konten, die Protokollierung von „Firefighter“-Sitzungen und die Überwachung des Zugriffslebenszyklus.

Multi-Faktor-Authentifizierung

Erforderlich ist ferner eine risikobasierte, gestaffelte Multifaktor-Authentifizierung (MFA) auf SAP-Transaktionsebene, die je nach Aktionstyp, Benutzer-Risikoprofil oder Zugriffszeitpunkt ausgelöst wird, ohne dass Änderungen an der zugrunde liegenden Authentifizierungsinfrastruktur erforderlich sind. Schließlich müssen auditfähige Nachweise für alle Kontrollen erstellt werden, die auf NIS2, ISO 27001, SOX und DSGVO abgestimmt sind. Stehen sie auf Abruf zur Verfügung, müssen sie nicht vor jedem Audit manuell zusammengestellt werden.

Die Nachweislücke betrifft fast alle

In den meisten großen Unternehmen liegt SAP außerhalb des SIEM, außerhalb des Schwachstellenmanagement-Programms und außerhalb jeglicher Echtzeit-Erkennungsfunktionen. Die Folge ist eine Nachweislücke, die bei NIS2-Audits aufgedeckt wird. Aus ihr resultiert ein ganzes Bündel an Problemen: Weil die Segregation-of-Duties (SoD) nicht kontinuierlich überwacht wird, häufen sich Verstöße zwischen den vierteljährlichen Überprüfungen. SAP-Sicherheitshinweise werden manuell oder gar nicht nachverfolgt, „Firefighter“-IDs in der Produktion ohne automatisierte Sitzungsaufzeichnung verwendet und benutzerdefinierter ABAP-Code wird ohne Sicherheitsscan in der Produktion bereitgestellt. Es gibt keine Echtzeit-Warnmeldungen zu Bedrohungsindikatoren auf SAP-Ebene und MFA wird nur am Netzwerkperimeter durchgesetzt, nicht aber innerhalb der SAP-Sitzung.

Welche Nachweise erwarten NIS2-Prüfstellen?

Verlangt wird eine lückenlose Betriebsdokumentation, Richtlinien oder Konfigurations-Screenshots genügen nicht. Das bedeutet: mit Zeitstempel versehene Protokolle über festgestellte und behobene SoD-Verstöße, markierte und bearbeitete inaktive Konten, überprüfte „Firefighter“-Sitzungen sowie protokollierte MFA-Anfragen. Die Nachweise müssen unabhängig vorliegen und auf Anfrage exportierbar sein – sie dürfen nicht erst in den Wochen vor einem Audit manuell zusammengestellt werden.

Fazit

SAP-Anwenderunternehmen dürfen NIS2 nicht auf die leichte Schulter nehmen, auch wenn  das Cybersicherheits-Rahmenwerk die ERP-Software nicht explizit erwähnt. Deshalb gilt Artikel 21 mit all seinen zehn Maßnahmen-Kategorien auch hier. Unternehmen sollten daher ein definiertes Bündel von Risikomanagementmaßnahmen umsetzen und diese zugleich jederzeit auditierbar machen.