SAP-Sicherheit: Gefahren­quelle Basisadministration

Der Datenschutz in SAP-Systemen zählt zu den dringendsten Sicher­heits­auf­gaben im Finanzsektor. Allerdings haben Tests bei ver­schied­enen Finanzinstituten  gravierende Schwachstellen im Bereich der SAP-Basisadministration offenbart.  

von Thomas Kastner,
Geschäftsführer Virtual Forge

Mit den verschärften Mindestanforderungen der BaFin an das Risikomanagement (MaRisk-Novelle 2016) und der 2018 in Kraft tretenden EU-Datenschutzgrundverordnung (EU-DSGVO) wächst der Druck auf die Finanzdienstleister, auch ihre SAP-Daten vor unbefugten Zugriffen zu schützen. Einer Studie des Ponemon Institutes zufolge zählt diese Branche zu denen, die am meisten zahlen müssen, wenn es um die Folgen von Datenverlusten geht. So kann der Abfluss von Kundendaten hohe Schadensersatzforderungen nach sich ziehen, wenn Cyber-Kriminelle damit etwa Zugriff auf Girokonten erhalten.

Ein Beispiel dafür ist die britische Tesco-Bank, die ihren Online-Banking-Kunden im vergangenen Herbst rund 2,5 Millionen Pfund erstatten musste, die bei Hackerangriffen gestohlen worden waren. Zu den finanziellen Schäden kommt meist ein schwerer Imageverlust hinzu.”

Doch können unerwünschte Datenabflüsse nicht nur durch böswillige Hacker, sondern auch durch eigene Mitarbeiter verursacht werden, wie etwa Administratoren von SAP-Geschäftsanwendungen und -systemen. Obwohl es auch aus Datenschutz- und Compliance-Gründen erforderlich ist, den Zugriff zum Beispiel für SAP-Basisbetreuer zu begrenzen, sieht die Realität oft anders aus. So wurden bei SAP-Sicherheitstests in Finanzinstituten Schwachstellen identifiziert, die den SAP-Basisadministratoren weitreichende Möglichkeiten eröffneten, an sensible Kundendaten heranzukommen.

Lücken in DBACOCKPIT und DB02

Die Sicherheitslücken wurden in DBACOCKPIT und DB02 entdeckt, zwei zentralen Transaktionen, mit denen die SAP-Datenbanken überwacht, gesteuert, konfiguriert und verwaltet werden können. Die SAP-Basisadministratoren führen darüber zahlreiche Basisfunktionen aus, wie die Überprüfung von Systemstatus und Betriebsarten, Tabellenerweiterungen oder die Indexpflege und -aktualisierung von Tabellen.

Beide Transaktionen enthalten den SQL Command Editor, der über so genannte Open SQL-Befehle den direkten Zugriff auf funktionale Tabellen erlaubt.”

Damit kann auch auf geschäftskritische Informationen zugegriffen werden, wie Personal- und Finanzbuchhaltungsdaten oder Passwort-Hashes.

SAP stellt für den SQL Command Editor zahlreiche Sicherheits-Patches zur Verfügung, die unbedingt beachtet und eingespielt werden sollten. Um den Zugriff auf die SAP-Daten zu steuern, hat SAP zusätzlich eine neue Berechtigung ausgeliefert (S_TABU_SQL). Mit ihr können die Finanzinstitute festlegen, welche Mitarbeiter auf welche SAP-Daten zugreifen dürfen.

Darüber hinaus gibt es im SQL Command Editor eine Tracking-Funktion, mit der jedes Kommando – ob berechtigt oder unberechtigt – geloggt wird. Werden diese Log-Daten zudem in ein SIEM-System (Security Information and Event Management) übertragen und dort analysiert, erhalten Unternehmen einen Überblick über sämtliche erfolgten Zugriffe. Durch Monitoring und Alerting kann möglichem Missbrauch zeitnah entgegengesteuert werden.

Verschlüsselte Passwörter geknackt

Wird der SQL Command Editor jedoch nicht mit den erforderlichen Sicherheits-Updates versorgt, kann dies fatale Auswirkungen haben, wie SAP Penetration-Tests von Virtual Forge zeigten. Nachdem es den Testern gelungen war, in der Datenbank eines SAP-Systems die USR02-Tabelle mit den verschlüsselten Passwörtern auszulesen, konnten diese mit einem Password-Cracker-Tool geknackt werden. Danach meldeten sich die Tester am SAP-System an und griffen dort problemlos auf dieselben Funktionen zu, für die die einzelnen Anwender berechtigt waren. Bösartige Attacken hätten bis zur vollständigen Kompromittierung des SAP-Systems führen können, was gerade für Unternehmen aus der Finanzbranche weitreichende Konsequenzen zur Folge haben könnte.

Um dies zu verhindern, sollte jedes SAP-Anwenderunternehmen regelmäßig die Security Notes für den SQL Command Editor einspielen.”

Zudem empfiehlt es sich, mindestens einmal im Jahr ein Upgrade vorzunehmen und dabei die aktuellen Support Packages zu implementieren, mit denen SAP die Kunden mit Fehlerbereinigungen und gesetzlich vorgeschriebenen Software-Anpassungen versorgt.

Know-how spezialisierter Dienstleister nutzen

Doch zeigt die Praxis, dass die meisten Finanzinstitute über keine eigenen SAP-Sicherheitsteams verfügen. Daher empfiehlt es sich, mit dem regelmäßigen Einspielen der Security Patches spezialisierte Dienstleister zu beauftragen, die das nötige Sicherheits- und SAP-Know-how kombinieren: vor allem Erfahrungen in der Umsetzung von Patches, Verständnis für unterschiedliche SAP-Releases und Upgrade-Verfahren sowie Kompetenzen im Bereich der Gefahrenerkennung („Threat Detection“) und Prävention.

Der Beratungspartner sollte dem Kunden helfen, die Kritikalität der Sicherheits-Patches zu bewerten und die erforderlichen Tests auszuwählen, damit es beim Einspielen der Patches zu keinen Programm- und Anwendungsfehlern kommt. Da die selektive Überprüfung aufwändige Regressionstests überflüssig macht, spart der Kunde Zeit und Kosten.

SAP-Systemkonfiguration auf Fehler scannen

Ergänzend bietet sich im Bereich der Prävention der Einsatz von Werkzeugen zur Erkennung und Korrektur von Fehlern in kundenindividuellen SAP-Systemkonfigurationen an. So lassen sich damit alle Anwender ermitteln, die umfangreiche Berechtigungen zur Ausführung des SQL Command Editors (DB02, DBACOCKPIT) und zugehöriger Tabellenberechtigungen (S_TABU_SQL) haben.

Hat ein Kunde seine SAP-Systeme an den SAP Solution Manager angeschlossen, können mit diesen Werkzeugen automatisch Sicherheitslücken und Schwachstellen identifiziert werden. So lässt sich auch für alle SAP-Systeme regelmäßig überprüfen, ob alle erforderlichen Security Patches eingespielt wurden, die die Sicherheitslücken im SQL Command Editor vollständig beseitigen.aj