Foto: HQuality - shutterstock.com
SAP-ERP-Software ist gänzlich auf die digitale Optimierung laufender Geschäftsprozesse ausgerichtet und wird heute von mehr als 440.000 Unternehmen weltweit eingesetzt. In der Regel handelt es sich um börsennotierte Konzerne und die viel zitierten Hidden Champions. Dementsprechend groß ist auch das Interesse von Cyberkriminellen an den Systemen und den von ihnen verarbeiteten Daten. Aus den Informationen lassen sich die wichtigsten Kennzahlen der Unternehmen ableiten, darunter nicht zuletzt Innovationen und Patente aller Art.
Leider ist SAP-Sicherheit ein häufig isoliert betrachteter oder sogar blinder Fleck in der zentralisierten Cyber-Sicherheitsüberwachung vieler Unternehmen. Der Vorgang lässt sich daher folgendermaßen definieren: SAP Security hat die Aufgabe geschäftskritische Systeme zu schützen, damit sich Unternehmen auf eine effektive Geschäftsabwicklung verlassen können.
Vor allem aber ist das ERP-System eine eigene IT-Infrastruktur mit eigenen Anforderungen an die IT-Sicherheit, die Außenstehenden wie ein Buch mit sieben Siegeln vorkommen kann. Wichtig festzuhalten ist, dass es die Daten sind, die den Wert eines SAP-Hacks ausmachen. Diese müssen vor unberechtigten Zugriffen von außen aber auch innen abgesichert werden. Beispiele für kompromittierte SAP-Systeme gibt es nur wenige, die publik geworden sind. Ein Blick auf die wachsende Anzahl der Anbieter von SAP-Sicherheit wirft jedoch ein Licht auf die wachsende Bedeutung dieser Teildisziplin der IT-Sicherheit. In diese Disziplinein spielen neben Applikationssicherheit auch die Infrastruktur-, Netzwerk-, Betriebssystem- und Datenbanksicherheit hinein.
Der wohl wichtigste Faktor, auch aufgrund der Schnittstellenproblematik, die SAP von Natur aus innewohnt, ist die Codesicherheit. Vor allem kundenspezifische Codes sind fehleranfällig und damit ein Sammelbecken von Schwachstellen, vor allem Zero Day-Schwachstellen, die nur wenigen Insidern bekannt sind. Zum einen garantiert das einen gewissen Schutz vor Angriffen von außen, erhöht jedoch zum anderen das Risiko von Innentätern.
Lesetipp: Was ist ein Zero Day Exploit?
- Mangelhafte Code-Qualität
Probleme mit der Qualität des Codes stehen nicht ohne Grund auf Platz 1 dieser Liste. In einer Studie zur Softwaresicherheit in Unternehmen hat der Security-Anbieter Veracode festgestellt, dass bei mehr als der Hälfte aller getesteten Anwendungen die Code-Qualität ungenügend ist. Dieses Ergebnis ist erschreckend – und gleichzeitig ein Aufruf an alle Branchen, sichere Coding-Verfahren einzusetzen. Denn je später eine mangelhafte Qualität des Quellcodes festgestellt wird, umso aufwändiger wird es, sie zu verbessern – und umso länger ist die Anwendung angreifbar. - Kryptographische Probleme
Sobald es darum geht, wichtige Informationen, wie Passwörter, Zahlungsinformationen oder persönliche Daten zu speichern oder weiterzugeben, kann man davon ausgehen, dass dies auf die eine oder andere Weise auf verschlüsseltem Wege geschieht – damit diese widerstandsfähig gegen Manipulation und unbefugtes Lesen sind. 87 Prozent der Android Apps und 80 Prozent der iOS Apps haben mit Verschlüsselungsproblemen zu kämpfen. Deshalb sind sie ein so beliebtes Ziel für Hacker. - CRLF Injections
Grundsätzlich sind CRLF Injections eine Art Tor zu größeren Angriffen. Durch das Injizieren einer CRLF-Zeichensequenz (=Zeilenumbruch) an einer unerwarteten Stelle können Angreifer Anwendungsdaten ändern und die Ausnutzung von Schwachstellen ermöglichen. Darunter fallen Website-Defacement, Cross-Site Scripting, Hijacking des Webbrowsers und viele weitere. Gerade Android- und Java-basierte Anwendungen sind hiervon betroffen. Sie weisen zu 79 Prozent (Android) und zu 75 Prozent (Java) CRLF Injections auf. - Cross-Site-Scripting
Eine weitere Attacke ist das Cross-Site-Scripting (auch als XSS bekannt). Sie tritt dann auf, wenn Angreifer Bereiche einer Website missbrauchen, die rund um dynamischen Content gebaut sind, Codes ausführen, die Nutzerkonten übernehmen oder Webbrowser fernsteuern. Cross-Site Scripting wird vor allem bei Formularen ein Problem, die ein gemeinsames Kodierungssystem mit der Eingabe von Fragezeichen und Schrägstrichen erlauben.<br /><br />Anwendungen, die in Web-Skriptsprachen geschrieben wurden, sind häufiger von Schwachstellen wie Cross-Site Scripting oder SQL Injections betroffen als Anwendungen basierend auf .NET oder Java. So beinhalten 86 Prozent der PHP-basierten Anwendungen mindestens eine Cross-Site-Scripting-Schwachstelle und 56 Prozent mindestens eine SQL Injection. - SQL Injections
Obwohl sich SQL Injections auf dieser Liste weiter unten befinden, sind sie aufgrund ihrer leichten Ausführbarkeit doch eine der häufigsten, auftretenden Sicherheitslücken. Angreifer platzieren SQL-Abfragen in entsprechende Eingabebereiche und versuchen so, über die Anwendung, die den Zugriff auf die Datenbank bereitstellt, eigene Befehle einzuschleusen. Dadurch ist es Angreifern möglich, Informationen einzusehen, Daten zu verändern und sogar zu löschen sowie die Kontrolle über den Server vollständig zu übernehmen. - Directory Traversals
Directory Traversals sind beängstigend, da weder viel Wissen noch Werkzeuge nötig sind, um damit großen Schaden anzurichten. Im Prinzip kann jeder mit einem Webbrowser und Hacking-Grundkenntnissen durch die Manipulation von Pfadangaben ungeschützte Seiten hacken, so Zugang zu größeren Dateisystemen erlangen und dort nützliche Informationen wie Passwörter, kritische Dateien oder sogar Seiten- und Anwendungsquellcodes abgreifen. Gemessen an den gängigsten Programmiersprachen sind 47 Prozent aller Anwendungen von Directory Traversals betroffen. - Unzureichende Datenvalidierung
Simpel gesprochen lässt sich sämtlicher Input, den Anwender im System abspeichern, kontrollieren und verwalten, unter der Voraussetzung, dass die Daten, die in das eigene Netzwerk kommen, entsprechend validiert und "sterilisiert" werden. Ist dies nicht der Fall, entstehen eine Reihe an Sicherheitsrisiken, die bösartigen Angreifern unter anderem ermöglichen, Daten auszulesen und zu stehlen sowie Sitzungen und Browser-Aktivitäten fremdzusteuern.
SAP-Systeme - die Bedrohungslage
Unternehmen müssen ihre SAP-Systeme vor den unterschiedlichsten Bedrohungsszenarien schützen. Die wohl wichtigste Motivation ist Betrug. Die kopierten Daten sind so wertvoll, dass sie bei der Konkurrenz oder im Darknet Höchstpreise aufrufen. Gefahr droht darüber hinaus nicht nur extern, wo Angriffstools für SAP-Systeme bereits für 600 US-Dollar angeboten werden, sondern auch von innen.
Mahnende Beispiele sind die Recon-Schwachstelle CVE-2020-6287 oder die 10Kblaze-Exploits. Mit der fortschreitenden Professionalisierung cyberkrimineller Gruppierungen nimmt zudem die Bedrohungslage für SAP-Systeme zu, denn der Preis für die Daten steigt und somit wird es für Cyberkriminelle lukrativer sich mit den Systemen zu beschäftigen und nach Schwachstellen zu suchen sowie Exploit Kits zu entwickeln. Ein Blick auf die Tools und Methoden der Angreifer zeigt, dass letztlich fast alle Bedrohungen, die auch auf reguläre IT-Systeme abzielen für SAP-Systeme angepasst werden können.
Lesetipp: Cybercrime als Service - So günstig ist ein Hack im Darknet
IT-Sicherheitsfachleute müssen die Datenintegrität sicherstellen, unberechtigte Zugriffe identifizieren, Datenlecks feststellen und ein zentralisiertes Sicherheits-Monitoring einführen. Darüber hinaus sollten kontinuierliche und automatisierte Audits durchgeführt werden. Oftmals werden allerdings die SAP-Systeme von vielen Unternehmen nicht von den IT-Sicherheitsfachleuten betreut oder sind allein auf die Tools der ERP-Anbieter angewiesen. Dies erhöht das Risiko von Angriffen und macht ERP-Systeme wie SAP zu einem Hauptziel für Gegner.
Berechtigungsmanagement und Rollenvergabe
Wer seine SAP-Sicherheit in den Griff bekommen will, der muss sich mit diversen Teilbereichen der IT-Sicherheit auseinandersetzen. Zum einen geht es darum Rollen und Berechtigungen laufend zu überprüfen. Berechtigungskonzepte sind in SAP standardmäßig festgelegt, lassen sich jedoch kundenspezifisch verändern. Besonders wichtig sind Zuordnungen von Berechtigungskombinationen, die sogenannte Segregation of Duties (SOD). Kritische Berechtigungskombinationen sollten im besten Fall gar nicht, sondern nur sogenannte Notfallbenutzer erlaubt werden.
Leider können Rollen und Berechtigungen mit SAP-Standardmitteln erteilt und somit SAP-basierte Lösungen der zentralen Nutzer- und Rechtevergabe kompromittiert werden, was an der IT-Sicherheit vorbeiläuft. Deshalb müssen Kontrollen eingeführt werden, um eben dies zu verhindern. Im besten Fall läuft dies automatisiert ab und nimmt einen Testkatalog als Grundlage. Einen solchen aufzusetzen, bedarf umfassender SAP-Kenntnisse, nicht nur in diesem Bereich, sondern zudem in den grundlegenden Geschäftsprozessen. Geprüft werden müssen Rollen und Berechtigungsprofile.
Wenn ein Benutzer mehrere Rollen zugewiesen bekommt, könnte dies einen SOD-Konflikt auslösen. Hier steht die Aufgabe an, nachzusehen, welche Rollen das Problem auslösen. Die SAP-Transaktion SUIM (Solutions for User Identity Management) und deren API ermöglichen eine Überprüfung von Berechtigungskombinationen.
Ein weiterer wichtiger Punkt beim Thema Berechtigungen und Rollen ist die sichere Einrichtung der Server. Die SAP-Sicherheitsfachleute konfigurieren den Server nach Sicherheitskriterien, aktivieren die Sicherheitsprotokollierung und kontrollieren die Kommunikation und Datensicherheit innerhalb des Systems. Hierfür eigenen sich automatisiere Monitoring-Tools, die nach der Einrichtung kontinuierlich prüfen, ob alle Systemeinstellungen sowie Berechtigungs- und Rollen-Vorgaben eingehalten werden.
Regelmäßige Audits helfen dabei die eingeführten Kontrollen auf dem Stand der Technik und Bedrohungslage zu halten. Last but not least sollte ein Notfallkonzept erstellt werden, um im Falle einer Kompromittierung, einer Schwachstelle oder eines Fehlers angemessen schnell reagieren zu können.
Patchen ist eine Kür
Wie bei allen ERP-Systemen, bedeutet regelmäßiges Patchen einen enormen Aufwand. Jedes Update bedeutet in gewisser Hinsicht die Unterbrechung sensibler Geschäftsprozesse. Abseits der normalen Aktualisierungen häufen sich in den letzten Jahren darüber hinaus solche zur SAP-Sicherheit: Der Grund sind Sicherheitsverstöße. Das Patch-Management muss also gut geplant werden.
Oftmals bleiben Updates auch einfach aus, so dass schwere Sicherheitslücken in vielen Systemen weltweit bestehen bleiben, ohne dass sich jemand um deren Behebung kümmert. Darüber hinaus bestehen zahlreiche Zero-Day-Schwachstellen, die wie eingangs erwähnt durch Anpassungen entstanden sind und deshalb nicht immer dokumentiert wurden.
Lesetipp: Vulnerability Management - Patchen allein istnicht genug!
Transaktionsüberwachung
Transaktionen und Funktionsmodule gehören zu den grundlegenden Bestandteilen eines SAP-Systems, viele sind auch remote verfügbar, um die Kommunikation mit dritten Systemen zu gewährleisten. Über APIs lassen sich Konten mit Berechtigungen anlegen, um sie aus der Ferne zu nutzen. Weitere Funktionsmodule laden dann weitere Daten aus dem System oder manipulieren sie im schlechtesten Fall. Die Berechtigungsvergabe ist für diesen Vorgang so wichtig, weil sie die Möglichkeit Transaktionen und Funktionsaufrufe vorzunehmen einschränken kann. Mit einer zentralen Überwachung gelingt zudem die automatisierte Überprüfung von kritischen Transaktionen, RFC-Modulen und SAP-Programmen sowie wer oder was auf diese zugreift.
Codesicherheit
Die Sicherheit des Codes ist für die SAP-Sicherheit von zentraler Bedeutung. ABAP (Advanced Business Application Programming, die Programmiersprache von SAP)-Code sollte möglichst unter dem Gesichtspunkt von Security by Design programmiert werden, ist aber bislang Aufgabe der Entwickler und nicht der IT-Sicherheit. Der Code wird zusammengestellt und von den Entwicklungssystemen zu den Produktivsystemen transportiert. Eine Qualitätsprüfung des Codings hinsichtlich der Sicherheit findet dabei oftmals nicht statt. Leider bieten SAP-Systeme auch Möglichkeiten der Code-Injektion. Code kann sogar zur Laufzeit generiert und ausgeführt werden. Im Zuge aktueller Diskussionen um Supply-Chain-Attacken eignen sich die Transporte dieser Codes, um Malware unentdeckt in SAP-Systeme einzuschleusen. Bordmittel von SAP wie der Code Inspector mit Modulen wie dem Code Vulnerability Analyzer unterstützen bei der Analyse.
Systemeinstellungen
Die Systemeinstellungen sind eine weitere Möglichkeit, derer sich Angreifer zu Nutze machen könnten. Auf der Datenbank- oder auf der Transaktionsebene lassen sich Einstellungen an den SAP-Profilparametern vornehmen, die in Dateien abgelegt sind. Kommt es dann zu einem Rollout muss ein bestimmtes Regelwerk eingehalten werden, das dem Betriebshandbuch der SAP-Basis folgt. Dort ist festgelegt, wie Sicherheitseinstellungen gewählt, Zugriffe gewährt oder verweigert werden und welche Kommunikation eines SAP-Systems zulässig ist. Die Sicherheitseinstellungen werden dann über verschiede Betriebs-, Datenbank-, und Anwendungsschichten hinweg konfiguriert, was leider allzu oft fehleranfällig ist. Zudem sind SAP-Standards oft nicht ausreichend.
RFC-Gateway-Konfiguration
Beim Thema Konfiguration ist zudem das RFC-Gateway, die SAP-interne Firewall, ein wichtiger Baustein innerhalb der SAP-Sicherheit. Das Gateway muss wie jede Firewall genau konfiguriert (RegInfo, SecInfo) werden. Nur dann lassen sich unberechtigte Zugriffe auf Systeme und Anwendungen vermeiden. Die DSAG (Deutsche SAP-Anwendergruppe e.V.) hat Best Practices und Leitfäden entworfen, die eine Reihe von praxistauglichen und sicherheitsorientierten Einstellungen sowie Testkataloge enthalten.
Sicherheits- und Lesezugriffsprotokolle
Das A und O für ein zentrales Sicherheits-Monitoring sind die Sicherheitsprotokolle. Sie müssen gleichzeitig eingeschaltet und kontrolliert werden.
Zu den wichtigsten Protokollen gehört das SAP-Sicherheitsauditprotokoll (SM20). Es enthält eine Reihe von sicherheits- und auditrelevanten Ereignissen.
Weitere wichtige Protokolle sind das Änderungsprotokoll (SCU3) von Datenbanktabellen und die Änderungsbelege von Benutzern und Business-Objekten (SCDO).
Das SAP RFC-Gateway Log SMGW enthält die Protokolle des RFC-Gateways und darüber hinaus existieren Protokolle des SAP Internet Communication Managers und des Web Dispatchers.
In dem SAP Read Access Log (SRAL) wiederum werden Lese- und Schreibzugriffe auf bestimmte Felder von Transaktionen, Datenbanktabellen oder Tabellenfelder gespeichert. Dieses Protokoll wird über die Transaktion SRALManager verwaltet und ist für die Erfüllung der Bestimmungen der DSGVO wichtig, denn es zeigt auf, wer zu welchem Zeitpunkt auf welche Daten zugegriffen hat.
Für ein funktionierendes Sicherheits-Monitoring ist die Konfiguration dieser Lesezugriffsprotokolle und deren Analyse ein wichtiger Baustein. Automatisierte Regeln, die bei der Auswertung der Protokolle helfen, unterstützen die SAP-Sicherheitsfachleute bei der Kontrolle der Lesezugriffe.
Automatisierung für mehr SAP Security
Wer sich mit der SAP-Sicherheit beschäftigt, muss sich mit ähnlichen Bedrohungen und Risiken auseinandersetzen wie bei allen anderen IT-Systemen auch, jedoch die IT-Sicherheit in einer ungleich komplexeren Umgebung organisieren. Dieses Missverhältnis wird durch den Umstand der vielen Schnittstellen- und Konfigurationsprobleme verstärkt und zwingt die Fachleute zunächst zu SAP-Spezialisten zu werden, bevor sie sich an die Härtung der SAP-Systeme wagen können. Doch es gibt ein Licht am Ende des Tunnels, denn mit Automatisierung lässt sich viel Sichtbarkeit erreichen, was sogar für bessere Compliance sorgen kann. (bw)