SAP-Sicherheit ist immer noch das Stiefkind in der allgemeinen IT-Landschaft. Immer wieder wird von Sicherheits-Spezialisten, Software-Herstellern, aber auch von staatlicher Seite wie dem BSI (Bundesamt für Sicherheit in der Informationsverarbeitung) nachdrücklich diese Sicherheit der SAP-Landschaft eingefordert. Die Dringlichkeit, aber auch das Wissen über konkrete Handlungsmöglichkeiten, ist immer noch nicht in den SAP-Abteilungen und SAP-Teams der Unternehmen angekommen.
Die häufigste Ursache für den Angriff auf SAP-Systeme ist klassische Ransomware
Dafür gibt es mehrere Gründe. 80% aller Fälle, in denen SAP-Systeme gehackt wurden, sind eigentlich Kollateral-Schäden aus Ransomware-Attacken. Also der Verschlüsselung der Server über einen Angriff auf das Betriebssystem, nicht auf das SAP-System selbst. Der Schutz dagegen ist ein effektiver Schutz der Netzwerke und Betriebssysteme. Das fällt in das klassische Aufgaben-Dreieck von den Betreibern von Netzwerk und Systemen, den Systemadministratoren und den SAP-Basis-Mitarbeitern.
„Das ist Sache der Netzwerker und unser neuer CISO hat die damit beauftragt“
Dies ist ein häufiger Einwand. Aber auch in den SAP-Netzwerksegmenten des Unternehmens-Netzwerks könnte durch geeignete Maßnahmen und Härtung die Ausbreitung von Ransomware ebenso verhindert werden. Der Netzwerk-Schutz muss bereichsübergreifend, von der email über klassische IT bis zu den SAP-Systemen, organisiert werden.
Die verbliebenen 20% sind spezifische SAP-Angriffe durch Insider, die über entsprechende Authentifizierung und Autorisierung verfügen. Seien es nun verärgerte und gekündigte Mitarbeiter, Entwickler aus Offshore-Lokationen, die anfällig für Bestechung sind oder einfach SAP-Benutzer, die ihre ausgeweiteten SAP-Berechtigungen in bare Münze umwandeln wollen. Alle haben die Möglichkeit, ausgefeilte und gezielte Angriffe und Betrugskampagnen gegen die SAP-Systeme zu fahren. Hierzu muss das SAP-System andauernd geschützt und gehärtet werden, denn hier liegen klassische offene Schwachstellen in den SAP-Systemen.
Neu: Der „CEO-Fraud“ im SAP
Eine neue Variante innerhalb dieser Insider-Angriffe auf SAP-Systeme sind Fälle des auch als „CEO-Fraud“ bekannten Betrugsmusters.
„CEO-Fraud“ ist eine Betrugsmethode, bei der ein Betrüger sich als CEO oder eine andere hochrangige Person einer Organisation ausgibt, um Mitarbeiter dazu zu bringen, Geld oder vertrauliche Informationen zu überweisen oder freizugeben. Der Betrüger verwendet oft eine gefälschte E-Mail-Adresse oder eine gefälschte Telefonnummer, um glaubwürdig zu erscheinen und die Mitarbeiter zu täuschen.
Das ist auch im Zusammenhang mit SAP-Abteilungen wie Finanzen (FI) oder Human Ressources (HCM) vermehrt zu beobachten.
Aber Insider-Angriffe sind für viele SAP-Bereiche immer noch eine Frage von Rollen und Berechtigungen, also GRC-Fragen. Das ist doch aber SAP-Security?
Ein sicheres SAP-System muss auf allen Ebenen gut geschützt sein. Wo aber beginnt ein umfänglicher SAP-Schutz? Wie schütze ich nun meine SAP-Systeme gegen alle diese vielfältigen technischen wie organisatorischen Bedrohungen?
Fünf Punkte für eine SAP Security Grundsicherung
Fünf wichtige Punkte und Schritte auf diesem Weg zu einem sicheren SAP-System sollen hier zusammengefasst werden.
1. Verantwortlichkeit
Ohne eine für die Sicherheit verantwortliche Person funktioniert keine SAP-Sicherheit. Ob es nun die koordinatorischen Fähigkeiten verlangt oder die technische Umsetzung der einzelnen Projekte und Schritte, eine solche Person muss innerhalb der SAP-Organisation existieren, benannt sein und dem Aufgaben-Kanon zugeordnet sein. Daran führt kein Weg daran vorbei.
Das Unternehmen hat Budgetprobleme, diese Person zu finanzieren?
Fragen Sie mal einen Hacker, ob er Budget-Probleme hat.
Oder vergleichen Sie mehrere Millionen in Ransomware-Erpressung oder Verlust durch Betrug mit den Kosten einer solchen Stellen. Spätestens dann dürfte sich diese erübrigen.
Sicherheits-Normen wie ISO27001 setzen eine solche Position als zwingend notwendig voraus, um einmal eine Jurisdiktion zu bemühen, ohne die KRITIS-Keule zu schwingen.
Was gehört zum Aufgabengebiet einer solchen Person. „Braucht man denn überhaupt eine volle Stelle für solch eine Funktion?“ Das wird in einem separaten Blog geschildert, der alle SAP Security-Aufgaben dieser Position auflistet. Dieser ist auch als Whitepaper von uns zu bekommen
2. Monitoring
Selbst wenn kein einziges SAP-Projekt zur Sicherheit umgesetzt wird – wenigstens zeitnah sehen sollte man seine Sicherheitsprobleme, Gefährdungen und Angriffe dann schon.
Es ist schon ein Akt der Notwendigkeit, wenigstens ein Security Information Event Management System (SIEM) an das SAP-System angeschlossen zu haben Denn ein SIEM-basiertes Monitoring ist schnell zu erreichen, es erfordert kein großes Projekt, dass Abläufe ändert oder in die Infrastruktur eingreift.
Ein Hacker, der sich sicher sein kann, das niemand auf das SAP Security Audit Log blickt, wird noch ausgiebiger die SAP Systeme auseinander nehmen
Auch hier sollte man nicht darauf warten, dass der Gesetzgeber oder das BSI dies einem gesetzlich oder organisatorisch vorschreibt. Diese SAP-SIEM-Systeme gibt es von der Ausprägung Open-Source (kostenlos) bis in die Königsklasse (SAP ETD) und allen Produkt-Klassen dazwischen. Es muss nur gemacht werden, und ein Projekt erfordert zumindest Ressourcen und ein Budget. Und wer sollte da täglich darauf sehen? Das ist die benannte Person aus dem 1. Punkt. Die Kreise beginnen sich zu schließen.
3. Sicherheits- und Risikofeststellung.
Will man die ganze Wahrheit über den Zustand seines SAP-Systems wissen und bekommen, muss man nicht aufwändige Pen-Test-Kampagnen, Audits oder Analysen durchführen. In wenigen Tagen kann ein SAP Security Professional eines oder mehrere Systeme analysieren und dies zu einer Risiko-Feststellung mit entsprechenden Projektempfehlungen zusammenstellen und dokumentieren.
Hier kann im Überblick festgestellt werden, in welche Risiko-Cluster das aktuelle SAP-System fällt und was man dort an Projekten aufsetzen sollten, um eine initiale und den BSI-Richtlinien entsprechende SAP-Sicherheit zu erreichen.
Neben den technischen Aspekten sollten auch Datenschutz-Aspekte, die Einteilung der SAP-Daten in Risiko-Gruppen und Cluster (auch nach DSGVO) und der operationale Schutz ( z.B. Passwörter, Zugriffsrechte, Firefighter) berücksichtigt werden.
Alle diese genannten Aspekte einer Sicherheits- und Risikofeststellung können je nach den individuellen Anforderungen des Unternehmens variieren, aber eine erste Überprüfung dieser Punkte kann helfen, grundlegende Schwachstellen im SAP-System zu identifizieren und zu adressieren. Auch die ISO-Norm 27001 erfordert eine solche Risiko-Feststellung als Grundlage weiterer Maßnahmen.
4. Projekte und Mitigation
Welche einzelnen Projekte sollten in einer sicheren SAP-Landschafft adressiert sein, also durch eine Verantwortlichkeit festgestellt und begonnen sein? Auch die Frage, welche Projekte sollten mindestens durchgeführt sein, um eine Grundsicherung (auch gemäß BSI Richtlinie ERP 4.1) zu erreichen, müssen berücksichtigt werden.
Der Mindestumfang an SAP Security Projekten sollte folgende Themen enthalten:
- Netzwerk-Härtung / Netzwerk-Segmentierung / SMGW RFC Gateway Härtung
Die Segmentierung des Netzwerks ist zwingende Notwendigkeit gegen Ransomware-Angriffe und wird die Sicherheit der SAP-Systems dem Bedrohungsmaß entsprechend schützen. Durch die Aufteilung des Netzwerks in einzelne Segmente können beispielsweise kritische Systeme von weniger wichtigen Systemen getrennt werden sowie Produktionssysteme von Test-und Entwicklungssystemen. Angriffe durch laterale Bewegung zwischen den SAP-Systemen sollten einem Angreifer nicht möglich sein.
Zur Netzwerk-Infrastruktur gehört auch die Härtung der SAP RFC-Umgebung. Die RFC-Umgebungen sind extern aufrufbare SAP-Funktionen, ähnlich den API’s der Webwelt. Diese externen Funktionen müssen geschützt werden und nur autorisierte Aufrufe müssen möglich sein.
- Passwort-Bereinigung
Schwache Passwörter sind eines der kritischsten Einfallstore. Passwort-Diebstahl schwacher Passwörter (Stichwort: USR02 BCODE) ist eines der Haupt-Angriffsvektoren. SAP hat in der SAPNote (ccc) alles Wesentliche zusammengefasst. Das hierzu nötige Projekte sollte unbedingt aufgesetzt werden. Neugierig, wie dieser Hack zur Entschlüsselung dieser Passwörter geht? – Siehe Youtube-Vide0
- SAP Kundeneigener ABAP-Code muss überprüft werden
Es gibt viele Muster im kundeneigenen SAP ABAP Code, die gefährlich sind und als Angriffsvektoren benutzt werden können, sowohl für Ransomware als auch für Innen-Angriffe und Betrug. Deshalb muss die kundeneigene ABAP Code Basis überprüft werden. Neben dem „Get Clean“, der erstmaligen Analyse aller Programme auf kritische Muster muss es dann auch ein „Stay Clean“ Teil des Projektes geben, der über den Schutz der SAP-Transporte die Sicherheit der Systeme garantiert.
- SAP Security System Defaults
SAP, aber auch die DSAG hat eine Menge Vorschläge, wie SAP System Profilparameter aussehen sollte und was davon als „SAP Default“ bezüglich sicherer Einstellungen ist. Eine entsprechende Härtung sollte unbedingt durchgeführt werden. Wir haben hierzu einen separaten 1-Tages-Workshop, in dem so etwas erfolgen kann.
5. Werkzeuge
Alle Punkte bisher konnten ohne den Zukauf von Software und entsprechenden Sicherheits-Werkzeugen erledigt werden. Es ist nur notwendig, verantwortliche Personen und Zeot bereit zu stellen. Angesichts der aktuellen Cyber-Bedrohungslage, die sogar von der Bundesinnenministerin Faeser festgestellt wurde, sollte dies alles
Es gibt viele Lieferanten und Werkzeuge, die viele dieser essenziellen Punkte abdecken und in ihrer Gesamtheit berücksichtigen.
In unseren Projekten haben wir mit folgenden Produkten gearbeitet:
- XITING XAMS Suite
- Protect4S
- Security Bridge
- SAP Enterprise Threat Detection
- Security Hub
- Onapsis Suite
Alle diese Produkte haben ihre eigenen Vor- und Nachteile, sie adressieren zum Teil unterschiedliche
Bereiche und Sicherheitsvorgehen. Ob und wie ein Produkt sich zum Einsatz eignet, muss man gezielt untersuchen und entsprechend des Einsatzes prüfen und planen. Dies kann am Ende der einzelnen Projekte die Möglichkeit sein, SAP-Sicherheitsprojekte zu automatisieren und SAP Security langfristig im Unternehmen zu etablieren.