Der Leitfaden für Versorgungsunternehmen zu SAP RISE: Umgang mit geteilter Verantwortung und Sicherheit
Energieversorger sind in einem stark regulierten Umfeld tätig. Während Unternehmen wie Oklahoma Gas and Electric (OG&E) ihre ERP-Systeme modernisieren, erfordert die Umsetzung einer sicheren Geschäftstransformation im Rahmen von „RISE with SAP“ einen grundlegenden Wandel in der Sicherheitsstrategie.
Um den Kern des Unternehmens zu schützen, müssen Sicherheitsverantwortliche verstehen, dass die Migration zu einem Hyperscaler die Risiken für das Unternehmen nicht beseitigt. Sie verlagert lediglich den Schauplatz. Eine ausführlichere technische Analyse finden Sie im vollständigen Webinar zu Sicherheit und Compliance im Shared-Responsibility-Modell mit OG&E und Onapsis.
Was ist das Shared-Responsibility-Modell in SAP RISE?
Das SAP RISE-Modell der geteilten Verantwortung sieht vor, dass SAP die zugrunde liegende cloud verwaltet, der Kunde jedoch die volle Verantwortung für die Anwendungssicherheit, den Datenschutz und die Einhaltung gesetzlicher Vorschriften trägt.
Auch wenn der Begriff eine Partnerschaft impliziert, bedeutet dies nicht, dass die Verantwortung geteilt wird. Sollte es bei einem Versorgungsunternehmen zu einer Sicherheitsverletzung in seiner SAP-Umgebung kommen, werden die Aufsichtsbehörden und Kunden das Versorgungsunternehmen uneingeschränkt zur Verantwortung ziehen, unabhängig davon, wie SAP seine Infrastruktur verwaltet.
Sicherheitsverantwortliche müssen sich bewusst sein, dass sie sich bei der Umsetzung des SAP-Modells der geteilten Verantwortung für cloud nicht mehr auf herkömmliche Kontrollen auf Netzwerkebene verlassen können. SAP schreibt vor, dass die Sicherheit aller Bereiche jenseits der Infrastrukturebene ausschließlich in der Verantwortung des Kunden liegt.
Warum behandeln Energieversorger SAP wie Betriebstechnik (OT)?
Versorgungsunternehmen behandeln SAP wie Betriebstechnologie, da in diesen Umgebungen eine extrem hohe Verfügbarkeit oberste Priorität hat, die Systeme nach den Lebenszyklen älterer Systeme betrieben werden und für deren Sicherung und Wartung hochspezialisierte Fachkräfte erforderlich sind.
Ähnlich wie physische Kraftwerke oder Übertragungsnetze unterliegen auch SAP-Umgebungen bestimmten Einschränkungen:
- Lebensdauer von mehreren Jahrzehnten: Die Systeme bleiben zehn bis zwanzig Jahre lang im Einsatz und sind äußerst widerstandsfähig gegenüber baulichen Veränderungen.
- Nischenkompetenz: Die Verwaltung dieser Umgebungen erfordert hochspezialisiertes Personal, das mit proprietären Protokollen vertraut ist, was die Einbindung externer Fachkräfte kostspielig und schwierig macht.
- Betriebliche Anfälligkeit: Das Installieren von Patches oder die Einführung neuer Sicherheitstools löst intern weitreichende Befürchtungen aus, dass dadurch der kritische Netzbetrieb, die Logistik der Lieferkette oder die Abrechnung der Stromkunden gestört werden könnten.
Indem sie das ERP-System als „OT des Unternehmens“ betrachten, können Sicherheitsteams von Versorgungsunternehmen erfolgreich passive und bewährte Tools einsetzen, deren Ausfall keine Auswirkungen auf die zentrale Produktionsumgebung hat.
Wie verändert SAP RISE die Transparenz in der Sicherheit?
Die Umstellung auf SAP RISE macht die herkömmliche Transparenz auf Netzwerkebene überflüssig und zwingt Sicherheitszentralen (SOC) dazu, anwendungsorientierte Funktionen zur Erkennung und Reaktion auf Bedrohungen einzuführen, um böswillige Aktivitäten zu erkennen.
In älteren lokalen Bereitstellungen konnten Sicherheitsteams den Datenverkehr auf Paketebene überprüfen und sich auf physische Firewalls im Rechenzentrum verlassen, die die Segmentierung des SCADA-Netzwerks widerspiegelten. SAP RISE kapselt die Umgebung und verhindert so den direkten Zugriff auf die Protokolle des zugrunde liegenden Hypervisors oder der Infrastruktur.
Darüber hinaus haben herkömmliche SOC-Teams in der Regel keinen Einblick in die proprietären Protokolle, Transaktionscodes und die Terminologie von SAP. Unternehmen müssen spezielle SAP-Software zur Erkennung von Bedrohungen einsetzen, die als Übersetzer fungiert und komplexe sowie anomale SAP-Ereignisse in verwertbare threat intelligence umwandelt, threat intelligence Standard-SOC-Analysten beim Schutz kritischer Infrastrukturen threat intelligence .
Warum ist sauberer Code wichtiger als ein sauberer Kern?
Sauberer Code ist wichtiger als ein sauberer Kern, denn die Verlagerung anfälliger kundenspezifischer Anwendungen auf SAP BTP verlagert das Risiko einer Ausnutzung SAP BTP , anstatt es zu beseitigen.
SAP setzt sich nachdrücklich für die „Clean Core“-Methodik ein und ermutigt Kunden, benutzerdefinierte Erweiterungen in die Business Technology Platform BTP) zu verlagern. Die Verlagerung von schlecht geschriebenem ABAP- oder Java-Code trägt jedoch nicht wirklich zur Sicherheit der Umgebung bei.
Angreifer, darunter auch Nationalstaaten, die es auf den Energiesektor abgesehen haben, agieren derzeit nach der Theorie der „Cyber Persistence“ – einem Umfeld ständiger Kontakt, in dem Angreifer massenhaft nach Fehlkonfigurationen suchen und innerhalb weniger Stunden funktionsfähige Exploits generieren. Um Angriffsmöglichkeiten zu beseitigen, ist ein ausgereiftes SAP-DevSecOps-Programm erforderlich, das sicherstellt, dass jede Zeile des benutzerdefinierten Codes frei von kritischen Schwachstellen ist, bevor sie bereitgestellt wird.
So gestalten Sie einen reibungslosen Übergang zu SAP RISE
Aufbau der Cyber-Resilienz für RISE with SAP erfordert die Implementierung strenger Code-Scans, einer kontinuierlichen Anwendungsüberwachung sowie einer umfassenden Sicherheitstransparenz vor Vertragsabschluss.
Versorgungsunternehmen müssen diese Umstellung als Gelegenheit nutzen, um veraltete Prozesse neu zu definieren, da sich eine cloud im Nachhinein nicht sicher nachrüsten lässt.
Voraussetzungen
- Einigkeit der Führungskräfte hinsichtlich der tatsächlichen cloud im Zusammenhang mit cloud für kritische Infrastrukturen.
- Ein anstehender oder laufender SAP-RISE-Migrationsvertrag.
- Einführung einer zentralen platform für das Schwachstellenmanagement, die speziell auf SAP- und Versorgungsunternehmen-Frameworks platform .
Schritt-für-Schritt-Anleitung
- Verhandeln Sie frühzeitig über Sicherheits-Add-ons: Verlangen Sie vor Unterzeichnung des RISE-Vertrags die Einbeziehung aller erforderlichen SAP-Sicherheits-Add-ons. Nach Vertragsabschluss schwindet die Verhandlungsmacht vollständig.
- Setzen Sie DevSecOps-Kontrollpunkte ein: Integrieren Sie automatisierte Software für SAP-Anwendungssicherheitstests direkt in die Entwicklungspipeline. Verhindern Sie, dass unsicherer Code in die Produktionsumgebung gelangt, um eine saubere baseline zu schaffen.
- Implementierung von Application Threat Hunting: Nutzen Sie fortschrittliche Ermittlungslösungen, um die Taktiken, Techniken und Vorgehensweisen (TTPs) von Angreifern nachzuahmen. Suchen Sie innerhalb der SAP-Anwendungsschicht nach Anzeichen für eine Kompromittierung und passen Sie die Sicherheitskontrollen auf der Grundlage aktueller threat intelligence den Energiesektor an.
- Compliance-Prüfungen automatisieren: Ordnen Sie automatisierte platform bestimmten SOX-, NERC-CIP- oder regionalen regulatorischen Kontrollen zu. Stellen Sie externen Prüfern mithilfe automatisierter SAP-Compliance-Software kontinuierliche Berichte zur Verfügung, um den strengen Prüfungszyklen ohne manuelle Datenextraktion gerecht zu werden.
Überprüfung
Führen Sie eine Angreifer-Emulationsübung in der RISE-Umgebung durch, wobei Sie auf reale threat intelligence zurückgreifen. Überprüfen Sie, ob die speziellen SAP-Sicherheitstools den Angriff auf Anwendungsebene erfolgreich erkennen, die Warnmeldung für das SOC korrekt übersetzen und die erforderlichen Daten zur Optimierung der Kontrollmaßnahmen bereitstellen, ohne den Kernbetrieb der Versorgungsunternehmen oder die Stromversorgung zu beeinträchtigen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen geteilter Verantwortung und geteilter Rechenschaftspflicht in SAP RISE?
Das Modell der geteilten Verantwortung bedeutet, dass SAP die cloud verwaltet, der Kunde jedoch die volle Verantwortung für die Anwendungssicherheit, den Datenschutz und die Einhaltung gesetzlicher Vorschriften trägt. Sollte ein Versorgungsunternehmen Opfer eines Cyberangriffs oder einer Datenpanne werden, werden Aufsichtsbehörden wie die NERC und die staatlichen Versorgungskommissionen das Unternehmen streng zur Verantwortung ziehen, unabhängig von der Rolle, die SAP bei der Verwaltung des Hypervisors oder der Server spielt.
Warum behandeln Energieversorger ihre SAP-Umgebungen wie Betriebstechnik (OT)?
Versorgungsunternehmen behandeln SAP wie Betriebstechnologie, da diese Systeme höchste Verfügbarkeit erfordern, eine Lebensdauer von mehreren Jahrzehnten haben und für ihre Wartung hochspezialisierte Fachkräfte benötigen. Ähnlich wie bei einem physischen Kraftwerk führt das schnelle Einspielen von Patches oder die Einführung ungeprüfter Sicherheitstools in das ERP-System (Enterprise Resource Planning) zu internen Befürchtungen, dass dadurch der kritische Netzbetrieb, die Lieferketten oder die Abrechnung gegenüber den Kunden gestört werden könnten.
Warum übersehen herkömmliche Security Operations Center (SOC) häufig Bedrohungen durch SAP RISE?
Herkömmliche SOC-Teams sind gegenüber Bedrohungen durch SAP RISE blind, da cloud die cloud die Transparenz auf Netzwerkebene verloren geht und die Analysten in der Regel die proprietären SAP-Transaktionscodes oder -Protokolle nicht verstehen. Versorgungsunternehmen müssen auf eine anwendungsorientierte Überwachung umstellen und spezialisierte Plattformen zur Erkennung von Bedrohungen einsetzen, um anomale SAP-Ereignisse in verwertbare Erkenntnisse für die regulären SOC-Analysten umzuwandeln, die das Stromnetz schützen.
Beseitigt die SAP-Clean-Core-Methodik Sicherheitslücken in benutzerdefiniertem Code?
Die SAP Clean Core-Methodik beseitigt Sicherheitslücken nicht; sie verlagert lediglich das Risiko einer Ausnutzung auf die SAP Business Technology Platform BTP). Um die Unternehmensumgebung wirklich zu sichern, müssen Versorgungsunternehmen den Fokus auf sauberen Code legen, indem sie automatisierte Tests zur Anwendungssicherheit in die DevSecOps-Pipeline integrieren, um unsichere Programmiermuster zu erkennen, bevor sie in die Produktion gelangen.