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.
Eigentlich eine einfache Frage und doch fällt eine ad-hoc Antwort irgendwie schwer, oder? Obwohl ich des Öfteren mit dieser Frage konfrontiert werde, kann ich dies eigentlich nie pauschal beantworten. Denkt man ein wenig über die Frage nach, wird schnell klar: Zur Beantwortung ist zwingend die individuelle Situation des Fragestellers zu berücksichtigen. Um eine Antwort auf diese Frage zu finden, muss man zunächst einige Informationen erhalten:
Welche Intention wird mit „der SAP-Sicherheit“ verfolgt? Was ist der eigentliche Bedarf, der abgedeckt werden soll?
Gilt es den Ist-Zustand zu ermitteln oder ist ein kontinuierliches Sicherheitsmonitoring gewünscht?
Wie sind die verschiedenen Angebote zu bewerten? Marketing Unterlagen, Vertriebs-Referenzen oder gar nach Leistung?
Wie breit (Scope) und tief (Ebenen) sollen denn Risiken gesucht werden?
Wie viel und was für „SAP“ ist eigentlich da, das „sicher“ sein soll?
Bis zur Antwort auf diese Frage liegt also ein kleiner Weg vor uns. Mit ein wenig Geduld und Informationssuche zu den genannten Punkten gelangen wir sicher ans Ziel.
„Die Kosten für SAP-Sicherheit lassen sich nur schwer pauschal benennen. Hingegen kann der Preis für fehlende Sicherheit mitunter recht hoch sein. Wichtig ist eine passgenaue Lösung für die individuelle Situation zu finden und nicht einfach „SAP-Security“ als Black-Box kaufen ohne Nachweis des tatsächlichen Nutzens.“
Fangen wir also von vorne an und starten mit der ersten Aufgabe.
Welche Intention wird mit „der SAP-Sicherheit“ verfolgt?
Um hier eine Antwort zu finden, kann man sich den Prozess SAP-Sicherheit als Wegbeschreibung vorstellen. Dazu muss man zunächst Wissen wo möchte man „hin“. Langfristig kommt als Ziel eigentlich nur der sichere Betrieb in Betracht. Damit ist klar wo die Reise hingehen soll. Doch für eine Wegbestimmung benötigt man auch einen Startpunkt. Diesen identifizieren wir mit einer Messung der aktuellen Sicherheit als Standortbestimmung. Damit haben wir schon mal die vor uns liegende Strecke identifiziert. Die Reise geht wie so oft von dem Ist-Zustand zum Soll-Zustand.
Die Frage wie wir reisen möchten, verschieben wir auf später. Jetzt gilt es unsere tatsächliche Reise zu planen.
Kennen wir bereits unseren ungefähren Standort? Oder sollten wir zunächst eine Etappe zur Standortbestimmung einplanen?
Brauchen wir nur einen „Stempel im Ausweis“ und müssen nur kurz über die Grenze fahren, um den Stempel zu bekommen? Dann sollte ein Compliance-Nachweis ausreichen.
Möchten wir dauerhaft einen sicheren Betrieb etablieren? Dann machen wir die komplette Fahrt.
Ich denke es steht außer Frage, dass wir hier echte Sicherheit und nicht nur den „Schein“ anstreben. Also steht uns die große Fahrt bevor. Für einen selbst möchte man vor so einer solchen Reise doch gerne etwas „Sicherheit tanken“. Unser Reiseführer (der Anbieter) soll ja auf der langen Reise auch zu uns passen. Also entscheiden wir uns für eine Standortbestimmung als erste Etappe, um dann die große Reise anzutreten.
Wie sind die verschiedenen Angebote zu bewerten?
Mit dem Wissen, dass wir auf große Reisen fahren möchten und der Erkenntnis vorher noch etwas Fahrtraining zu erhalten, gilt es nun den passenden Anbieter zu finden. Damit sind wir wieder bei der Frage wie wollen wir Reisen?
Ein wesentlicher Fixpunkt ist „SAP“ auf unserer Reise, somit sollte der Anbieter zwingend über fundierte Expertise auf dem Gebiet SAP-Sicherheit verfügen. Wir kaufen ja auch kein Auto von der Bahn – auch wenn diese viel Erfahrung im Personentransport besitzt. Damit will ich sagen, dass der etablierte Partner aus dem Bereich IT-Security/Pentesting wirklich den Nachweis erbringen sollte auf dem Gebiet SAP-Security zu Hause zu sein. Es liegen doch Welten zwischen der Sicherheit auf Betriebssystem- und Netzwerk-Ebene und der in den SAP-Applikations-Ebenen. Auch wird ein spezielles Werkzeug benötigt. Man nehme doch nur den DSAG Prüfleitfaden zum Vergleich. Der Umfang ist manuell nicht in ein paar Tagen zu prüfen und im Vergleich zu spezialisierten Werkzeugen ist der DSAG-Umfang eher gering. Da reichen dann auch keine Open-Source Werkzeuge wie Metasploit, PowerSAP aus, um eine vollständige Prüfung durchzuführen.
Ebenso glaubt inzwischen sicher niemand mehr, dass die bestandene Jahresabschlussprüfung beim Wirtschaftsprüfer wirklich bedeutet das eigene SAP-System wäre sicher.
Falls man der Meinung ist der Dienstleister oder Hoster würde das Kind schon schaukeln, dann bitte einfach zur Verifikation einen entsprechenden Nachweis oder Dokumentation der Systemsicherheit anfordern. Wenn hier „nur“ der Earlywatch-Report als Nachweis kommt, dann ist es Zeit zu handeln…
Es gibt inzwischen diverse auf SAP-Sicherheit spezialisierte Anbieter. Wir suchen einen Anbieter der sowohl in der Breite ( SAP-Landschaft (Risiken aufgrund der Verflechtung), SAP-Layer (ABAP-Stack, Java-Stack,…) und IT-Landschaft) als auch in der Tiefe (siehe Bild Prüfungstiefe ) umfassend die Sicherheit bewerten kann.
[Prüfungstiefe: Ganzheitliche Sicherheit für SAP-Systeme]
Somit sollte das Augenmerk zur Beurteilung auf den tatsächlichen Leistungen liegen und nicht auf die schönsten Marketingaussagen oder besten „Referenzdeals“. Ein schönes Beispiel dazu habe ich kürzlich in der Fernsehwerbung gesehen:
„SUPER-Wasch! Das einzige Waschmittel, dass auch unsichtbare Flecken entfernt!“
Klingt super, oder? Wenn man erst mal an einer einzigen Lösung für unsichtbare Flecken glaubt, dann ist die ganze Wäsche voll von unsichtbaren Flecken. Und nach dem Waschen sieht man die gar nicht mehr! Perfekt.
In der SAP-Welt könnte man dies als Denkanstoß nehmen. So empfiehlt jeder Experte (nicht nur bei SAP-Systemen) die „Security“-Logs auf einem eigenen Log-Server zu sammeln, um im Fall einer Systemkompromittierung manipulationssichere Logs zur Auswertung zu haben. Da könnte man doch mal bei einigen Anbietern hinterfragen, warum denn im Kontrast dazu die komplette Sicherheitslösung IN SAP betrieben wird und wie es mit dem Manipulationsschutz bei einem erfolgreichen Angriff aussieht?
Somit haben wir neben der tatsächlichen Leistung mit dem „Betriebsort“ der Lösung ein zweites Bewertungskriterium.
Ein drittes Kriterium ist der Aufwand und die Bedienbarkeit. Wie viel Zeit muss ich in die Einrichtung und den Betrieb der Lösung investieren, um meinen Nutzen zu erhalten? Hier können Erfahrungswerte als implementierten Projekten (Kundenaussagen) herhalten.
Diese drei Kriterien sind unser Wegweiser bei der Angebotsbewertung. Da lassen wir uns auch nicht blenden, wenn jemand einen Stern auf sein Auto klebt und den doppelten Preis verlangt. Bei einem direkten Vergleich hilft das maximal „optisch“ und wirkt im Vergleich gegebenenfalls deplatziert.
Der Preis ist natürlich auch zu beachten, doch hier spielt natürlich individuell der Leistungsumfang und die Ausrichtung eine zusätzliche Rolle. Somit bleibt neben dem Leistungsvergleich auch der Preisvergleich.
Wie viel und was für „SAP“ ist eigentlich da, das „sicher“ sein soll?
Unmittelbare Auswirkung auf die Kosten hat naturgemäß die Menge. Ob ich drei oder dreihundert SAP-Systeme betreibe wirkt sich ja auch dezent auf die Anschaffungs- und Wartungskosten gegenüber der SAP SE aus.
Möchte man hier an der Kostenschraube drehen, so ist eine Option auf Basis der Bedeutung für den Geschäftsbetrieb die Anzahl der zu „sichernden“ Systeme zu filtern. Allerdings ist das ein wenig Mut zur Lücke, da ungeschützte Systeme doch gerne mal als Sprungbrett verwendet werden. Solche Systeme sollten dann wirklich keine Verbindung (weder Daten noch ähnliche Zugangsdaten) zu den geschützten Systemen aufweisen.
Budgetplanung: Was muss man denn jetzt für SAP-Sicherheit einplanen?
Die Hausaufgaben sind erledigt und die Reise geplant:
Wir möchten zunächst unseren Standort bestimmen. Dabei ist uns tiefe SAP-Security Expertise zur Bestimmung wichtig.
Wir möchten langfristig einen sicheren Betrieb der SAP-Systeme. Dabei ist uns ein Leistungsvergleich der Breite und Tiefe verschiedener Lösungen wichtig. Zudem der „Betriebsort“ der Lösung sowie die Erfahrungswerte für den Ressourcenaufwand zur Installation und Pflege.
Zur Verdeutlichung nehmen wir mal die Rolle eines IT-Leiters im Unternehmen „Mittelstand & Co GmbH“ ein. Dort werden eine SAP ERP Landschaft (P,Q,E) sowie zwei BW (P,E) Systeme betrieben. Da nahezu alle Betriebszahlen über das BW laufen und das Entwicklungssystem mit diesem verbunden ist, spricht vieles dafür alle 5 SAP Systeme abzusichern.
Als erste Etappe wird die Standortbestimmung geplant. Dabei wird aus Kostengründen „nur“ das produktive ERP als Gradmesser geprüft. Jedoch soll zusätzlich die SAP-Landschaft analysiert werden, um Risiken aus dem Landschaftsaufbau zu erkennen und generell ein Bild über den Datenaustausch zu erhalten. Mit diesem Zwischenstopp haben wir die Möglichkeit den Anbieter kennen zu lernen, die Ergebnisse zu bewerten und dann bewusst die Entscheidung zu treffen mit diesem Anbieter die Reise fortzusetzen. Die Etappe sollte in zwei, drei Tagen gemeistert sein.
Ein solches Projekt benötigt ein Budget im gehobenen 4-stelligen bis niedrigen 5-stelligen Bereich. Angebote darunter stammen entweder von zwielichtigen Zauberern oder liefern möglicherweise nicht die gewünschten Ergebnisse. Bei höheren Angeboten darf man eine nachvollziehbare Begründung erwarten.
Die Berechnung des Budgets für die restliche Reise basiert auf dem Entschluss insgesamt 5 SAP-Systeme abzusichern. Im Unterschied zur ersten Etappe kommen hier neben den Kosten für Dienstleistungen auch Kosten für die gewünschte Lösung zum Tragen. Im Vergleich zur Standortbestimmung müssen wir mit 5 bis 10 fachen Kosten kalkulieren, um unseren Anforderungen gerecht zu werden. Natürlich kann man auch jederzeit mehr investieren, dies jedoch bewusst vor dem Hintergrund, dass hier gezielt Zusatzleistungen erworben werden. Die vermutliche Reisedauer gibt das Navi-Orakel mit ca. 1 Woche an.
Damit stehen Hausmarken zur weiteren Planung fest. Somit gilt es die Budgets für die einzelnen Schritte einzuplanen und zu beantragen. Die Messung des Ist-Zustandes ist hier ebenso zu berücksichtigen wie der sichere Betrieb der SAP-Landschaft. Dies führt gleich zur nächsten großen Frage: „Welche Argumente helfen dem CIO beim Security-Budget?“
Diese Frage vertagen wir bis zum nächsten Beitrag. Ich besorge mir derweil schon mal Popcorn für die Schlacht um das Budget. Oder war es das Buffet?
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
Im Februar 2019 hat das BSI die Aktualisierung seines IT-Grundschutzkompendiums veröffentlicht. Im Rahmen des IT-Grundschutz werden Anforderungen für den sicheren Betrieb von SAP-ERP-Systemen genannt.
Zielstellung des Bausteins
Im Baustein selbst sind die Ziele und Abgrenzungen wie folgt beschrieben:
Der Baustein beschreibt, welche Gefährdungen für SAP-ERP-Systeme zu beachten sind und wie diese Systeme sicher installiert, konfiguriert und betrieben werden können. Er richtet sich an Informationssicherheitsbeauftragte und Administratoren, die dafür verantwortlich sind, SAP-ERP-Systeme zu planen und umzusetzen.
Der Baustein beschränkt sich auf die Kerninstallation eines SAP-ERP-Systems und fokussiert die spezifischen Merkmale des darunterliegenden SAP-NetWeaver-Applikationsservers.
APP.4.2: SAP-ERP-System
Besondere Bedrohungen
Der Baustein nennt vier wesentliche Bedrohungen für die Sicherheit von SAP-ERP-Systemen.
Fehlende Berücksichtigung der Sicherheitsempfehlungen von SAP
Eine nichtbeachtung der von SAP Empfohlenen Sicherheitseinstellungen und -maßnahmen kann zu schweren Sichereheitsproblemen führen. Das gesamte System kann angreifbar werden.
Fehlendes oder nicht zeitnahes Einspielen von Patches und SAP-Sicherheitshinweisen
Patches schließen bekannt gewordene Schwachstellen. Bleibt ein zeitnahes einspielen aus, können offene bekannte Schwachstellen für unautorisierten Systemzugriff oder -ausfall missbraucht werden.
Mangelnde Planung, Umsetzung und Dokumentation eines SAP-Berechtigungskonzeptes
Ohne ein durchdachtes Berechtigungskonzept erhalten Benutzer oftmals mehr Berechtigungen als notwendig. Dies ermöglicht vorsätzliche Manipulation oder Sabotage. Eine fehlende Dokumentation verhindert die Nachvollziehbarkeit und Pfelge. Als Folge könnten ggfs. ausgeschiedene Mitarbeiter weiterhin auf die Systeme zugreifen.
Fehlende SAP-Dokumentation und fehlende Notfallkonzepte
Fehlt die Dokumentation wie und mit welcher Konfiguration das System aufgebaut wurde kann dies zu Verzögerungen bei der Wiederanlaufzeit im Notfall führen. Ebenso besteht die Gefahr, dass im Notfall keine detaillierte Beschreibung existiert, wie die Verantwortlichen vorzugehen haben.
Im dem fünften Teil der Serie „Howto SAP Security“ (Gateway , Netzwerk,Datenbank, RFC ) ist das Thema der Internet Communication Manager (ICM).
Internet Communication Manager (ICM)
Der ICM nimmt Anfragen über das HTTP(s) Protokoll entgegen. Insbesondere Aufrufe aus dem Internet an das SAP-System lassen sich so seit geraumer Zeit realisieren. Diese Aufrufe gibt der ICM je nach Architektur an den JAVA oder ABAP Dispatcher zur Verarbeitung weiter. Dies ist auf dem folgenden Schaubild zu erkennen:
Architektur SAP ABAP / JAVA mit ICM (Quelle SAP: https://help.sap.com/doc/saphelp_scm70/7.0/ru-RU/48/03b72c49f04aa5e10000000a421937/frameset.htm)
Im vierten Teil der Serie „Howto SAP Security“ (Gateway , Netzwerk,Datenbank ) ist das Thema ABAP RFC.
Sicherheitsrisiken bei ABAP RFC
Die Remote Function Calls (RFC) finden breite Anwendung in SAP ABAP Systemen. Ein Benutzer kann ABAP Funktionen, die Remote aufrufbar sind, von anderen Systemen aus aufrufen.
Dazu muss er jedoch die System ID, den Mandanten, sowie die Zugangsdaten des Benutzers kennen.
