Werth IT, Hersteller der prämierten SAP-Security-Lösung WerthAuditor bietet das, wonach viele SAP-Kunden seit langem suchen: ein tiefgreifendes und manipulationssicheres System zur Angriffserkennung und Sicherheitsbewertung ihrer SAP-Landschaft. Brandneu ist das Security Dashboard 2.0, das alle durch den WerthAuditor erkannten Sicherheitsrisiken in den Systemen visualisiert und eine Bewertung der zugehörenden Sicherheitsprozesse ermöglicht. Das interaktive und editierbare Dashboard bereitet übersichtlich alle Sicherheitsinformationen in Echtzeit auf.
Das neue Security Dashboard 2.0 der WerthAuditor-Plattform für SAP-Systeme ermöglicht wertvolle Analysen und Zugriff auf Sicherheitsdaten in Echtzeit
Der diesjährige 1. Mai war für viele IT-Experten nicht nur ein Feiertag, sondern vor allem ein Tag, der SAP-Kunden vor neue Herausforderungen stellt: Denn ab dem 1. Mai 2023 greift das IT-Sicherheitsgesetz 2.0 (kurz IT-SIG 2.0), das die deutsche KRITIS-Regulierung von 2015 deutlich erweitert. Das bedeutet: mehr Pflichten für Unternehmen und IT-Verantwortliche, höhere Cyber-Security-Anforderungen und erweiterte Befugnisse für Staat und Regulierungsbehörden. Eine anspruchsvolle Aufgabe für Unternehmen, die für ihre kritischen Infrastrukturen SAP einsetzen und somit im Fokus des IT-SIG 2.0 stehen, denn die meisten Lösungen erfüllen die steigenden Security-Anforderungen nicht im gewünschten Umfang.
Security Dashboard 2.0 – Angriffserkennung und Risiken auf einen Blick
Die neueste Innovation der Werth IT – ein übersichtliches Dashboard, das alle Sicherheitsrisiken sowie die dazu gehörenden Sicherheitsprozesse in den Systemen innerhalb einer Oberfläche in Echtzeit aufzeigt – kommt daher genau zur richtigen Zeit. Die Visualisierung sämtlicher Sicherheitsinformationen aller miteinander kommunizierenden Systeme der kompletten SAP-Landschaft zentral in nur einem Dashboard ist eine echte Innovation und ein Alleinstellungsmerkmal der Lösung. Zudem können Security-Fachkräfte aus dem Haupt-Dashboard heraus die für ihren Verantwortungsbereich relevanten detaillierteren Einzel-Dashboards ansteuern und tiefgreifende Informationen zu einzelnen Bereichen abrufen. Ebenfalls äußerst wertvoll: Das Dashboard zeigt in Echtzeit und en Detail, wie sicher die SAP-Landschaft aufgestellt ist, welche Rubriken zu verbessern sind und wo unmittelbares Handeln erforderlich ist.
Die wichtigsten Features des WerthAuditor in Überblick
Der WerthAuditor bietet SAP-Kunden eine umfassende Angriffserkennung: Er enttarnt Angriffe, deckt Sicherheitsrisiken auf und visualisiert die zugehörigen Sicherheitsinformationen – in allen miteinander kommunizierenden Systemen der IT-Landschaft. Jederzeit und in Echtzeit analysiert die Security-Lösung die Sicherheitskonfiguration, weist auf fehlende SAP-Security-Notes und Patches hin und überprüft den gesamten ABAP-Quellcode – und zwar nicht nur den für Kunden zugängigen Bereich, der lediglich einen kleinen Teil das ABAP-Codes ausmacht. Ferner prüft die Lösung das Betriebssystem, die Datenbanken, Schnittstellen sowie die Berechtigungen. Zusätzlich lässt sich an der Entwicklung des Security-Reifegerades sowie der Lebensdauer von Schwachstellen die Wirksamkeit der internen Security-Prozesse ablesen und analysieren.
Modernste, intelligente Security-Analyse mit mehr als 2.000 Prüfungen
Während herkömmliche Prüfsysteme die erhobenen Daten häufig in Tabellen darstellen, verwendet Werth IT die SIEM(Security Information and Event Management)-Technologie, mit deren Hilfe alle gesammelten Sicherheitsdaten vollständig über Schlagworte und beliebige Zeiträume filterbar sind und ganzheitliche, tiefgreifende Sicherheitsanalysen aller Systeme ermöglichen. Dies bedeutet zugleich maximale Effizienz für Threat Detection, Vulnerability Management und Patch Management.
Weitere wichtige Aspekte: Die Werth-IT-Lösung arbeitet mit Zero Footprint und erfordert keine Softwareinstallation beziehungsweise Agenten auf dem lokalen System. Ebenfalls wichtig: Die Lösung benötigt keine stehende Internetverbindung. Dadurch sind alle Sicherheitsdaten manipulationssicher, denn Angreifer der überwachten SAP-Systeme können nicht auf die Prüflogik, das Dashboard oder dessen Daten zugreifen.
Für die Sicherheits-Teams und die Verantwortlichen stehen mehrere vollständig anpassbare Dashboards zur Verfügung. „Das Management und die IT nutzen unser Security Dashboard für den Zugriff auf unverfälschte Echtzeitdaten, um auf dieser Basis kompetente und richtungsweisende Beschlüsse zu fassen. Mit über 2.000 Prüfungen und einem kontinuierlichen Monitoring liefert der WerthAuditor optimale Voraussetzungen, um alle Anforderungen des IT-SIG 2.0 zuverlässig zu erfüllen“, erklärt Thomas Werth, Geschäftsführer der Werth IT.
Das Security Dashboard 2.0 für SAP ist ab sofort verfügbar und als Webanwendung von jedem Device aus aufrufbar.
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?
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 zweiten Teil der Serie „Howto SAP Security“ (Teil 1) wird die Netzwerksicherheit betrachtet. Hierbei sind zwei Punkte von besonderer Bedeutung. Zuerst ist die Zugriffskontrolle zu betrachten. Dann folgt die Verschlüsselung der Kommunikation.
SAP Netzwerksicherheit
SAP beinhaltet diverse Dienste, die größtenteils aus dem Netzwerk heraus erreichbar sind. Es ist wichtig die verfügbaren Dienste zu kennen, daher zeigt der folgende Screenshot einige wichtige Dienste.
SAP Portliste, Quelle: https://help.sap.com/viewer/ports
Um Remote zu erkennen, welche Dienste konkret von einem SAP-System in Netzwerk angeboten werden, ist ein Netzwerkscan des Systems ein gutes Mittel. Ein Beispiel eines Scans kann wie folgt ausfallen:
PORT STATE SERVICE VERSION
21/tcp open ftp?
22/tcp open ssh SSH (SSH-2.0-WeOnlyDo 2.1.3)
445/tcp open microsoft-ds?
3200/tcp open sapdisp SAP ABAP Dispatcher release 7010, patch level 111, database release 701 (DB name T11)
3300/tcp open sapgateway SAP Gateway (Monitoring mode disabled)
3389/tcp open ms-wbt-server Microsoft Terminal Service
3600/tcp open sapms SAP Message Server (SID T11, ID 00)
3900/tcp open sapms SAP Message Server (SID T11, ID 00)
7210/tcp open maxdb SAP MaxDB 7.7.07
8000/tcp open sapicm SAP Internet Communication Manager
8100/tcp open sapmshttp SAP Message Server httpd release 701 (SID T11)
40080/tcp open sapigs SAP Internet Graphics Server
50013/tcp open sapstartservice SAP Management Console (SID T11, NR 00)
Hier sieht man neben typischen SAP Diensten auch noch weitere kritische Dienste wie SSH, MSRDP, SMB und FTP.
Seit dem 25. Mai 2018 sind Verstöße gegen die Datenschutz-Grundverordnung (DSGVO) mit empfindlichen Geldbußen belegt. Entsprechend viel Aufmerksamkeit hat das Thema bereits erhalten. Doch wie sieht eine Compliance Prüfung und ein Nachweis der Rechenschaftspflicht im Kontext von SAP-Systemen aus?
DSGVO Umsetzungsstatus in den Unternehmen
Die Datenschutzbeauftragten in den Unternehmen und Behörden haben sicher auch ohne Berücksichtigung der SAP-Systeme keine Langeweile.
Nachdem die Verfahren dokumentiert und Prozesse festgelegt sind rücken die SAP-Systeme in den Vordergrund. Hier sind beispielsweise die definierten Lösch- und Sperrprozesse technisch einzurichten. Doch aufgepasst, denn es ist sicher mehr zu beachten als nur Daten zu sperren und zu löschen. „DSGVO Compliance bei SAP-Systemen“ weiterlesen
Mit diesem Beitrag startet die Serie „Howto SAP Security“. In der Serie werden typische SAP Angriffsflächen vorgestellt – mitsamt Angriffsvektoren und Gegenmaßnahmen. Zu Beginn der Serie wird daher mit dem SAP Gateway das wahrscheinlich größte Angriffsziel betrachtet.
SAP Gateway
Das SAP Gateway ist eine Schnittstelle des Systems nach außen. Es dient der Kommunikation mit anderen Systemen oder Programmen und regelt jegliche RFC Kommunikation. Das Gateway ist eine Kernkomponente der SAP Netweaver Systeme.
RFC Kommunikation, Quelle: SAP – Securing Remote Function Calls
Für einen Angreifer sind folgende Eigenschaften des Gateways von Bedeutung.
Zuerst ist die Ausführung mit <SID>adm Rechten im System zu nennen. Weiterhin besitzt es Funktionen zur Befehlsausführung auf OS-Ebene. Letztlich ist das Gateway ohne Authentifizierung nutzbar.
Die Vernetzung der Systeme nimmt immer weiter zu. Industrie 4.0 sowie IoT sind hier wesentliche Faktoren. Doch ein Faktor im IT-Betrieb scheint unverändert gültig zu bleiben:
Die Systeme müssen „laufen“. Patch-Management und Security erhalten daher nicht immer die erforderliche Priorität. Dies führt letztlich zur Anbindung von Systemen an das Internet, die veraltete Releases nutzen oder nicht die neuesten Security-Patches erhalten.
Anhand dieser Systeme lässt sich anschaulich skizzieren wie Hacker SAP-Systeme identifizieren und angreifen. Das Verständnis wie ein Hack eines solchen SAP-Systems abläuft, dient hier der Sensibilisierung der Systemverantwortlichen. Dies wiederum sollte sodann zur Härtung der SAP-Systeme führen.
Warum ist die Internet-Anbindung ein Risiko?
Die globale Erreichbarkeit des Systems durch die Anbindung an das Internet sorgt für eine deutliche Steigerung der Gefährdung des Systems. Dies liegt einfach daran, dass ab dem Moment der Internet-Anbindung jeder dieses System aufspüren und angreifen kann.
Jedes System bietet auch im Normalfall eine gewisse Angriffsfläche. Denn ein System wird in der Regel zu einem bestimmten Zweck an das Internet angeschlossen und bietet für diesen Zweck vorgesehene Dienste im Internet an. Beispielweise bieten die im Internet bekannten Web-Server ihre Webseiten über einen Web-Dienst (HTTP/HTTPS) an.
Dienste können bekanntlich Schwachstellen haben. Dies gilt auch für SAP-Systeme. Hier sind 4 bekannte und „gefixte“ Schwachstellen in SAP-Systemen aufgeführt, die für potentielle Angriffe aus dem Internet nutzbar sind:
2234971 – Directory-Traversal in AS Java Monitoring
SAP NetWeaver AS Java 7.10 bis 7.50 verwundbar
1682613 – Fehlende Berechtigungsprüfung im Core-Service
SAP NetWeaver AS Java 6.40 bis 7.31 verwundbar
2101079 – Mögliche Änderung/Offenlegung von persist. Daten in BC-ESI-UDDI
SAP NetWeaver AS Java 7.11 bis 7.50 verwundbar
Wie hoch ist nun die Wahrscheinlichkeit potentiell verwundbare Systeme im Internet zu finden? Beispielsweise in einem technologisch fortschrittlichem Land wie Deutschland…
SAP-Systeme mit Shodan.io finden
SAP-Systeme lassen sich relativ zuverlässig und kostenlos mit Shodan.io aufspüren. Die hier ausgesuchten Schwachstellen beziehen sich auf Systeme des Typs SAP NetWeaver AS Java. Solche Systeme findet diese Suche bei Shodan „sap as Java„. Insgesamt werden 2391 Systeme gefunden.
Shodan Suche
Anhand des Server Tags in der Ergebnisliste lässt sich einfach die Version ablesen:
Server: SAP NetWeaver Application Server 7.21 / AS Java 7.31
Dieses System wäre potentiell für 3 der 4 genannten Schwachstellen anfällig.
Schränkt man die Suche auf Deutschland ein („sap as Java country:DE„), so werden immer noch 183 Systeme gefunden.
Shodan Karte für Deutschland
Darunter sind durchaus neuere Systeme:
server: SAP NetWeaver Application Server 7.45 / AS Java 7.50
Jedoch könnten immer noch 2 der 4 Schwachstellen vorhanden sein.
Es lässt sich jedoch auch gezielt nach älteren Systemen suchen: „SAP J2EE Engine„. Hier werden 1078 Systeme gefunden. Vornehmlich veraltete Systeme.
server: SAPJ2EEEngine/7.00
Auch in Deutschland stehen noch 70 solcher Systeme.
Karte für ältere Systeme in Deutschland
Zwei potentielle Schwachstellen lassen sich diesen älteren Versionen zuordnen.
Shodan zeigt sich wirklich auskunftsfreudig zu diesen Systemen.
Detailansicht in Shodan
An dieser Stelle kann man soweit festhalten, dass mit wenig Aufwand und kostenlos eine immense Liste an potentiell verwundbaren Systemen identifiziert werden kann.
An 4 theoretischen Beispielen lässt sich nun die Gefährdung solcher Systeme nachvollziehen.
Beispiel Hack 1: Anonymer Datei Download (SAP Hinweis 2234971)
Ein Angreifer kann unter Kenntnis der URL der verwundbaren Komponente beliebige Dateien des Servers herunterladen. Dies sogar ohne gültiges Login. Auf diesem Weg kann sich ein Angreifer Zugriff auf den Passworttresor (SecStore) des Systems verschaffen. Diesen kann er im Anschluss knacken (decodieren) und erhält die darin enthaltenen administrativen Zugangsdaten. Mit diesen Logindaten hat er dann Vollzugriff auf das System.
Beispiel Hack 2: Anonymer Dateitransfer (SAP Hinweis 1682613)
In dem Kernservice des P4-Dienstes von SAP Netweaver AS Java Systemen klafft bis zur Version 7.31 eine schwerwiegende Lücke. Diese kann ein Angreifer wie folgt ausnutzen. Zunächst prüft er ob der betroffene Dienst bei dem System aus dem Internet erreichbar ist. Sofern dies der Fall ist kann er eine anonyme Verbindung ohne Logindaten zu diesem Dienst aufbauen. Über diese Verbindung kann er dann jede beliebige Datei aus dem System lesen. Wie zuvor kann ein Angreifer damit Zugriff auf den SecStore erhalten und die administrativen Zugangsdaten auslesen.
Beispiel Hack 3: CTC Servlet (SAP Hinweis 1445998)
Diese Schwachstelle hat viel Aufsehen erhalten, selbst das US-CERT hat eine Warnung zu dieser Schwachstelle veröffentlicht. SAP selbst beschreibt die Schwachstelle mit diesen Worten:
Der Zugriff auf Servlets ist unabhängig von in der Datei web.xml definierten Sicherheitsbeschränkungen anonym über einen anderen Pfad möglich.
Konkret bedeutet dies, dass ein Angreifer lediglich eine bestimmte URL des Servers aufrufen muss. Damit kann er dann beliebige Systembefehle ausführen. Weiterhin kann er Benutzer anlegen und beliebige Berechtigungen zuweisen. Mit diesen Mitteln ist er in der Lage das System vollkommen unter seine Kontrolle zu bringen.
Besonders gefährlich bei dieser Lücke ist, dass ein Patch nicht generell das Problem behebt sondern lediglich eine bestimmte Konfigurationseinstellung deaktiviert. Diese kann jederzeit wieder aktiviert werden und damit das System erneut verwundbar machen.
Beispiel Hack 4: SQL-Injection (SAP Hinweis 2101079)
Es existiert eine SQL-Injection Schwachstelle in der Komponente SAP NetWeaver AS Java UDDI. Diese Schwachstelle kann anonym ohne Zugangsdaten ausgenutzt werden. Doch ganz so einfach ist dieser Weg dann doch nicht. Zunächst benötigt man einen Benutzernamen im System. Dieser ist für den Angriff zwingend nötig. Es gibt jedoch weitere Schwachstellen in den Systemen zu diesen Releases. Diese erlauben das anonyme Anzeigen der Benutzer im System. Hierzu reicht es aus eine von zwei möglichen URLs aufzurufen und sich die Benutzer anzuzeigen. In der Liste der Benutzer sucht man nun nach einem administrativen Account wie J2EE_ADMIN.
Mit Kenntnis des Benutzernamens kann über die SQL-Injection Schwachstelle nun auf dessen im System gespeicherten Passworthash zugegriffen werden. Dieser Hash kann aufgrund eines weiteren Fehlers in diesen Systemen sehr leicht in ein klartext Passwort überführt werden.
Damit kennt ein Angreifer nun die Zugangsdaten und erhält somit administrativen Vollzugriff auf das System.
SAP-Systeme schützen
Die Beispiele zeigen eindrucksvoll, dass es mit dem notwendigen Know-how relativ einfach ist SAP-Systeme erfolgreich aufzuspüren und zu hacken.
Abwehrstrategien scheitern vor allem an zu wenig Ressourcen und mangelndem Verständnis für Sicherheitslücken sowie dem fehlenden Know-how zur Ermittlung des tatsächlichen Sicherheitsstatus eines Systems. Mit dem werthAUDITOR von Werth IT ist es möglich die Systemsicherheit zu prüfen bevor und während die Systeme mit dem Internet verbunden sind. Damit lassen sich nicht nur die hier vorgestellten Risiken mindern, sondern auch Problemstellungen im ABAP-Coding, den Berechtigungen, der Systemkonfiguration und weiteren sicherheitskritischen Systemeigenschaften lösen. Trotz limitierter Ressourcen kann so ein dauerhaft sicherer Betrieb und die Einhaltung der Compliancevorgaben erreicht werden.
Mehr Informationen zu unserem SAP Security Service erhalten Sie hier.
Oftmals fragen sich Unternehmen welche Erfahrungen andere Unternehmen mit dem Thema SAP-Security-Audit gemacht haben. Dabei stehen meist die nachfolgenden Fragen im Vordergrund:
Gab es Komplikationen?
Welcher Nutzen ist entstanden?
Wie Aufwändig ist ein solches Projekt?
Wie geht es danach weiter?
Es gibt sehr wenige öffentliche Erfahrungsberichte von Unternehmen, die anderen Unternehmen Einblick in SAP-Security-Audits geben können. Daher möchte ich mit freundlicher Genehmigung der Queisser Pharma GmbH an dieser Stelle einen Erfahrungsbericht publizieren:
Erfahrungsbericht von Queisser Pharma GmbH & Co. KG mit dem von der OSC AG durchgeführten SAP Security-Audit
Da das Thema Sicherheit für Unternehmen essentiell und überlebenswichtig ist, lassen wir zurzeit unsere Systeme von externen Partnern auf mögliche Sicherheitslücken überprüfen. Es ist von Vorteil, die eigenen Anstrengungen bzgl. Sicherheit auch mal extern begutachten zu lassen.
Nachdem wir letztes Jahr einen Penetration-Test durchführen ließen, haben wir uns als nächstes entschlossen, unser SAP System von OSC mit dem WerthAUDITOR prüfen zu lassen.
Mit der Software wurden bei uns 660 Einzeltests durchgeführt. Hierbei ging es unter anderem um die Berechtigungen, die Datenbank, die Schnittstellen, die relevanten Themen bzgl. Wirtschaftsprüfung, kritischen ABAP-Code etc..
In der ersten Kurzübersicht konnte man sich sehr schnell einen ersten Überblick verschaffen. In einem Workshop mit OSC haben wir uns dann die Details angesehen und die erforderlichen Maßnahmen besprochen. Auf dieser Grundlage haben wir die erforderlichen Aufgaben aufgeteilt, in Punkte die wir selber durchführen können und in Maßnahmen, die wir von OSC durchführen lassen.
Durch das Security-Audit haben wir nun einen klaren Leitfaden, wie wir unser SAP System noch sicherer machen können.
Positiv überrascht hatte uns, dass wir nahezu keinen eigenen Aufwand bei der Durchführung der Tests hatten. Die breite Palette an verschiedenen Tests hat uns sehr gefallen.
Da die Tests selber ohne großen Aufwand für uns durchgeführt werden konnten und wir bei den erforderlichen Maßnahmen das Tempo je nach eigener Auslastung selber bestimmen können, ist solch ein Test jederzeit durchführbar. Wir sind sehr zufrieden mit dem Security-Audit und können es jedem empfehlen.
Als Essenz aus dem Erfahrungsbericht lässt sich folgendes festhalten:
Das Thema Sicherheit ist für Unternehmen essentiell und überlebenswichtig.
Es ist von Vorteil die Sicherheit auch mal extern begutachten zu lassen.
Der Prüfungsumfang muss umfassend sein: Berechtigungen, die Datenbank, die Schnittstellen, die relevanten Themen bzgl. Wirtschaftsprüfung, kritischen ABAP-Code etc..
Die Kurzübersicht liefert sehr schnell einen ersten Überblick, Maßnahmen lassen sich leicht ableiten.
Der Security-Audit haben gibt einen klaren Leitfaden, wie das SAP System noch sicherer wird.
Es gibt nahezu keinen eigenen Aufwand für den Kunden bei der Durchführung der Tests.
Der Test ist jederzeit durchführbar und es gibt eine klare Weiterempfehlung.
Mit der Markteinführung von HANA 2011 als zukünftige Standard-Datenbank für SAP-Systeme hat SAP ein ehrgeiziges Ziel ausgegeben. Um dieses Ziel zu erreichen wurde die In-Memory-Datenbank HANA konsquent ausgebaut. Zunächst kam mit HANA XS der Schritt zur Plattform und 2015 erschien mit S/4HANA die erste SAP-Komplettlösung auf HANA-Basis.
Damit rückt HANA immer stärker in das Zentrum einer SAP-Landschaft. In Kombination mit dem Schutzbedarf der dort hinterlegten Daten wird schnell klar, dass ein angemessener Schutz von HANA-Systemen unabdingbar ist.
Hierzu gilt es unter anderem die Netzwerksicherheit zu gewährleisten, den korrekten Umgang mit dem System Benutzer vorzunehmen, für eine verschlüsselte Kommunikation zu sorgen und die persistenten Daten sowie die Enrcyption Keys richtig zu handhaben. Ebenso müssen die Benutzer und die Authentifizierung sicher verwaltet und konfiguriert werden.
Auch das Auditing und Logging hat seinen Anteil an der Gesamtsicherheit des HANA-Systems und ist entsprechend manipulationssicher einzurichten. Aufgrund zunehmender öffentlich bekannter Schwachstellen ist ebenfalls ein effektives Patchmanagement von Nöten. Werden Eigenentwicklungen unter HANA XS erstellt, so sind die Entwicklungen „sicher“ vorzunehmen.
Es zeigt sich also die Sicherheit von HANA ist komplex.
Eine Übersicht zu dem Thema und den notwendigen Schritten finden Sie in unserer neuesten BSI-Publikation „SAP HANA Sicherheitsübersicht„
