Das IT Sicherheitsgesetz Version 2.0 verpflichtet in §8 Unternehmen und Behörden, die zu den kritischen Infrastrukturen zählen, ein Angriffserkennungsystem für alle IT-Systeme zu etablieren, die Geschäftsprozesse der eigenen kritischen Dienstleistungen verarbeiten.
Aus meiner Sicht (keine Rechtsberatung!) könnte §8 wie folgt interpretiert werden:
Muss Vorgaben
Ein System zur Angriffserkennung für (kritische) IT-Systeme.
Kontinuierliche automatische Erfassung und Auswertung geeignerter Parameter und Merkmale (Logs, Konfigurationsparameter,..)
Sollte Umgesetzt werden
Fortwährende Identifizierung von Bedrohungen
Ausführen und Anzeigen von Maßnahmen zur Vermeidung und Beseitigung für (eingetretene) Störungen
Was ist zu tun?
Laut Gesetz sind die Anforderungen zum 01.05.2023 zu erfüllen. Entsprechend sollten betroffene Unternehmen prüfen, welche Systeme gemäß IT-SiG 2.0 betroffen sind. Dies in einer für einen Auditor nachvollziehbaren Form.
Es folgt die GAP Analyse bei der Angriffserkennung. Sind diese Systeme mit einer wirksamen Lösung abgedeckt?
Falls nicht besteht Handlungsbedarf und der Support des Management ist einzuholen, um eine wirksame Lösung (beispielsweise den werthAUDITOR für SAP-Systeme) zu beschaffen und in Betrieb zu nehmen.
In diesem Beitrag stelle ich ausschließlich meine persönliche Meinung als Elternteil dar.
Elternfinanzierte 1:1-iPad- Ausstattungen an deutschen Schulen
Viele Schulen sind dabei den digitalen Unterricht voranzutreiben. Dazu setzen sie auf die privaten iPads der Schüler. Dies vornehmlich aus dem Grund, dass Schulen und Schulträger ganz überwiegend nicht über die erforderlichen Mittel verfügen, um die gesamte Schülerschaft, bzw. alle Klassen mehrerer Jahrgänge mit digitalen Endgeräten auszustatten.
Gemeinsam mit den Kollegen von Chaos macht Schule des CCC habe ich zu diesem Thema den ausführlichen Artikel „Bring your own devices an Schulen“ in der „datenschleuder Nr. 106“ veröffentlichen dürfen. Der kritische Blick auf die elternfinanzierten Geräte macht den Artikel zur Pflichtlektüre für Schulen, Schulträger, Eltern und Elternräte. In dem Artikel wird schonungslos angesprochen welche bürokratischen Hürden die Institutionen nehmen müssen und Eltern & Schüler erhalten einen ungeschönten Einblick worauf sie sich einlassen, wenn eine elternfinanzierte 1:1 iPad Ausstattung an ihrer Schule eingeführt wird.
Wie bewerten Landesdatenschutzbehörden den Einsatz von BYOD an Schulen?
Oftmals können die Schulen keine umfassende Aufklärung der Eltern leisten. Umso erfreulicher, dass sich die Landesdatenschutzbehörden bereits (eingeschränkt) zu dem Einsatz privater Geräte an Schulen geäußert haben.
Die LDI NRW hat mit Stellungnahme vom 31.10.2022 nur schulischen Geräten eine datenschutzkonforme Anwendung bescheinigt. Hingegen „sieht die LDI NRW den Einsatz privater Endgeräte nicht nur bei Lehrkräften, sondern auch bei Schülerinnen generell kritisch. … Daher kann der Einsatz privater Endgeräte – auch im Interesse der Schulen, die für die Wahrnehmung ihres Bildungsauftrags auf digitale Lösungen setzen – nur übergangsweise in Betracht kommen. … Um die hiermit verbundenen rechtlichen Unsicherheiten zu vermeiden, empfehlen wir Ihnen, alle Schülerinnen möglichst kurzfristig mit schulischen Endgeräten auszustatten und damit die dauerhafte Gewährleistung von Datenschutz und –sicherheit zu ermöglichen.“
LDI Vorgaben für eine übergangsweise Nutzung von BYOD
Den Einsatz von elternfinanzierten iPads knüpft die LDI an einige Bedingungen:
Umsetzung von technischen und oragnisatorischen Maßnahmen zur Gewährleistung des Datenschutzes der Schüler. Hier ist ein umfassendes Paket zu implementieren, um das Missbrauchspotential der totalen Kontrolle über die private iPads abzumindern.
Echte freiwillige und nachteilsfreie Wahl, so dass eine Elternfinanzierung weder direkt noch indirekt zur Sicherung der Teilhabe an der digitalen Ausbildung ist. Somit muss die Schule jedem Schüler ein Leihgerät stellen, der nicht sein privates Gerät in das MDM einbinden lassen möchte.
Aufklärung und Information der Eltern über die Einbindung der BYOD Geräte in ein schulisches MDM inklusive supervised Mode.
Jederzeitiges Widerrufsrecht.
Durch die private Nutzung der durch die Schule voll kontrollierten, gesteuerten und überwachten BYOD Geräte ergeben sich weitere zu prüfende Aspekte.
Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO
Grundlegend muss jede Schule gewährleisten, dass die Anforderungen bezüglich Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO erfüllt werden. Aufgrund der unklaren Aussagen(AGBs, Handbuch) über die Erhebung und Nutzung der Daten (u.a. Telemetrie) der nutzenden Schüler*innen, erscheint es unmöglich für den Auftraggeber (Schule) hier eine den Anforderungen entsprechende Auskunft an die Nutzenden (Schüler*innen) geben zu können.
Teacher Tools und Teacher App
Ein wesentlicher Grund warum die Schulen sich für Apple und dem MDM entscheiden sind die Apple Teacher Tools in Kombination mit der MDM Teacher App.
Die Apple Classroom App aus den Teacher Tools erlaubt es einer Lehrkraft jederzeit auf den Bildschirm eines Schülers in seiner Klasse zuzugreifen.
Die Funktion „Klassenzusammenfassung“ liefert ein Aktivitäts- und Leistungsprotokoll über die Schüler in der Klasse.
Die Teacher App (https://relution.io/insights/relution-teacher) erlaubt es einer Lehrkraft Richtlinien (Ad-Hoc) für die Schüler Geräte festzulegen (https://www.youtube.com/watch?v=_r5Mxzfvy0s) . Damit kann eingeschränkt werden (optional) welche Apps, System Apps oder Webseiten zugelassen sind. Diese Profile lassen sich sogar mit der Option „Persönliches Unterrichtsprofil“ vor anderen Lehrkräften verbergen.
Apple Classroom
Die App Classroom erlaubt es einer Lehrkraft jederzeit auf den Bildschirm einer Schülerin oder eines Schülers in ihrer Klasse zuzugreifen. Dies ermöglicht eine umfangreiche und anlasslose Datenerhebung/ Überwachung der Schülerinnen und Schüler. Diese sehen nur anhand der Anzeige eines blauen Punktes am Bildschirmrand, ob die Lehrkraft gerade die Funktion „Screens der Schüler ansehen“ aktiviert hat oder nicht. Der Einzelne kann nicht erkennen, ob die Lehrkraft gerade auf seinen Bildschirm schaut oder nicht. Auch im Nachhinein werden die Schülerinnen und Schüler darüber nicht regelmäßig informiert. Diese Funktion / Vorgehensweise unterscheidet sich ganz erheblich vom analogen Unterricht, bei dem Schülerinnen und Schülern bekannt ist, wann jemand auf die eigenen Unterlagen schaut.
Dauerhafte und anlasslose Überwachungsmöglichkeit vs Art. 7 DSGVO, Erwägungsgrund 39
Es entsteht ein permanenter Überwachungsdruck und Mangel an Privatsphäre während der Bearbeitung (z.B. falls nicht abgabereife Notizen/Aufgaben der Schülerinnen und Schüler von der Lehrkraft angeschaut werden oder persönliche Daten geöffnet sind). Der bloße Verdacht, dass Schülerinnen und Schüler in der Schule digital Angelegenheiten erledigen, die als privat zu klassifizieren sind oder nicht angemessen, sollte nicht deren lückenlose Überwachung legitimieren. Die Durchführung einer dauerhaften und anlasslosen Überwachung -ohne dass es von den Schülerinnen und Schülern bemerkt wird- erscheint nicht legitim. Eine Beobachtung der Schülerleistungen per Videokamera im Klassenraum wäre ja auch nicht zulässig. Personenbezogene Daten sollten nur dann verarbeitet werden, wenn sich der Zweck (hier: sich einen Eindruck verschaffen und pädagogisch begleiten) der Verarbeitung nicht auf andere zumutbare Weise erreichen lässt (Art. 7 DSGVO, Erwägungsgrund 39).
Gefahr der Verhaltensänderung bei Schüler*innen
Die Tatsache, dass über den gesamten Schultag jederzeit unangekündigt der Bildschirm überwacht werden kann, könnte zu einem angepassten und veränderten Verhalten führen. Es besteht die Gefahr, dass die Entwicklung der Schüler nachhaltig durch die Angst vor Überwachung beeinträchtigt wird. „Die freie Selbstbestimmung bei der Entfaltung der Persönlichkeit werde gefährdet durch die Bedingungen der modernen Datenverarbeitung. Wer nicht wisse oder beeinflussen könne, welche Informationen bezüglich seines Verhaltens gespeichert und vorrätig gehalten werden, werde aus Vorsicht sein Verhalten anpassen (siehe auch Panoptismus). Dies beeinträchtige nicht nur die individuelle Handlungsfreiheit sondern auch das Gemeinwohl, da ein freiheitlich demokratisches Gemeinwesen der selbstbestimmten Mitwirkung seiner Bürger bedürfe.“ (Wikipedia). Es besteht durch die Schulpflicht für Schülerinnen und Schüler faktisch Zwang zur Nutzung von Tablets und Lernplattformen, sie müssen sich durch die Tabletnutzung der umfassenden Beobachtung ergeben und können sich ihr nicht entziehen. Das Sammeln von Daten über die Lernenden fügt negativ auswirkende Facetten hinzu. Die Lehrkräfte bekommen weitere Kontrollinstrumente an die Hand, mit denen sich umfassende Kontrolle manifestiert.
„Es muss sichergestellt sein, dass die Lehrkräfte nicht nachverfolgen können, wie lange die Schülerinnen und Schüler an den jeweiligen Dokumenten gearbeitet haben. Denn dies würde im Vergleich zum analogen Schulalltag, in dem solche Auswertungsmöglichkeiten nicht bestehen, einen unverhältnismäßigen Eingriff in das Recht auf informationelle Selbstbestimmung der Schülerinnen und Schüler darstellen.“
Eckpunkte für den datenschutzkonformen Einsatz von digitalen Lernplattformen in den niedersächsischen Schulen (Stand: Juni 2022)
Datenschutzfragen / DSGVO Art. 15
Wie können die Nutzer in Erfahrung bringen und nachvollziehen, welche Daten wann mit der „Klassenzusammenfassung“ oder der Bildschirmeinsicht über sie erhoben wurden? Wie kann das Recht auf Auskunft (z.B. wann eine Lehrkraft Bildschirmeinsicht genommen hat) umgesetzt werden? Welche Vorkehrungen sind hierfür für das Auskunftsrecht nach Art. 15 DSGVO getroffen?
Die Teacher App erlaubt es einem Einzelnen -ohne 4 Augen Prinzip oder technischen Einschränkungen- jederzeit Richtlinien für die Geräte “seiner” Klasse zu erzeugen und diese sogar vor anderen Lehrkräften zu verstecken. Zusätzlich kann über die App jederzeit ein Unterricht gestartet werden. Jemand könnte jederzeit auf diesem Weg eine Richtlinie (ohne Einschränkungen für die SuS Geräte, um „unbemerkt“ zu bleiben) erzeugen und vor anderen Lehrkräften verbergen. Dann könnte er damit zu einem beliebigen Zeitpunkt einen Unterricht für (gezielt ausgewählte) SuS starten und direkt im Anschluss mit Apple Classroom sich Zugriff auf dessen Bildschirm verschaffen. Ob Schüler und Schülerinnen (SuS) diesen Zugriff bemerken und “verstehen” bleibt fraglich, da auf dem IPAD der SuS kein Hinweis oder eine Informationsmeldung erscheint (https://youtu.be/ZG3mmnxUW-E?t=349) .
Fragenkatalog Datenschutz BYOD iPads an Schulen
Die hier ausgewählten Beispiele zeigen den weiteren Prüfbedarf auf. Mein Paper Digitaler Unterricht – Chaosfrei? – Eine technische Risikobetrachtung gewährt einen tieferen Einblick in die Welt des Datenschutzes und der Datensicherheit inklusive Betrachtung rechtlicher und organisatorischer Fragen. Aus diesem Paper stammt die folgende Auflistung der zu betrachtenden Aspekte bei dem Einsatz von elternfinanzierten iPads an Schulen.
Gewährleistung eines freiwilligen und nachteilsfreien Angebotes (z.B. Leihgeräte) inklusive Widerrufsrecht und Aufklärung bei BYOD Geräten. Festlegung eines angemessenen Zeitraumes für eine möglichst kurzfristige übergangsweise Nutzung privater IPADs. (Kapitel 10 Punkt Bewertung LDI NRW (Auskunftsverfahren, Teilaspekte)
Ist die Gewährleistung der Anforderungen bezüglich der Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO durch die Schule sichergestellt? ( Kapitel 10 Datenschutz Problematiken Punkt 1)
Es ist zu prüfen, ob die Funktionen der Apple Teacher Apps wie die Classroom Funktion „Viewing Students Device Screen“ datenschutzkonform auf privaten und Leihgeräten genutzt werden können. Insbesondere in Kombination mit den Möglichkeiten der Relution Teacher App ist der Datenschutz für SuS zu gewährleisten. Zudem ist zu prüfen, ob die Erhebung der Aktivitäts- und Leistungsdaten durch Apple Schoolwork/Classroom zulässig ist. (Kapitel 5 Apple Teaching Tools )
Existieren Regelungen und Dienstanweisungen wann und wie Lehrkräfte die Möglichkeiten der Tools nutzen dürfen/können? Beispielsweise: ● Darf eine Lehrkraft Screenshots von dem Bildschirm eines Schülers anfertigen? Falls ja, unter welchen Voraussetzungen? ● Wann darf eine Lehrkraft den Bildschirminhalt eines Schüler IPADs auf die Tafel / Bildschirm spiegeln? Muss/Kann der Schüler zuvor zustimmen? Welche Voraussetzungen sind zu erfüllen, damit keine Inhalte angezeigt werden, die der Schüler nicht teilen möchte? (Kapitel 5 Apple Teaching Tools )
Wie können die Nutzer in Erfahrung bringen und nachvollziehen, welche Daten wann mit der„Klassenzusammenfassung“ oder der Bildschirmeinsicht über sie erhoben wurden? Wie kann das Recht auf Auskunft (z.B. wann eine Lehrkraft Bildschirmeinsicht genommen hat) umgesetzt werden? Welche Vorkehrungen sind hierfür für das Auskunftsrecht nach Art. 15 DSGVO getroffen? (Kapitel 5 Apple Teaching Tools )
Gewährleistung, dass bei ein Auftragsverarbeiter einer öffentlichen Einrichtung (Schule) keinerlei persönlichen Daten der Nutzenden für eigene Zwecke verwendet wird – wie jedoch in den Apple AGBs angegeben. ( Kapitel 10 Datenschutz Problematiken Punkt 2)
Vor dem Hintergrund der Datenkommunikation mit Servern eines US-Herstellers ist der Schutz aller Daten der Kinder vor unberechtigtem Zugriff durch Dritte sicherzustellen. „Dabei ist der entscheidende Aspekt, ob die Schule als öffentliche Einrichtung personenbezogene Daten (von Kindern) in einer (europäischen) Cloud speichern kann, die z.B. einem möglichen Zugriff US-amerikanischer Behörden ausgesetzt ist. Öffentliche Einrichtungen in Deutschland haben eine besondere Verantwortung hinsichtlich der Zulässigkeit und Nachvollziehbarkeit der Verarbeitung personenbezogener Daten.“. (ITMediaLaw) ( Kapitel 10 Datenschutz Problematiken Punkt 2)
Existiert ein (unabhängiger) Nachweis, dass die notwendigen TOMs (Change Management vorhanden? ; Teacher App & Classroom Zugriff) wirkungsvoll für die tatsächliche Infrastruktur (shared Server?) implementiert sind? (Mehrere Kapitel verweisen auf notwendige TOMs)
Es ist zu prüfen, ob der Einsatz der Plattform Office 365 und deren Apps datenschutzkonform ist, da diese Plattform in der Schule verwendet wird und deren Apps automatisch durch die Schule aufgespielt werden. (Kapitel 9 Risiko von durch die Einrichtung installierten Apps )
Was kann man als Betroffene tun?
Oftmals ist die Aufklärung durch die Institution unzureichend und die Angst vor Nachteilen, wenn man nicht „mitzieht“, ist groß. Der Druck auf die Schüler ist ebenfalls nicht zu leugnen, da ja „alle“ mitmachen und weder Eltern noch Schüler verstehen was da genau auf einen zu kommt und welche Optionen einem eigentlich zustehen. Nicht immer ist die Kommunikation mit der Schule zu diesem Punkt einfach und man kann schnell eine gemeinsame Lösung finden.
Ob diese Art der Kommunikation strategisch ist, lässt sich nicht mit Sicherheit beantworten. Allerdings spricht die Empfehlung des Medienzentrums Cloppenburg für sich.
FAQ des Medienzentrums Cloppenburg wie Schulen Tablets einführen sollen
In solchen Fällen findet jeder Betroffene (Eltern oder Schüler) Hilfe bei seiner zuständigen LDI. Dort kann man mit eine formlosen E-Mail eine Anfrage/Beschwerde einreichen. Dies ist jederzeit möglich – sowohl VOR der Einführung als auch DANACH. Wie hier dargestellt existieren Auflagen für einen BYOD Einsatz und mehrere kritische Punkte sind zum jetzigen Zeitpunkt noch ungeklärt.
Eine Inspiration für eine solch formlose Anfrage stelle ich in meiner Vorlage bereit. Diese Vorlage stellt keine juristische Beratung oder Dienstleistung dar und ist meine rein private und subjektive Sicht der Dinge.
In der Vorlage ist der Kontakt zu der LDI NRW enthalten, andere LDI sind eigenständig im Internet zu suchen (postestelle@xyz ist ausreichend). Die Vorlage ist auf die persönliche Situation anzupassen und stellt nur eine Inspiration dar.
Das SAP-System in der Cloud zu betreiben etabliert sich vermehrt als valide Option für den SAP-Betrieb. Es klingt alles so schön einfach und sicher soll es ja auch sein. Kann man das Blind glauben? Was macht eigentlich Sicherheit in der Cloud aus? Reicht es aus, wenn das System selbst sicher ist?
Mir drängt sich da noch eine weitere Frage auf, um überhaupt etwas zur Sicherheit sagen zu können:
Wie funktioniert eigentlich Cloud?
DevOps und Cloud gehen für mich Hand in Hand. Ohne DevOps wäre der Betrieb einer Cloud gar nicht möglich. Stark vereinfacht ist DevOps die Transformation der Serverlandschaft in „Software“. Man beschreibt seine Dienste und Server in Konfigurationsdateien und die DevOps Werkzeuge „generieren“ dann die dort beschriebenen Systeme. Schrauben ziehen in einem Rack, Betriebssystem installieren, passende Pakete suchen – all das gehört seit DevOps zur die „alten Zeit“.
Auf dieser Basis ist es möglich in der Cloud hunderte oder sogar zigtausende Systeme zu orchestrieren.
Wie genau funktioniert das denn jetzt wieder?
Nähern wir uns dem Thema mal in einer Vereinfachung ohne zu tiefe Details. Docker hat einen enormen Siegeszug hinter sich. Das nicht ohne Grund. Ist man mit Docker doch in der Lage quasi einen Dienst zu isolieren. Man braucht einen Webserver? Kein Problem „Nimm einen Docker Container“. Egal ob nginx oder Apache es gibt vorgefertigte aktuelle Container. Doch auch selbst einen passenden Docker zu erstellen ist nicht viel mehr als eine Konfigurationsdatei zu schreiben. Hier wählt man ein Basis-Image. Gibt Anweisungen zur Erstellung der Web-Server Konfiguration und verweist auf ein Verzeichnis in dem die Webseiten liegen (idealerweise als mount außerhalb des Dockers). Abgerundet wird die Konfiguration durch ein Init-Skript, das über ENVIROMENT Variablen die individuelle Konfiguration setzt (wie den Domain-Namen).
Kurzum mit Docker sind Dienste nicht mehr fest im System verankert, sondern isolierte „Container“-Baukästen, die individuell nach Bedarf zusammengesetzt werden können. Die Kombination aus einem Webserver Container und einem Datenbank Container ersetzt das klassische System auf dem alles direkt installiert wurde.
Dies ist ein wesentlicher Kern der Idee von Infrastruktur als Code. Es ist von der Idee her so „einfach“: Eine Beschreibung der Komponenten und wann diese „laufen“ sollen sowie den Namen der Maschine und welche Pakete zu installieren sind – fertig. Den Rest erledigen die Werkzeuge und erschaffen die Infrastruktur. Auf Basis der Beschreibung werden die Systeme in der definierten Anzahl erschaffen. Abweichungen (Systemausfälle, Zusätzliche Systeme oder wenige aufgrund der aktuellen Last,…) werden automatisch korrigiert. Firewall-Konfigurationen, Änderungen an IP-Adressen, mehr Speicherplatz – alles auf Knopfdruck. Das ist DevOps, die Magie hinter der Cloud.
Werkzeuge
Terraform ist eines der bekanntesten Werkzeuge für diese Aufgabe und wird von vielen Cloud-Providern wie AWS unterstützt. Es wird eingesetzt um letztlich die „Server“ in der Cloud zu erstellen und zu steuern. Dazu zählen ssh-keys, Firewall-Regeln, „Hardware-Ausstattung“, Anzahl der Systeme und mehr. Es kann auch die Docker-Container auf den Servern installieren. Doch möchte man tausende solcher Container verwalten, ist dieser spezielle Punkt bei Kubernetes besser gelöst als „nur“ Terraform zu nutzen.
Kubernetes ist Spezialist für Docker-Container. Egal ob die laufenden Container durch eine neue Version ersetzt werden sollen oder ein Load-Balancer die Zugriffe verteilen soll oder die Anzahl aufgrund hoher Last verdoppelt werden soll. Das alles macht Kubernetes mit „links“. Um dies zu ermöglichen, bündelt Kubernetes „Server“ in Kubernetes Cluster. Mehrere Container werden für den gemeinsamen Nutzungszweck in „Pods“ als eine Einheit zusammengefasst. Diese Pods leben virtuell auf einem „Node“. Früher war dies das „Blech“ auf dem Server letztlich lief. Mit einem „Deployment“ wird dann beschrieben wie viele Pods wann und wo laufen sollen und wie die Replikationsstrategie aussehen soll. Bei den Deployments ist das „Update“ ein herausragendes Feature. Man kann live seine Systeme updaten und Kubernetes sorgt dafür, dass während des Updates keine Downtime entsteht und am Ende alle Pods auf der neuen Version sind. Für Load-Balancing lassen sich verschiedene Pods mit demselben Dienst zu „Services“ zusammenfassen. Bisher spielt die Musik aber nur „in“ dem jeweiligen Kubernetes Cluster, für Zugriff von außen muss noch ein „NodePort“ erstellt werden, damit wird der Dienst dann nach außen geöffnet. Soweit doch schon ein wenig Komplex, trotz unserer sehr hohen Flughöhe. Die Zugriffsberechtigungen der Systeme untereinander werden über Rollen und Policies definiert. Dies variiert je nach Cloud-Anbieter und kommt als weitere Komplexitätsschicht oben drauf.
Dies alles ist der Kern hinter der Mammut-Aufgabe eine Cloud zu betreiben.
„Bereits ohne SAP-Systeme ist ein Cloud Betrieb komplex. Die Konfiguration aller Komponenten ist letztlich eine zusätzliche Ebene für die Systemsicherheit. Kann ein Angreifer Schwachstellen in der Konfiguration ausnutzen und Zugriffsrechte auf die Cloud erhalten und ausweiten, dann geraten auch die Systeme dort in Reichweite für den Angreifer. “
Sehen wir uns mal an wie Amazon das SAP Hosting umgesetzt hat. In einem Blog-Eintrag wird das SAP-Hosting vorgestellt. Terraform ist dabei ein wesentliches Element zur Erzeugung der Infrastruktur und auch Dev-Ops ist gern gesehen. Es stehen verschiedene Instanzen („virtuelle Hardware“ mit Maßgabe von Speicher und CPU) als Grundgerüst für ein SAP-System zur Auswahl. Individuelle Installations-Dateien sind über S3 Buckets (Key/Value Ablagesystem) verfügbar. Berechtigungen lassen sich über IAM Rollen für Systeme und Administratoren steuern.
Zusätzliche Werkzeuge wie Cloudwatch (Monitoring) oder auch Backup-Tools sind optional.
Der DevOps Ansatz „Infrastruktur als Code“ wird über eine AWS API unterstützt und damit lässt sich die SAP Infrastruktur in der Cloud automatisiert vom Kunden steuern. Für Terraform stellt Amazon sogar eigene Module bereit, die für die Verwendung mit SAP-Systemen (HANA, Netweaver) ausgelegt sind. Diese Module sind sogar in die Terraform Registry integriert und stehen allen Nutzern zur Verfügung.
Grundlegend entspricht dies dem allgemeinen Cloud-Ansatz, nur wird hier komplett auf den Einsatz von Docker und damit auch Kubernetes für den SAP-Anwendungsfall verzichtet. Das ist auch Nachvollziehbar, da ein SAP-System nicht in einen Docker-Container passt. Ebenso sind die Vorteile von Kubernetes nicht voll und ganz ausspielbar. Wer hat schon tausende SAP-Systeme oder fährt mal eben ein paar zusätzliche Systeme hoch, weil „zu viele“ User damit arbeiten?
Was bietet SAP zusätzlich?
SAP selbst bietet auch Hosting in der Cloud an und greift dabei auf die etablierten Anbieter wie Amazon, Microsoft und Google zurück. Als Mehrwert bietet SAP nach eigener Darstellung verschiedene Sicherheitsmaßnahmen.
(Quelle SAP)
Zugriffsschutz ist auf verschiedenen Ebenen vorhanden. Dennoch sieht man an dem Schaubild, dass SAP Mitarbeiter als Cloud Administratoren auf jede private Cloud zugreifen können. Das muss natürlich auch sein, da SAP letztlich die Systeme betreibt. Nennen wir es mal Wertungsneutral den SAP Master Zugriff.
Zudem betont SAP seinen Zero Trust Ansatz, in dem die unterschiedlichen Schichten keine Vertrauensstellung besitzen.
(Quelle SAP)
Alles sicher?
Dies ist ein sehr lobenswerter Ansatz, da gerade Vertrauensstellungen gerne mal ausgenutzt werden. Man denke nur an Social Engineering oder die RFC-Trust Destinations der SAP-Systeme. Der Boden auf dem alles steht ist der externe Cloud Anbieter. Von Amazon haben wir erfahren, dass Terraform alles für ein SAP-System aus dem Hut zaubern kann. Sogar beliebige Installationsdateien über S3 Buckets und die individuellen Berechtigungen über die IAM Rollen. Was passiert wohl, wenn jemand sich hier Zugriff verschaffen kann und beliebig Berechtigungen vergeben kann oder Skripte editiert? Was wenn er die AWS Policies anpasst und somit faktisch die Firewallregeln neu schreibt? Wie hoch bleibt der Schutz durch den Zero-Trust für die restlichen Komponenten? Das sieht jedenfalls nach dem ersten Ansatzpunkt für einen Angreifer aus.
SAP hat auch Verwendung für Docker und Kubernetes.
(Quelle SAP)
Da sind sicher einige Funktionen, die auch aus Security Sicht nützlich sind. Doch Docker und Kubernetes als Security Feature darzustellen ist sportlich. Natürlich nutzt man nicht den Default Namespace und auch keine privilegierten Container. Ein solcher Container kann im Handumdrehen als Root auf das „hostende“ System zugreifen. Doch auch nicht privilegierte Container sind nicht automatisch hoch sicher. Wesentlich wichtiger ist jedoch der Schutz von Kubernetes. Wird Kubernetes zum Angriffsziel, kann das gesamte Königreich fallen – mit allen SAP-Systemen darin. Auch wenn diese gar nicht von Kubernetes verwaltet werden. Sicherheitsfeatures kannte Kubernetes beim Relese gar nicht, nicht einmal Authentifizierung. Das wurde erst 2 Jahre nach dem ersten Release nachgereicht. Das macht ja Hoffnung… Die Frage ist nur wem?
Was passiert bei einem Cyberangriff auf die Cloud?
Begeben wir uns mal gedanklich in die Welt eines Angreifers, der unser Unternehmen attackieren möchte. Unser Unternehmen nutzt die Cloud umfänglich. Web-Server, File-Server, SAP-Systeme, Datenaustausch – für alles hat die Cloud eine Anwendung und die wird auch benutzt. Ist ja einfach.
Step 1: Ziel virtualisieren
Zunächst müssen wir unser Ziel „virtualisieren“ – also Angriffsziele im Cyberraum finden. Für einen schnellen Start nehmen wir die Domain und suchen Subdomains. Hier gibt es verschiedene Hilfsmittel SubList3r, Spiderfoot oder Fernmelder. Schnell haben wir mit diesen eine Liste mit DNS Namen zur Hand. Wir suchen jetzt Systeme, die in der Cloud laufen. Dies lässt sich am einfachsten mit der Webseite DNSCharts bewerkstelligen. Hier laden wir unsere Liste mit DNS Adressen und sortieren die Ausgabe nach den „Services“.
(Auszug Ergebnisse dnscharts)
Wir kennen somit ein paar Systeme, die in der Cloud betrieben werden. Dort sitzen auch die SAP-Systeme und zu denen möchten wir gelangen. Wie kommen wir jetzt also weiter?
Step 2: Die MetaAPI
AWS bietet eine MetaAPI auf der IP Adresse http://169.254.169.254/ . Die API bietet verschiedene Informationen an sowie die Möglichkeit temporäre Credentials auszustellen. Jedoch ist die API nur innerhalb der Cloud ansprechbar. Ein Sicherheitsfeature? Damit die API nicht von außen verwendet werden kann? Wir benötigen also einen „Helfer“, um mit der API sprechen zu können. Die gute alte SSRF Schwachstelle kommt hier wie gerufen. Diese Schwachstelle erlaubt es einen Server als „Proxy“ zu missbrauchen, um Anfragen an einen dritten Server im geschützten Netzwerk (Cloud) zu stellen.
Wir suchen also einen Server der Verwundbar gegen diese Schwachstelle ist. Dieser Server muss in der Cloud stehen, damit er uns zur MetaAPI leiten kann. Der ZAP Proxy kann solche Schwachstellen erkennen. Für den nächsten Schritt prüfen wir also erneut unsere Liste der Domains und nehmen die ins Visier, die laut dnscharts bei AWS gehostet sind. Mit ZAP wird ein aktiver Scan gefahren und nach SSRF Schwachstellen gesucht.
Bingo! Wir sind fündig geworden. Dies ist übrigens oftmals bittere Realität, wie man am Beispiel des Capital One Hacks nachlesen kann. Im Folgenden wird die gefundene SSRF Schwachstelle ausgenutzt, um gezielt eine URL der API aufzurufen. Ich spare mir hier zur Übersicht den konkreten SSRF Angriff, zumal dieser je nach Webseite hoch individuell ausfällt. Stattdessen zeige ich nur die eigentliche „Ziel-Url“ und deren Auswirkung.
Step 4: Zugriff auf die API
Mit Zugriff auf die API lassen sich nun verschiedene Abfragen tätigen:
http://169.254.169.254/latest/meta-data/iam/security-credentials/full-role.ec2 : Liefert ein Json Objekt, das zu dem Profil „full-role.ec2“ temporäre Zugangsdaten erzeugt: AWS access key ID, secret access key, und session token.
Mit diesen beiden Aufrufen erhalten wir sofort Zugangsdaten zur „privaten“ AWS Cloud unseres Unternehmens. Nur Aufgrund der SSRF Schwachstelle in dem Web-Server.
Damit hat man direkt Zugang zu dem AWS-Konto, in dem die ganzen Systeme laufen.
Damit wir die Zugangsdaten bequem nutzen können installieren wir die AWS CLI Tools:
$ apt install awscli
Und nutzen gleich die erhaltenen Zugangsdaten
$ aws configure
[Zugangsdaten]
Wir können nun die AWS Cloud API verwenden. Dem eigentlichen Ziel, das SAP System zu erreichen bringt uns das nur indirekt näher. Es fehlt uns noch die Adresse des Systems und ein User für das Login.
Step 6: Lateral Movement
Gehen wir noch mal einen Schritt zurück. Der Webserver mit der SSRF Schwachstelle bietet diverse Tarif-Rechner und ähnliches an. Je nach Standort und Kundenkreis werden andere Ergebnisse erzielt. Die Daten zur Berechnung wird nicht der Webserver in einem Docker Container halten. Er muss die Daten von einem weiteren System abfragen. Es ist gar nicht unwahrscheinlich, dass er diese Abfragen direkt an das SAP System stellt. Dazu muss er aber die Adresse kennen und Zugangsdaten besitzen. Docker Container kommen aber genau genommen „von der Stange“, solche individuellen Informationen können erst beim Start übergeben werden. Meist als ENVIROMENT Variablen zur Verwendung in Skripten. Wie kommen wir jetzt an die ENVIROMENT Variablen? Oder das Init-Skript beim Start, welches die Variablen setzt?
Die SSRF Schwachstelle! Bei DevOPs (AWS, Terraform) werden die individuelle Settings in den User-Daten der Systembeschreibung hinterlegt. Die lassen sich auch über die MetaAPI Abfragen:
Als Ergebnis erhalten wir die gesuchten Zugangsdaten und die Public IP Adresse. Dies wird im Rahmen der Installation gesetzt, damit der Web-Server Anfragen an das SAP-System stellen kann.
Jetzt ist noch fraglich wer darf auf das System zugreifen?
Zugriffsrechte werden in AWS mit Policies deklariert. Mit unserem AWS Zugang können wir uns die Instanzen in der „private“ cloud auflisten lassen
$ aws ec2 describe-instances
In dieser Auflistung sind auch die Firewallregeln für den Zugriff enthalten. Wir suchen in der Liste das SAP-System und prüfen die Security Groups, welche die Zugriffsregeln enthalten:
…
„SecurityGroups“: [
{
„GroupName“: „SAPSecurityGroup“,
„GroupId“: „sg-0598c7d356eba48d7“
}
],
…
Sehen wir doch mal nach wer Zugriff auf die Systeme hat:
Man sieht hier, dass je eine Zweigstelle aus New York und Berlin Zugriff haben. Scheinbar ist jedoch auch eine Regel aus einem GO-Live Test noch aktiv: Die IPRange 0.0.0.0/0 ist für alle Zeiten meine Lieblingsrange, insbesondere in Firewall Allow Regeln. Damit darf jeder –wirklich JEDER- mit dem System auf Port 3302 kommunizieren. Vorausgesetzt natürlich man kennt seine Adresse (3.227.102.13) und hat valide Zugangsdaten (web_rfc). Beides kennen wir bereits.
Wir sind also jetzt in der Lage uns über RFC in das SAP-System von überall auf der Welt einzuloggen.
Als Proof of Concept soll uns das an dieser Stelle reichen.
Fazit
Die Cloud ist eine nicht zu unterschätzende neuer Sicherheitsebene für SAP-Systeme. Der Aufbau ist komplex und wurde hier nur angerissen. Die Anbieter bieten diverse Schutzmaßnahmen und Monitoring Instrumente, die gute Arbeit leisten. Der Lesbarkeit geschuldet, habe ich hier auf „Evasion“ Maßnahmen verzichtet, doch es gibt sie!
Diese neue Sicherheitsebene ermöglicht aber auch gänzlich neue Angriffswege, wie dieses Beispiel gezeigt hat. Von der Aufspürung der Systeme, über eine SSRF-Schwachstelle im Web-Server mit Zugriff auf die MetAPI haben wir Zugriff auf die AWS erhalten. Dort konnten wir die Zugriffskonfiguration zu dem SAP System einsehen und über die MetaAPI sogar Zugangsdaten finden. Damit war ein Zugriff auf das SAP-System möglich, was uns niemals ohne die „Cloud“ gelungen wäre. Dies bedeutet jetzt nicht, dass die Cloud unsicher ist. Es zeigt nur, wie ernst die neue Ebene zu nehmen ist. Denn es sind ganz neue Pfade zu den SAP-Systemen entstanden. Das Beispiel war bewusst einfach gewählt, doch auch die Ausweitung der Rechte in der Cloud, die Re-Konfiguration von Policies und Rollen ist ein gangbarer Weg, der „nur“ nicht in ein einfaches Bespiel passt. Letztlich haben wir gelernt, dass das „sicherste“ SAP-System dennoch angreifbar ist, wenn die Cloud-Umgebung nicht sicher ist.
Erinnern wir uns doch kurz was wir bisher bei der Mittelstand & Co GmbH erlebt haben. Da war der Sicherheitscheck mit brisanten Ergebnissen: SAP_ALL User gewürzt mit einer unbemerkten Backdoor im System. Zumindest haben die Ergebnisse des Sicherheitschecks dem Thema SAP-Sicherheit die Unterstützung des Managements verschafft. Das Budget für die in den Budgetverhandlungen vorgelegte Roadmap wurde nachträglich genehmigt. Aufgrund der Hintertür im System ist ein weiteres Thema in den Fokus gerückt: „SAP-Forensik“.
„Damit eine forensische Auswertung eines SAP-Systems erfolgen kann, muss der Analytiker zwingend wissen an welcher Stelle im System welche Sicherheitsrelevanten Ereignisse protokolliert werden. Ebenso muss er die Einschränkungen und Eigenschaften der jeweiligen Log-Daten kennen, um den Inhalt (oder eben den fehlenden Inhalt) korrekt in seine Untersuchung einfließen lassen zu können.
Weiterhin ist zu beachten, dass die meisten Logging-Mechanismen zunächst deaktiviert sind und erst noch zu aktiviveren sind. Es gilt also zu prüfen, welche Logs stehen überhaupt zur Verfügung und wo sind diese zu finden.“
Was sind die ersten Schritte, wenn man etwas Verdächtiges bemerkt? Halten wir uns einfach an die Polizei, die sammelt doch ständig Beweise. Bei der Incident Response ist daher auch einer der ersten Schritte „Beweise sichern“. Im Fall von SAP bedeutet dies relevante Logs zu sichern. Jedoch sind diese Logs teilweise im Standard deaktiviert. Sie helfen also nur, wenn man sie VOR einem Vorfall manuell aktiviert hat.
Erstreaktion: Übersicht der Logs
Welche Logs sind denn im Fall der Falle konkret zu sichern und wo „wohnen“ diese?
Da man in kritischen Situationen ruhig und strukturiert vorgehen soll, sind wir an dieser Stelle ganz ordentlich und bringen die Logs in eine Tabellenform. Diese enthält Stichpunkte zu dem Namen, dem Speicherort und welche zusätzlichen Konfigurationsoptionen im Rahmen einer Auswertung zu beachten sind oder den Dateinamen/Speicherort spezifizieren.
Parallel zu dem Sichern der Logs empfiehlt es sich externe Hilfe anzufordern. Dies ist eine Ausnahmesituation in der auf solche Fälle spezialisierte Personen übernehmen sollten. Also auf „sicheren“ Weg den Dienstleister zur Unterstützung kontaktieren und weitere Schritte (System-Isolation?) abstimmen. Sichere Kommunikation bedeutet hier nicht SSL, sondern einen Kommunikationsweg der sicher nicht von dem Cyber-Angriff betroffen ist. E-Mail ist hier nicht die erste Wahl.
„Ich brauche mehr Informationen!“
Die Checkliste für die Logs ist ideal um schnell die richtigen Logs zu finden und zu sichern. Doch was steht in diesen Logs? Was muss ich zusätzlich beachten? Lernen wir die wichtigsten Logs doch mal kennen.
SECURITY AUDIT LOG
Dieses Werkzeug zeichnet detailliert die Ereignisse im SAP-System auf. Die zu protokollierenden Ereignisse sind durch einen Admin zu konfigurieren. Die Ereignisse sind so zu wählen, dass folgende Daten aufgezeichnet werden:
Sicherheitsbezogene Änderungen an der SAP-Systemumgebung (z. B. Änderungen an Benutzerstammsätzen)
Informationen, die mehr Transparenz bieten (z. B. erfolgreiche und erfolglose Anmeldeversuche)
Informationen, die der Nachvollziehbarkeit einer Reihe von Ereignissen dienen (z. B. erfolgreiche oder erfolglose Transaktionsstarts)
ACHTUNG:
Das Security Audit Log ist im Standard nicht aktiv und ist manuell zu aktivieren! Die Größe der Logdatei kann über den Profilparameter rsau/max_diskspace/local definiert werden. Der Vorschlagswert ist 1MB. Wird dieses Limit erreicht stoppt das Logging und erst mit dem nächsten Tag und einer neuen Logdatei wird wieder protokolliert!
Der Inhalt des Logs kann über die SAP-Transaktion SM20 eingesehen werden.
Jede Logmeldung verfügt über folgende Informationen:
• Servername
• Instanzname
• Workprozess-Typ
• SAP-Benutzer
• Terminalname
• Workprozessnummer
• Transaktionscode
• Programmname
• Mandant
• Meldungstext
• Meldungsgruppe
• Untergeordneter Name (wird zur Bestimmung der Meldungsgruppe verwendet)
• Audit-Klasse
• Sicherheitsstufe
• Dateinummer
• Adresse in Datei
• Parameter, die für den Meldungstext verwendet werden
Damit lässt sich der genaue Zeitpunkt, der verursachende User und Quellcomputer sowie die protokollierte Aktion bestimmen.
SYSTEMLOG
Das Systemlog dient eigentlich der Fehlerkontrolle und ist automatisch aktiv. Die maximale Größe wird durch den Profilparameter rslg/max_diskspace/local bestimmt und liegt im Standard bei 1MB.
Ein Eintrag beinhaltet immer Daten zu dem User, Clienten sowie der Aufgerufen Transaktion oder dem Programm und Details zu dem Fehler.
Dieses Log überwacht die Aktivitäten des SAP-Gateways (Schnittstelle zu andern SAP-Systemen und Programmen).
Das SAP-Gateway-Logging ist per Default nicht aktiviert. Die maximale Größe richtet sich nach der Option MAXSIZEKB .
Sobald die maximale Dateigröße erreicht ist, wird eine neue Datei angelegt und das Logging läuft weiter. Es sei denn die Option FILEWRAP wird auf „on“ gesetzt, dann wird die vorhanden Logdatei einfach wieder geöffnet und überschrieben.
Der Zugriff auf die Loginhalte erfolgt im SAP-System über die Transaktion SMGW.
Das Gateway-Log liefert Informationen zu dem Datum und der Uhrzeit, dem Quellserver und der ausgeführten Aktion (Verbindung zu Server, Start Server, Register Server, usw.) .
Aus forensischer Sicht wird in den Log-Einträgen nach der Ausführung von Monitor-Befehlen, Änderungen in der Sicherheitskonfiguration sowie der Registrierung potentiell schädlicher RFC-Server oder dem Start kritischer RFC-Server gesucht.
Das Security Log ist nur bei dem ICM standardmäßig aktiviert und liegt in dem Pfad
/usr/sap/<SID>/<INSTANCE>/work/dev_icm_sec .
Wie sich das Log verhalten soll, wenn das Limit erreicht ist, spezifiziert der Parameter FILEWRAP. Wird dieser Parameter auf on gesetzt, wird bei Erreichen der Maximalen Größe die Logdatei zurückgesetzt und neu geschrieben. Alle Logeinträge gehen verloren!
Dieses Log kann genutzt werden, um fehlgeschlagene Loginversuche an der Web Administration zu erfassen. Sowie HTTP Fuzzing Versuche aufzudecken.
Das Log bietet dabei die Informationen über Datum und Uhrzeit, der IP des Angreifers und Inhalt der Anfrage in Abhängigkeit des eingestellten Loglevels.
Neben dem Security Log existiert noch das HTTP Log. Dies ist nicht per Voreinstellung aktiv. Der Speicherort wird über den Parameter icm/HTTP/logging_XX angegeben.
Wie bei dem Security Log wird die maximale Dateigröße durch den Parameter MAXSIZEKB und das Verhalten bei Erreichen der Grenze durch den Parameter FILEWRAP gesteuert
Das HTTP Log vermerkt spezifische Zugriffsereignisse wie Zugriffe ohne Authentifizierung (HTTP Code 401) oder Fuzzing Zugriff (HTTP Code 400). Generell wird auch der Zugriff auf kritische Webseiten hier protokolliert.
Das Log bietet dabei die Informationen über Datum und Uhrzeit, der IP des Angreifers, den angegebenen Benutzer zur Autorisierung, die HTTP Anfrage mit Parametern und Headern, den HTTP Antwort Code sowie den Inhalt der Anfrage in Abhängigkeit des eingestellten LOGFORMATes.
SAP Java Instanzen haben Standardmäßig das Logging aktiv. Dabei wird es im „simple mode“ betrieben, es werden also nur schwerwiegende Fehler und Ereignisse protokolliert, die sicherheitsrelevante und administrativen Tätigkeiten des Systems umfassen oder die Geschäftslogik betreffen.
Die Java Server-Logs beinhalten die Logdatei für die Responses. In dieser sieht man wann das System wie auf HTTP-Anfragen reagiert hat.
Finden sich in diesem Log „HEAD“ Anfragen, so können diese Einträge als Hinweise auf Verb Tampering Angriffe gesehen werden. Hier gilt es dann besonders gründlich die Angefragte URL mitsamt Ihren Parametern zu prüfen.
Ebenso lassen sich XSS Angriffe durch die Suche nach Schlüsselwörtern wie „%3C/script%3E“ identifizieren. Auch die berühmten Diretory-Traversal-Angriffe können hier aufgespürt werden. Eine Suche nach „/../“ oder „!252f..!252f“ kann hier als Ausgangspunkt verwendet werden.
Über den Parameter ms/audit kann die Protokollierung für den Message Server eingeschaltet werden. Mit dem Wert 1 werden An- und Abmeldungen protokolliert und der Wert 2 loggt auch Aktivierungen und Suspends eines Clients.
Welche weiteren Logs existieren in SAP?
Nicht alle Logs liegen als Dateien auf dem Betriebssystem vor. Es gibt weitere Logs, die bei der Untersuchung eines Incidents weiterhelfen können. Man weiß niemals auf was man als nächstes trifft. Die Änderungsprotokollierung kann helfen gewisse Aktionen im System besser nachvollziehen zu können. Es gibt 3 wichtige Änderungsprotokolle:
Die Tabellenprotokollierung ist im Standard nicht aktiv. Zur Aktivierung der Protokollierung im System selbst ist der Profilparameter rec/client auf ALL oder eine Komma-getrennte Liste der zu überwachenden Mandanten zu setzen. Zur Überwachung des Transportwesens muss der Wert r3transoptions = recclient=“XXX“ in das Transportprofil aufgenommen werden.
Die Protokolldaten werden in der Tabelle DBTABLOG hinterlegt und es existiert keine Obergrenze für die Datengröße. Die Logdaten können über die SAP-Transaktion SCU3 eingesehen werden.
Ein Logeintrag liefert Informationen zu dem Zeitpunkt, zu dem Benutzer und dem Applikations-Server auf dem die Änderung vorgenommen wurde sowie zu der Tabelle und den Feldwerten (alt und neu).
Ein SAP-System protokolliert Änderungen an Benutzer- und Berechtigungsdaten automatisch.
Die Logdaten werden in den USHXX Tabellen (wie USH02, USH04,…) unbegrenzt abgelegt. Die historischen Daten sind über den ABAP-Report RSUSR100N einsehbar.
In den Logdaten ist ersichtlich wann und von wem eine Änderung vorgenommen wurde. Ebenso welcher Benutzer von der Änderung betroffen ist und über welchen Programm oder Transaktion die Änderung erfolgt ist. Direkte Änderungen von Benutzer auf Datenbankebene können von diesem Log nicht erfasst werden. Unter normalen Umständen sollte so etwas jedoch niemals vorkommen. Interessant ist hier unter anderem welche Benutzer SAP_ALL oder SAP_NEW Profile erhalten bzw. verloren haben.
SAP-Systeme protokollieren Änderungen an betriebswirtschaftliche Objekten in Änderungsbelegen. Dies ist besonders wichtig für Objekte die kritisch sind oder der Revisionen unterliegen. Oft ist es sinnvoll oder sogar notwendig, solche Änderungen später nachvollziehen zu können, z. B. zu Revisionszwecken.
Die Daten der Protokollierung werden in den Tabellen CDHDR und CDPOS abgelegt. Eine Limitierung für den Speicherplatz gibt es nicht. Der Zugriff auf die Daten erfolgt über den ABAP-Report RSSCD200.
In den Logs ist der Benutzername, das Datum der Änderung die genutzte Transaktion sowie die Art der Änderung und die Änderungsnummer des Belegs einsehbar.
Rückblick
Genehmigen wir uns einen kurzen Rückblick. Am Steuer der Mittelstand & Co GmbH haben wir wilde Gewässer überquert und letztlich den richtigen Kurs gesetzt. Zu Beginn musste zunächst geklärt werden was „SAP-Sicherheit“ eigentlich bedeutet und welches Budget man jeweils benötigt. Dieses Budget musste dann noch erkämpft und ein passender Anbieter gefunden werden. Die Ergebnisse des SAP-Sicherheitschecks haben für dezente Schreckmomente gesorgt, doch inzwischen ist bei allen die Farbe ins Gesicht zurückgekehrt. Inzwischen macht die Härtung der Systeme Fortschritte und der zusätzliche Aspekt „Incident Response“ wurde angegangen.
Die erste Etappe ist gemeistert und die Reise zum sicheren Betrieb der SAP-Systeme jetzt in Angriff genommen werden. Dieses Thema habe ich hier bereits vorgestellt. Somit warten in der nächsten Kolumne neue unbekannte Gewässer auf uns!
Threat Detection ist ein Trend Thema der SAP Sicherheit. Die Bedrohungserkennung hat enorm an Bedeutung gewonnen. Höchste Zeit also zu beleuchten wie dies funktioniert.
Alle Threat Detection Systeme haben gemein, dass diese letztlich auf den Logs eines SAP Systems aufsetzen. Beispielsweise das Audit Log oder das System Log. Je mehr Logs ein solches Threat Detection System berücksichtigt, desto „besser“ kann es sich ein Bild der Bedrohungslage machen.
Security Audit Log als Basis
Die wesentlichen Kerndaten bezieht es dabei aus den bereits genannten Audit Log und System Log. Entsprechend ist die Konfiguration dieser Logs essentiell für ein funktionierendes Threat Detection. Frank Buchholz hat hier vor vielen Jahren bereits eine gute Zusammenfassung veröffentlicht, was sinnvoll zu prüfen ist:
Wichtige Ereignisse wie der Zugriff auf Benutzertabellen, das Starten von kritischen Programmen, Transaktionen oder RFC Funktionen sowie Änderungen an Benutzern durch „Nicht-Benutzer-Administratoren“ können hier protokolliert und ausgewertet werden.
Unter all diesen Einträgen solche zu finden, welche kritisch sind, ist wie die Suche nach der Nadel im Heuhaufen. Diese Nadel im Heuhaufen schnell zu finden ist Aufgabe der Threat Detection Systeme. Die vorliegenden Daten werden mit Zusatzdaten angereichert und so kann eine Bewertung der Ereignisse vorgenommen werden.
Dies stellt schon eine enorme Erleichterung für den Security-Admin dar, da er so viel Zeit spart und effizient neue Bedrohungen mitgeteilt bekommt.
Der werthAUDITOR erkennt viele Bedrohungsituationen und informiert umgehend den Security-Admin, damit dieser auf die neue Bedrohung reagieren kann.
Ist eine Threat Detection 100% zuverlässig?
Allerdings muss man auch offen beide Seiten bei diesem Katz und Maus Spiel von Angreifer und Verteidiger betrachten, um die Zuverlässigkeit solcher Threat Detection Systeme korrekt bewerten zu können.
Ist das Threat Detection System beispielweise in der Lage die Geolocation zu einem Login auszuwerten und somit in der Lage zwei Logins desselben Users aus unterschiedlichen Orten in kurzer Zeit zu erkennen und zu melden (da der User wohl kaum zig Kilometer in 5 Minuten überwinden kann), dann ist es gut zu wissen ob solche Situationen immer zu 100% zu erkennen sind.
Typischerweise leiten Angreifer Ihren Datenverkehr über die Systeme ihrer Opfer um. Dies bedeutet, dass ein Angreifer die Zugangsdaten wohl eher nicht von seinem heimischen PC aus nutzen wird, sondern über den Zugang zu dem PC des Opfers diese Zugangsdaten für den Zugriff auf das SAP System verwendet. Das SAP System sieht dann nur einen weiteren Login von DEMSELBEN System. Damit gibt es keine Auffälligkeiten und der Alarm bleibt stumm.
Systemhärtung mit Threat Detection on Top
Ein Threat Detection als „Schutz“ statt als Alarmanlage beinhaltet somit ein kalkuliertes Risiko, da Angreifer Wege kennen KEINE Spuren im Audit Log zu hinterlassen. Damit wird es für jedes darauf basierende System sehr schwer den Angriff zu erkennen. Ist das System jedoch gehärtet und der Angreifer kann gar nicht erst sein „Bedrohungsereignis“ ausführen, gibt es zwar auch keine Spuren, aber dies aus gutem Grund: Es ist auch nichts passiert!
Damit sollte klar sein, dass nicht jedes Feature eines Threat Detection Systems auch 100% Wasserdicht ist. Man kann sich somit nicht alleine auf den Einsatz eines Threat Detection Systems verlassen. Aus meiner Sicht ist es unerlässlich die Systeme zu härten, um die Angreifern nicht einmal einen Finger breit in das System zu lassen.
Ein Threat Detection System on Top rundet die Sicherheitsmaßnahmen dann sinnvoll ab. Der werthAUDITOR unterstützt als ganzheitliche Lösung vollständig bei der Systemhärtung und der Erkennung von Bedrohungen.
Da sind wir wieder bei unserem Nebenjob in der „Mittelstand & Co GmbH“. Wir haben Budget erkämpft und der SAP-Sicherheitscheck steht an. Es ist unser erster „SAP-Pentest“, was uns da wohl erwartet? Aus meiner persönlichen Erfahrung kann ich sagen, dass ein Pentest immer eine spannende Angelegenheit ist. Jeder Auftrag ist individuell mit seinen eigenen Herausforderungen.
„SAP-Penetrationstest sollten durch erfahrene Experten durchgeführt werden. Dies natürlich vor dem Hintergrund der Bedeutung der Systeme, ebenso sind gerade deshalb zuverlässige und ganzheitliche Aussagen durch einen Experten zu bewerkstelligen. Zur Durchfürung eines SAP-Pentest müssen dem Tester die typischen SAP Umgebungen und deren Schwachstellen sowie die Systemarchitektur und deren Security Architektur gut bekannt sein. Er muss zudem fähig sein den idealen Scope für den jeweiligen Kunden zu erkennen.“
Im Vorfeld wurde bereits viel über das Thema SAP-Sicherheit diskutiert bis endlich die Roadmap stand und das Budget genehmigt wurde. Das große Ziel ist der sichere Betrieb der SAP-Systeme. Doch bevor man zu diesem Ziel aufbrechen kann, gilt es herauszufinden wo man aktuell steht. Dazu soll der Sicherheitscheck dienen. Welche Ergebnisse dieser bringt, kann niemand seriös keiner vorhersagen. In all den Jahren des SAP-Betriebs bei der Mittelstand & Co GmbH ist bisher nichts vorgefallen. Darf man Schlussfolgern, dass es maximal ein paar Schrammen, aber keinen Knock-Out im Pentest gibt?
Ziele des Sicherheitschecks
Unser klar formuliertes Ziel für die Vergabe eines Pentests ist die Identifizierung von Schwachstellen im System. Dies soll zur Transparenz von Risiken für das Unternehmen führen. Die Risikominderung soll durch die Systemhärtung erzielt werden, was langfristig durch die Maßnahmen für den sicheren Betrieb dauerhaft gewährleistet werden soll.
Wichtig ist insbesondere, dass die Ergebnisse verständlich und detailliert dargestellt werden, da für uns in der Rolle als IT-Leiter das Gebiet SAP-Sicherheit Neuland (ob wir dort Frau Merkel treffen?) ist und kaum Expertise im Unternehmen existiert.
Hilfreich wären für uns zu jeder ermittelten Schwachstelle eine Schritt für Schritt Anleitungen zur Behebung.
Ein kurzfristiges Ziel wird dann sein die Daten (Business, Kunden, Mitarbeiter) im System zu schützen, um auch regulatorischen Anforderungen (z.B. DSGVO) gerecht zu werden.
Vorbereitung durch Auftraggeber
Was ist eigentlich für einen „Security-Check“ vorzubereiten, damit der Auditor „arbeiten“ kann? Braucht der Tester einen Arbeitsplatz oder bewerfen wir ihn besser mit der Firewall-Hardware aus dem ersten Stock? Er muss diese ja „überwinden“ können.
Der Tester hat unsere Gedanken wohl erahnt und uns eine Checkliste zur Vorbereitung ausgehändigt. Kurzer Check: Firewall Weitwurf steht nicht drin. Schade!
Die Liste ist gut strukturiert und auf einen authentifizierten Scan ausgerichtet, damit der Tester fundierte Aussagen kann:
Auf jedem SAP-System im Scope ist ein Audit-Benutzer mit einer mitgelieferten Berechtigungsrolle einzurichten.
Zugänge mit spezifizierten Berechtigungen für Whitebox-Checks auf Betriebssystem- und Datenbankebene sind vorzubereiten.
Einige Informationen zu den Zielsystemen und Administratoren werden benötigt
Für eine Remote-Prüfung wird ein sicherer VPN-Zugang benötigt und ein kurzer Testlauf vor Projektbeginn.
Das klingt machbar, trotz der alltäglichen Arbeitspflichten. Schön, dass nicht mehr Aufwand nötig ist.
Der Benutzeradministrator übernimmt den Punkt Anlegen des Audit-User mitsamt einspielen der Berechtigungsrolle. Die IT-Administration erstellt die Zugangsdaten für OS- und DB-Zugriff. Das SAP-Team stellt die angeforderten Informationen (SID, IP, Mandant, Stack, OS- und DB-Typ) zusammen. Nur das VPN muss der Firewall-Dienstleister einrichten. Das dauert wieder: Ticket beantragen, Rückfragen, Zuständigkeiten, … Da planen wir besser gleich etwas mehr Zeit für diesen Punkt ein.
Am Ende zittern wir ein wenig ob der Dienstleister bis zum angesetzten Termin endlich das VPN aufbaut, doch intern hat die Vorbereitung keinen Stress verursacht. Es ist ganz angenehm, wenn keine aufwendigen Änderungen (wie Custom Code) in den SAP-Systemen durchgeführt werden müssen. So lief auch der produktive Betrieb ungestört fort.
Der Security Check
Es ist soweit, die Vorbereitungen sind abgeschlossen: Heute wird getestet und geprüft. Als IT-Leiter ist uns ein reibungsloser Betrieb wichtig. Der Tester hat versprochen „wir werden nichts merken“. Warum hat er dabei nur so komisch gegrinst? Zur Sicherheit beobachten wir den Workload des Systems mit der ST03N. Der Tester hat sich vor ein paar Stunden gemeldet und den Start des Tests bekannt gegeben. In den Statistiken ist bisher nichts Auffälliges und bisher hat noch kein Mitarbeiter etwas von einem laufenden Pentest bemerkt. Ob wir das als gutes Zeichen werten können? Jedenfalls haben wir uns die Berechtigungsrolle für den Tester genau angesehen. Dabei haben wir Festgestellt, dass auch höhere Privilegien angefordert wurden. Doch der Tester hat uns beruhigt. Das ist alles nur zur Erhebung des Ist-Status. Die erhaltenen Zugriffsrechte werden bei der Verifizierung potentieller Risiken komplett außer Acht gelassen. „Schummeln habe ich nicht nötig!“ hat er lachend gesagt. Was kommt da auf uns zu?
Was macht der Pentester?
Ich bin ja von Natur aus Neugierig und frage mich: „Was macht denn so ein Pentester in seinem stillen Kämmerlein?“ Wollen wir mal gemeinsam ein wenig zuschauen?
Der Tester startet mit dem authentifizierten Whiteboxscan. Der Vorgang dauert seine Zeit, doch parallel kann er schon die ersten Ergebnisse sichten. Der Tester hat viel Routine und arbeitet seine geistige Checkliste anhand der eintreffenden Test-Ergebnisse ab:
Unsicheres SAP Gateway *OK*
SAP Standard Zugangsdaten *OK*
Patchstatus *OK*
Ablauf Initialkennwörter *NIE*
User mit Initialkennwort *MSCHULZ*
Default Initialkennwort im Unternehmen *init,1234*
FUN MODE *STARTING*
Bingo! Damit kann ein Pentester arbeiten. Der Zugang zum System steht. Welche Berechtigungen besitzt der übernommene Account? Die Antwort liefert eine schnelle Berechtigungssimulation mit seinem Audit-Werkzeug. Oh, schön! Debug mit Wertänderung ist in den Rollen des Users enthalten. Der Tester versteht sein Handwerk und 3,7 Sekunden später besitzt MSCHULZ das Profil SAP_ALL.
Es stehen jedoch noch weitere Prüfungen an, denn letztlich geht es bei einem Security Check nicht darum EINEN Weg in das System zu finden, sondern ALLE Risiken zu ermitteln. Lassen wir den Tester mit seiner Arbeit in Ruhe fortfahren.
Ende des Scans
Der Whiteboxscan lief ohne Auswirkungen auf den SAP-Betrieb durch. Der Tester sichtet die ermittelten Schwachstellen und bereitet den Abschlussbericht vor.
Damit wissen wir nun zumindest, es gibt etwas zu berichten. Welche Risiken hat der Tester wohl gefunden?
Gibt es Sicherheitsrisiken in dem Custom ABAP-Code?
Sind die RFC-Destinations zu dem BW-System sicher?
Welche Berechtigungen sind noch mal in unseren Standard-Rollen vergeben?
Ergebnisse
Endlich bekommen wir die Ergebnisse präsentiert.
Der Tester berichtet er hat SAP_ALL Zugriff erreicht. Der SAP_ALL Zugriff auf das System wurde Mehrstufig erreicht. Der Einstieg war möglich, da die Generierung der Initial-Kennwörter nicht sicher ist. Weil diese jedoch niemals ablaufen, konnte der Tester einen verwaisten User übernehmen. Als dritter Aspekt kamen dann zu weitreichende Berechtigungen in dessen Standard-Rollen zum Tragen und der Tester konnte so die Berechtigungsprüfungen in dem SAP-System umgehen und SAP_ALL erhalten.
Doch das ist nicht alles, es gibt da noch einen weiteren Punkt der zu untersuchen ist: Im ABAP Code wurde eine 8 Monate alte Backdoor gefunden. Diese erlaubt das Ausführen von Systembefehlen als <SID>Adm – ohne Protokollierung.
Insgesamt war die Abschlusspräsentation auf den Punkt gebracht. Die zusätzliche Dokumentation bestehend aus verschiedenen Zielgruppen orientierten Berichten enthält wertvolle Details und Anleitungen zur der Härtung der Systeme.
Insgesamt lief die Präsentation sehr anschaulich und die passenden Handlungsempfehlungen nehmen direkt den Schrecken.
Konzentrieren wir uns auf das Positive: Die Handlungsempfehlungen. Die Punkte „Ablauf Initialkennwörter“ und „Generierung Initialkennwörter“ lassen sich schnell abstellen. Die Anpassung der Berechtigungen wird eine größere Baustelle, da dort noch weitere Aspekte im Rahmen der Testergebnisse aufgefallen sind.
Die Backdoor im System ist da schon ein anderes Kaliber. Glückicherweise hat der Tester den Benutzernamen des Erstellers identifiziert und nach Rücksprache mit dem externen Berater ließ sich Sinn und Zweck dieser Pseudo-Shell zumindest Nachvollziehen. Der Report mit der Backdoor ist zwar schnell gelöscht, doch was, wenn das nicht so glimpflich ausgegangen wäre, wie läuft denn eine „Spurensuche“ im SAP-System“?
Ich finde das ist eine sehr gute Frage und denke der sollten wir im nächsten Beitrag nachgehen. Ob ich zur nächsten Kolumne meine Forensik-Lupe finden werde?
Ich würde gerne einen meiner Lieblingsangriffe mit Ihnen teilen:
Wie wäre es mit einem Angriff, bei dem Sie sich einen Benutzer Ihrer Wahl, ein System Ihrer Wahl und einen Client Ihrer Wahl aussuchen können und wie von Zauberhand sofortigen Zugriff erhalten?
OK, da ist ein Haken: Sie brauchen Zugriff auf das Dateisystem! Ist das ein großer Haken? Nun, ich sehe eine Menge Möglichkeiten: Zugriff auf OS-Ebene (wie in fast jedem Breach/Pentest), niedrig privilegierter Benutzerzugriff mit Download-Option und natürlich Schwachstellen mit OS-/Dateizugriff. In den meisten Fällen wird man einen passenden Einstiegspunkt finden.
OK, der Rest ist schnell erledigt:
Beschaffen der SAPSYS.PSE-Datei
Erzeugen Sie damit ein MySAPSSO2-Anmeldeticket für einen Benutzer (DDIC?) Ihrer Wahl in einem Mandanten Ihrer Wahl (000/produktiv).
Verwenden Sie das generierte Ticket zur Anmeldung. Der Einfachheit halber erstellt der werthAUDITOR eine SAP GUI Verknüpfung on the fly. Also nur ein Doppelklick und das System ist im Besitz.
Dies funktioniert sogar mit den neuesten S4/HANA Systemen. Der Screenshot zeigt die Ticket-Erstellungsnachricht in dem werthAUDITOR. Die letzte Zeile enthält den Pfad zur Sap-Gui-Verknüpfung.
Da dieser wirklich oft übersehen wird und eine kritische Auswirkung hat. Ein paar Hinweise zum Schutz:
Zugriff auf Dateisystem / SAPSYS.pse beschränken
Setzen Sie eine Passphrase (standardmäßig keine) für die Schlüssel in der PSE-Datei!
SSO-Ticket deaktivieren (login/accept_sso2_ticket = 0) – nur wenn möglich und wirklich unbenutzt!
Ist der DDIC gesperrt wie es die SAPNote 1998382 empfiehlt, gibt es eine weitere Quelle für Power-User: Die pfl-Dateien im System. Schauen Sie sich die automatisch generierten Änderungskommentare an. Dort finden Sie Benutzernamen mit starken Berechtigungen anstatt „blind“ den DDIC für ein Ticket zu nutzen .
Es wäre doch nur zu schön, wenn es eine Formel geben würde mit der jedes Unternehmen seine individuellen Folgerisiken von „SAP-Sicherheit einfach ignorieren“ berechnen könnte. Diesen Schaden oder die resultierende Summe X könnte man ignorieren (wenn die Kosten für SAP-Sicherheit höher liegen) oder als Motivation verwenden.
In der Realität sind die Folgerisiken jedoch immer nur „optional“ und kein „muss“ . Fehlende SAP-Sicherheit kann gar keine Auswirkungen auf ein Unternehmen haben (zumindest für einen Zeitraum X). An dem Tag X kann es jedoch das ganze Unternehmen durchschütteln. Schadensersatzklagen können die Folge sein, der Markenwert kann sinken oder Aktionäre können das Unternehmen verlassen.
Oft sind diese Risiken dem Unternehmen gar nicht bewusst, sie existieren einfach, weil SAP-Sicherheit ignoriert wird.
Daher ist es wichtig zu verstehen, dass in einem Unternehmen das Personal und die Geschäftsprozesse von SAP-Systemen abhängig sind. Egal ob es die kritischen Geschäftsprozesse, Gehaltsbuchungen oder die Logistik sind. Kommt es zu einem Ausfall das SAP-Systems stehen diese Prozesse und Einnahmen können verloren gehen.
Was kostet … ?
Dies und die abstrakten Angriffsfläche SAP wirklich zu sehen gelingt nicht jeder Unternehmensführung. Gerade weil das Ignorieren des Themas doch die letzten Jahre so gut funktioniert hat. Somit bricht das Management in der Regel SAP-Security auf 2 Punkte herunter:
Was kostet die Einrichtung und der Betrieb von SAP-Sicherheit dem Unternehmen?
Was kostet ein Sicherheitsvorfall -wegen fehlendem Security-Invest- das Unternehmen?
Punkt 1 haben wir in meiner vorherigen Kolumne ermittelt. Punkt 2 wirft zunächst weitere individuelle Fragen auf:
Was kostet eine Unterbrechung des Geschäftsbetriebs?
Welche Folgen hat ein Ausfall, sowohl monetär als auch bezogen auf die Reputation?
Was passiert, wenn der gesamte Betrieb ausfällt?
Wieviel Verlust entsteht, wenn die Systeme für die Geschäftsprozesse ausfallen?
Was könnte ein Datendiebstahl das Unternehmen kosten?
Diese Fragen müssen mit dem Management besprochen werden und helfen zugleich deren Sichtweise auf das Thema SAP-Sicherheit zu verändern. Die abstrakten Kosten eines erfolgreichen Angriffs sind nur schwer vorzustellen, aber diese Fragen regen zum Nachdenken an.
Angriffsszenarien gibt es viele und letztlich wirkt dies alles wie Angst schüren. Effektiver ist es die Kosten für SAP-Sicherheit (Punkt 1) mit den Vorteilen daraus zu verbinden. Abstrakt kann man darstellen in welchem Maß es schwieriger wird erfolgreich das System anzugreifen. So versteht das Management wofür es Geld genehmigt.
Im Folgenden sind einige Ideen skizziert, die zur Verbesserung von Budget-Gesprächen beitragen.
Die Sprache des Geldes sprechen
Auf Basis der obigen Fragen lassen sich die Folgen eines erfolgreichen Angriffs auf das SAP-System monetisieren. Damit kann man die Kosten „fehlender“ Sicherheit beziffern. Dem stellt man die Ausgaben zur Absicherung dieser Geschäftsprozesse entgegen. Zusätzlich sollte hierbei noch der Automatisierungsaspekt der verwendeten Lösung dargelegt werden, um zu zeigen wie zusätzlich die erforderlichen Ressourcen für einen sicheren Betrieb gesenkt werden. Dies ist ein zusätzliches Einsparungspotential, da die gewonnenen Ressourcen anderweitig eingesetzt werden können.
Ein konkretes Risiko verwenden
Sicherheitslücken und Vorfälle finden regelmäßig ihren Weg in die Schlagzeilen. Ist hier ein Thema aktuell, dass auch auf das eigene Unternehmen zutrifft, so sollte dies zum Anlass genommen werden das Thema Security-Budget zu besprechen. Das Management wird bereits sensibilisiert sein.
Anlässe ergeben sich jedoch auch aus Schwachstellen im eigenen Unternehmen – entweder extern gemeldet oder durch einen Security-Check erkannt. In Kombination mit dem „vermutlichen“ Alter der Sicherheitslücke, lässt sich hier der Handlungsbedarf erörtern. Gegenargumente wie dann ist ja seit Zeitraum X nichts passiert, sind als Steilvorlage zu verwenden: Gleich mal Aufzeigen, dass man ein unzureichendes Auditing besitzt und gar keine Aussage zu potentiellem Missbrauch treffen kann – geschweige denn diesen Erkennen würde.
Ebenso sind Gesetzesanforderungen wie das ITSiG2 oder die DSGVO mit den Strafzahlungen führen zu mehr Gehör im Management.
Roadmap darlegen
Zukunftssichere Investitionen sind hier das Schlagwort. Legt man eine verständliche Roadmap für die nächsten drei Jahre vor, fällt es dem Management leichter eine gute Investition zu sehen. Die Glaubwürdigkeit in die Security-Investition erhöht sich drastisch, wenn sichtbar wird welche tatsächlichen Auswirkungen auf den sicheren Betrieb einhergehen. Risikominimierung und frühzeitige Risikoerkennung lassen sich hier gut darstellen.
Vergleiche ziehen
Die DSAG liefert mit dem DSAG Prüfleitfaden einen einfachen Benchmark zur Systemsicherheit. Dies kann als Minimum der zu erreichenden SAP-Sicherheit angesehen werden. Durch den Anteil der „bestandenen“ Tests aus dem Prüfleitfaden wird das eigene Sicherheitsniveau vergleichbar. Erreicht man die Vorgaben kann man darauf aufbauen und ambitionierte Maßnahmen ergreifen, um „vorne“ zu bleiben. Wird der Benchmark verfehlt, ist dies allein bereits ein Maßgebliches Argument für mehr Budget.
Vermeiden Sie Fachjargon
Bei dem Thema Security Budget treffen häufig Welten aufeinander. Die kryptische Welt der Technik (selbst nicht alle ITler verstehen „Security“) und Business-Welt. In jedem Fall muss das Management abgeholt werden und es darf kein Vorwissen erwartet werden. Vermeiden Sie Begriffe ohne Erklärung zu verwenden: Die Sicherheit von RFC und ABAP, wirft möglicherweise sogar bei einem Security-Experten für Web-Anwendungen Fragen auf. Achten Sie auf Ihre „Flughöhe“ und erklären Sie wenn unvermeidbar die verwenden Fachbegriffe bereits in der Einleitung.
Konzentrieren Sie sich auf den Nutzen und das Können statt auf die Funktionsweise. Bleiben Sie im Kontext von RoI, Risikominderung oder Datenverlust. Enden Sie immer mit den Resultaten und Nutzen für die Geschäftsprozesse des Unternehmens.
Präsentation – das Auge isst mit
Der Mensch lernt visuell am effektivsten. Nutzen Sie dies und verwenden Sie Grafiken oder Modelle, um Ihre Botschaft zu transportieren statt sich auf den Charme von Excel zu verlassen. Bauen Sie ihrem Management so eine Brücke auf der es Ihnen zu neuen Ufern folgen kann.
Entscheidung
Das Gespräch um das Security Budget muss mit einer Entscheidung enden. Entweder trägt das Management das Risiko beziehungsweise ignoriert es weiter (schriftlich geben lassen) oder es wird investiert. Mit der richtigen Roadmap und Präsentation sitzen dann alle in einem Boot.
Denken wir an unsere Rolle als IT-Leiter bei der „Mittelstand & Co GmbH“ zurück. Mit den hier vorgestellten Ideen, schaffen wir es der Geschäftsführung die Notwendigkeit zum Handeln aufzuzeigen. Doch den Igel in der Tasche des CEO konnten wir nicht ganz vertreiben. Der CEO hat es so formuliert: „Ich benötigte einen Vertrauensbeweis in die vorgeschlagenen Sicherheitsmaßnahmen und Transparenz für diese „Sicherheitsrisiken. Wie verwundbar sind wir denn wirklich?“ Entsprechend wurde die erste Etappe der Reise genehmigt und eine Standortbestimmung der SAP-Sicherheit kann in Angriff genommen werden. Auf Basis deren Ergebnisse wird dann entschieden ob weiteres Budget freigegeben wird. Wie der Sicherheitscheck abläuft verfolgen wir in meiner nächsten Kolumne.
Corona mitsamt seinen Schutzmaßnahmen sorgt an vielen Stellen für einen Slow-Down oder Stillstand. Arbeitsplätze und Systemzugriffe werden mobiler (Homeoffice, Mobile Endgeräte). Zeit für Security ist da oftmals nicht eingeplant. Passend kommt da ein schwerer Zero-Day für iPhones in der Mail App zur Unzeit und ein Patch lässt aktuell auf sich warten.
Dabei kann man doch mit dem iPhone so schön auf die neuen Fiori Apps von SAP zugreifen – wer weiß wer einem jetzt dabei über die Schultern sieht.
Doch man merkt deutlich, dass an vielen Stellen damit gekämpft wird überhaupt arbeiten zu können. Security Projekte werden da hinten angestellt.
Heißt das Däumchen drehen für Security Consultants? Vielleicht – persönlich habe ich jedoch andere Erfahrungen. Ohne Details zu nennen ist jetzt endlich mal Zeit für die harten Nüsse. Die ein oder andere ist bereits geknackt, andere Schalen haben schwere Risse. Mein Umfeld hat bei den ersten Ergebnissen von einer Erschütterung der Macht gesprochen. Ein bissen Spass muss ja erlaubt sein in diesen Zeiten.
Leider liegt der Mantel des Schweigens über all dem, dafür ist es alles andere als Langweilig aktuell!
Gesund bleiben und Schwachstellen brechen ist die Divise der Stunde.
Die dort beschriebenen Angriffe zielen im Kern auf bereits bekannte Angriffe gegen das SAP-Gateway. Zum Schutz vor diesen Angriffen kann eine Zugriffsrichtlinie für das SAP-Gateway definiert werden. Diese erlaubt im Default nur Zugriff von dem Localhost und den zum „Internen“ Verbund zählenden SAP-Systemen.
Außenstehende erhalten damit keinen Zugriff auf das Gateway und können keine Angriffe ausführen. Als Ergebnis der neuen Angriffe gilt dies jedoch nicht mehr uneingeschränkt.
10KBLAZE
Zur Ausführung dieses Angriffes haben Sicherheitsforscher neue Wege identifiziert, um die ACLs auszutricksen.
Dazu nutzen Sie entweder einen vorgeschalteten SAP-Router oder im zweiten Weg den Zugriff auf den MS-Monitor Port.
Im ersten Fall bei einem Angriff über den SAP-Router wird eine Konfigurationslücke genutzt, die es erlaubt den SAP-Router als Proxy für Zugriffe auf das SAP-System zu nutzen. Diese entsteht, wenn der SAP-Router auf dem SAP-System oder einem zum „internen“ Verbund der SAP-Systeme zählenden System betrieben wird. Dann gewährt die Standard-ACL dem SAP-Router Zugriff auf das Gateway. Unter diesen Vorrausetzungen kann ein Angreifer den SAP-Router sodann als Proxy nutzen. Daraufhin erscheinen für das Gateway die Anfragen des Angreifers als kämen diese von dem SAP-Router und werden zugelassen. Damit kann ein Angreifer die ACLs umgehen.
SAP-Router als Proxy setzen
Beim zweiten Weg benötigt ein Angreifer Zugriff auf einen ungeschützten SAP-Monitor Port (39NN). Dann kann er dort -ohne die Notwendigkeit eines Logins- sein eigenes System zur Liste des „Internen“ SAP-Verbundes hinzufügen. Damit ist es ihm im im Anschluss möglich von seinem System aus die Gateway ACL zu passieren und auf das Gateway zuzugreifen.
Registrierung als „Trusted“ Server über MS Monitor
Starten eines Angriffs nach erfolgreicher „Registrierung“ als Trusted Server
Beide Wege erlauben dann die bekannten Angriffe gegen das SAP-Gateway auszuführen.
Risikoeinschätzung
Wie hoch ist jetzt das tatsächliche Risiko?
Grundlegend sollte ein SAP-Gateway mit ACLs abgesichert sein. Weiterhin sollten die SAP-Systeme durch eine Firewall geschützt sein. Bei der Nutzung eines SAP-Router für den Zugriff sollte dieser nicht auf dem SAP-System oder einem System, welches zu dem Verbund der „Internen“ SAP-Systeme gehört, betrieben werden.
Die Sicherheitsforscher konnten in Deutschland 733 „verwundbare“ SAP-Router aufspüren. Wie zuverlässig die Verwundbarkeit geprüft wurde, ist nicht beschrieben. Es ist jedoch zu erwarten, dass hier und dort ein SAP-Router zu finden ist, der als Proxy missbraucht werden kann.
Der SAP Monitor Port (39NN) für interne Kommunikation sollte definitiv nicht von außen erreichbar sein. Zusätzlich empfhielt sich der Schutz mit einer Firewall.
Laut Aussage der Sicherheitsforscher konnten 92 Systeme mit Zugriff auf den Monitoring Port in Deutschland identifiziert werden. Wie exakt die Ermittlung der Anzahl ist, kann nicht validiert werden. Dennoch ist zu erwarten, dass ein exponierter MS Monitor Dienst doch eher ein seltener Fund ist.
Schutzmaßnahmen
Was bleibt jetzt zu tun?
Die SAP-Router Installationen sind zu prüfen. Diese sollten nicht auf den SAP-Systemen oder Systemen des „Internen“ Verbund betrieben werden.
Für den Schutz des Gateways ist die SAP Note 1408081 Basic settings for reg_info and sec_info zu beachten.
SAP Monitor Dienste für die interne Kommunikation (39NN) dürfen nicht von Außen erreichbar sein. Zusätzlich kann eine Firewall schützen. Hier sind zwei Hinweise zu befolgen:
SAP Note 821875 Security settings in the message server
SAP Note 1421005 Secure configuration of the message server
