In der Ecke Wissenswertes versuchen wir ihnen das Thema SAP Security näher zu bringen. Sie als Kunde bekommen dadurch idealerweise neue Ideen und erhalten einen Einblick in unsere Arbeit.
Systeme zu hacken erfordert viel Fachwissen, Menschen zu manipulieren und Einfühlungsvermögen. Jede noch so ausgefeilte Sicherheitstechnik wird schlussendlich von Menschen bedient und kann mittels „Social Engineering“ umgangen werden. Das Können liegt darin, den Menschen richtig einschätzen zu können. Führt eher ein autoritäres Auftreten gegenüber dem Opfer oder das Auslösen seiner Hilfsbereitschaft zum Erfolg, liegt auch am Angreifer. Ich stütze diese These auf eigene Erfahrungen. Zum Start meiner Karriere hatte ich recht gute Kenntnisse im SAP-Umfeld, was ungewöhnlich dergestalt war, dass man damals nur schwer Zugang zu einem SAP-System hatte.
Als junger, naiver Mensch wurde ich nicht als Bedrohung oder Konkurrent wahrgenommen. Im Gegenteil: Der väterliche Admin gab dem jungen Praktikanten damals eine leicht lösbare Aufgabe und da ein wichtiger Admin wichtige Dinge zu tun hat, meldete er sich, für den Praktikanten mit seinem Account an.
Bei einem SAP - Account mit Debugging Change Berechtigungen und ohne einem ETD System braucht ein Angreifer 30 Minuten unbeobachtet, um in Zukunft nicht mehr auf den Firmenaccount angewiesen zu sein. Damals war ich Programmierer und Stolz auf das entgegengebrachte Vertrauen. Später wiederholten sich ähnliche Fälle in meinem Berufsleben, bis ich mich selbst dabei ertappte, einen schweren Fehler zu machen und nur aufgrund eines Schubladendenkens zu handeln: Mein Fehler damals war meine Arroganz.
So hart es klingt, nach meiner Erfahrung verwechseln systemnahe Admins ihr Können mit Berechtigungen. Nur weil ich es darf, ist es nicht richtig. Zu schnell ist in einer hektischen Phase die schnelle Lösung gewählt und ein Testaccount angelegt, mit weitgehenden Rechten. Man nutzt schnell die gegebenen Möglichkeiten und baut bewusst oder unbewusst Hintertüren ein. Das schlechte Gewissen, beruhigt man mit, „ich weiß ja, was ich tue“.
Ein weiterer menschlicher Bug, der genutzt werden kann, ist seine Autoritätsgläubigkeit. Dazu braucht es nicht das direkte Gespräch, es reichen schon gut gemachte Mails. Versenden Sie eine gefakte Massenmail an ihre Belegschaft, in welcher diese aufgefordert wird, sich mit ihrem SAP-Account an einer externen Webseite zur Mitarbeiterbefragung anzumelden.
Wiederholen Sie diese Attacke und prüfen Sie dadurch die Lernkurve.
Die Lösung sind Awareness-Schulungen und eine Abfrage des Erlernten durch simulierte Angriffe.
Die Informationsübermittlung vom Menschen zum SAP-System erfolgt an stationären Geräten über Tastatur und Maus. Passwörter werden über die Tastatur eingegeben, somit ist knapp 40 Jahre nach der Einführung des ersten PCs der Angriff der Hardware immer noch ein erfolgversprechender Weg. Ein Mittel ist es, einen Keylogger zu nutzen, der unauffällig in Form eines USB–Sticks zwischen Tastatur und Computer befestigt wird oder als Software installiert wird.
Es reicht aber womöglich schon der Blick über die Schulter des Opfers, denn es finden nicht alle Angriffe aus der „Cyber“ Welt statt. Die reale Gefahr sitzt womöglich im gleichen Büro. „Sichere Passwörter“ sollen nach gängiger Vorstellung mindestens 8 Zeichen lang sein, Sonderzeichen haben, Groß- und Kleinbuchstaben beinhalten, 4-mal im Jahr geändert werden, nach drei Fehlversuchen gesperrt werden, in jedem System unterschiedlich sein usw.
Solch „sichere Passwörter“ führen in der Praxis dazu, dass die Nutzer die Passwörter irgendwo extern notieren, die Eingabegeschwindigkeit aufgrund der Komplexität zum Mitlesen einlädt und die Hotline beschäftigt wird.
Wirklich sichere Passwörter sind Einmalpasswörter oder eine Zweifaktorauthentifizierung. Dies ist auch bei SAP-Systemen möglich, allerdings ist das viel schwieriger, als die Passwort Policy zu ändern.
Wissen Sie, welche SAPGUI Version in ihrem Unternehmen genutzt wird? Kennen Sie das Feature, durch die SAPGUI Clientanwendungen, z.B. ihr Outlook zu steuern? Wussten Sie, dass Sie SAP - Funktionsbausteine z.B. mittels Excel -VBA aufrufen können? Der Browser oder die SAPGUI sind nicht die einzigen Wege, mit einem SAP-System zu sprechen.
Eine weitere Möglichkeit, SAP anzugreifen, ist die Nutzung der verschiedenen Kommunikationswege. SAP-Systeme verwenden zur Darstellung des Ergebnisses Graphical User Interfaces in der Kurzform GUIs. Während neuere Anwendungen auf Browsertechnologien setzen, ist das Brot- und Buttergeschäft immer noch SAPGUI basierend. Standardmäßig kommuniziert der Client mit dem Backend unverschlüsselt. Das eingesetzte DIAG-Protokoll ist zwar nicht öffentlich dokumentiert, die Zeichenketten werden aber unverschlüsselt übertragen.
Dies bedeutet, dass die Anmeldedaten zwar je nach Einstellung komprimiert, aber dennoch lesbar über das Netz übertragen werden. Gängige Sniffer bieten Plugins an, um die Credentials mitzulesen.
5. Applikationsserver
SAP-Systeme sind hochkomplexe Systeme, die aus mehreren Tausend quellcodeoffenen Programmen, Klassen und Funktionsbausteinen bestehen. Fluch und Segen der quellcodeoffenen Systeme liegen eng beieinander. Die prominentesten Befürworter quellcodeoffener Systeme sind die Schöpfer des Linux Betriebssystems.
Unabhängig der vielen Vorteile bietet für einen Angreifer die quellcodeoffene Software einen riesigen Vorteil, wenn er über ABAP-Kenntnisse und einen Zugriff auf das OSS verfügt. In dieser riesigen Fehlerdatenbank sind tausende Fehler von der SAP dokumentiert und erklärt. Sobald der Fehler veröffentlicht wird, läuft die Zeit gegen die Administratoren, die einen Change des Systems beantragen und weitere Abhängigkeiten prüfen müssen. Die Vorteile des Angreifers sind die Zeit, und dass er den Fehler vom Softwarehersteller erklärt bekommt. Verfügt er über ein vergleichbares System, kann er prüfen, ob er vergleichbare Fehler in anderen Bereichen findet, die noch nicht gefixt wurden.
Um die Flut der Fehlerkorrekturen für die Administratoren überschaubar zu machen, gibt es verschiedene Tools. Das SAP Recommendation, basierend auf dem Solution Manager, vergleicht das Kundensystem mit der SAP OSS Datenbank und zeigt an, welche Hinweise fehlen und wie hoch deren Kritikalität ist.
Zudem gibt es die Funktion des EWA-Berichts (Early Watch Alert). In diesem durchaus managementtauglichen Wordbericht werden offensichtliche, kritische Fehler des SAP-Systems aufgelistet und auch auf Performanceprobleme aufmerksam gemacht.
Schlussendlich ergibt sich der Nutzen der Tools nur dann, wenn ein funktionierendes Changemanagement und eine Governance vorhanden ist. Der Aufwand, eine aktuelle RACI Matrix vorzuhalten, ist erheblich. Die Forderung „Security First“ steht im ständigen Konflikt zum Geschäftsprozess.
Aus Sicherheitsgründen empfiehlt es sich, auf Applikationsservern und Datenbankservern die Software sortenrein zu installieren und keine zusätzliche Software zu installieren. In der Praxis wird man aber Zusatzinstallation finden, wenn man z.B. zur PDF-Verarbeitung Hilfsprogramme wie das pdftoolkit nutzt. Diese speziellen Tools unterliegen selten einem Changemanagement. Setzt sich der Administrator durch und die Tools werden auf anderen Servern installiert, sieht er sich dennoch mit dem größten Sicherheitsrisiko eines Drittanbieters konfrontiert => dem Betriebssystem.
Ob nun Microsoft, Linux oder Unix. Dass der Basisadministrator auch ein Experte für die Betriebssysteme ist, ist eher selten. In großen Firmen ist die Verantwortung daher geteilt. Es gibt also unterschiedliche Verantwortliche für das Betriebssystem, die Datenbanken und der Basisadministration. Ein Betriebssystem Patch führt fast immer zu einem Neustart, zumindest bei den Windowssystemen. Und somit zu einer Störung des SAP Services.
Man wird die Patche nicht ohne Test in die Produktionssysteme einspielen wollen. Es werden daher zunächst die Entwicklung und Trainingsmaschinen gepatcht und getestet und später die Produktion. Läuft parallel eine Wartung der Datenbank oder der eigentlichen SAP Software, behindern sich die Wartungen gegenseitig.
In größeren Firmen kommt man daher an einem funktionierenden Changemanagement nicht vorbei.
Selten, dafür medientauglich aufgemacht, werden die Angriffe gegen Hardware gemeldet. Ich habe schon Computer auf dem Rolltisch aus der Firma geschoben, ohne angehalten worden zu sein. Der Pförtner hat mir sogar die Tür aufgehalten.
Die Angriffsweise bei der Kommunikation zwischen Applikationsserver und Datenbank ist eine Ähnliche wie zwischen Präsentations- und Applikationsserver. Auch hier gilt es, den Netzwerkverkehr mitzuschneiden. Je nach Datenbank gibt es verschiedene Verschlüsselungsmethoden. Microsoft bietet eine zertifikatsbasierte Lösung an, die aber bewusst aktiviert werden muss.
Der Basisschutz lautet, dass der Applikationsserver und die Datenbank in einem eigenen Netzwerkbereich stehen, damit die Snifferattacken nicht greifen können.
Die Datenbank bzw. ihr Inhalt ist das eigentliche Ziel eines Angreifers, wenn er es auf die Integrität oder die Vertraulichkeit der Daten abgesehen hat.
Bei nicht Hana-Systemen gibt es mehrere Datenbanksysteme, die verwendet werden können. Jede dieser Datenbanken musste in der Vergangenheit den einen oder anderen Security-Bug zugeben. Das System sollte daher regelmäßig aktualisiert werden und die Daten verschlüsselt vorliegen, damit nicht der Zugriff auf das Filesystem schon ausreicht, um sich eine Kopie zu erstellen. Im Abschnitt Datensicherung führe ich aus, warum das in den meisten Unternehmen nicht gemacht wird.
Das Leben eines Datenbankadministrators ist im SAP Umfeld sehr einfach. Nach der erstmaligen Installation und Einrichtung der Sicherungen ist faktisch nichts mehr zu tun. Gelegentliche Deadlocks bei Datenbankzugriffen können über Neustarts gelöst werden, Optimierungen führen die Systeme selbstständig aus bzw. lassen sich wiederkehrend einplanen. In vielen Firmen übernimmt der SAP Basisadministrator daher die Rolle des Datenbankadministrators. Sollte man nun als Angreifer auf ein gepatchtes System treffen, das auch netzwerkseitig nicht angreifbar ist, muss man über ein wenig SQL- Kenntnis verfügen und den Umstand nutzen, dass alle Berechtigungsprüfungen SAP seitig erfolgen, um sein Ziel zu erreichen. Dies bedeutet, dass nur ein Kommunikationsuser, der alle Daten der Instanz selektieren und ändern darf, in der Datenbank existiert. Anders formuliert: Der SAP User HEUP existiert nicht als Anwender auf der darunterliegenden Datenbank. Ob er die Kundentabelle ändern darf, entscheidet die Logik des SAP Systems. Die Datenbank erhält den Updatebefehl für die KNA1 vom Kommunikationsuser der SAP ID und nicht vom User Heup.
Bei einem Kunden wurde folgender Angriff simuliert:
Bei der MSSQL Datenbank gibt oder gab es ein kommandozeilenbasiertes Tool für Abfragen an die Datenbank namens SQLCMD. Mittels SM49 ist der Zugriff auf das Betriebssystem und damit auf das Tool möglich. Die Datenbanksprache erlaubt grundsätzlich auch den Zugriff auf das Betriebssystem. Somit gelang uns aus ABAP heraus, das Betriebssystem der Datenbank zu steuern.
SAP Applikationsserver tauschen mit SAP und Non SAP-Systemen Daten aus. Dazu gibt es verschiedene Möglichkeiten. Zum einen kann dies über Webservices geschehen, deren großzügige Freischaltung in der Transaction SICF immer wieder zu Sicherheitsproblemen führen oder über die RFC Schnittstellen.
Technisch beschreibt die SAP die notwendigen Einstellungen und Gefahren ausführlich in ihrem SAP-RFC Sicherheitsleitfaden. Um Webservices zu sichern, wird auf URL Filter oder Applikationsfirewalls verwiesen.
Schnittstellen zu härten ist kein einmaliger, sondern ein kontinuierlicher Prozess und erfordert ein Schnittstellenmanagement. Jede Schnittstelle hat einen Lebenszyklus und muss wie eine Firewall Regel auf Aktualität geprüft werden. Sie können dazu eigene Skripte oder SAP Produkte einsetzen. Wichtig ist, den zeitlichen Aufwand und die Komplexität nicht zu unterschätzen.
Die Datensicherung eines SAP-Systems ist eine unterschätzte Achillesferse in einem Unternehmen.
In der Praxis werden für die verschiedenen Systeme unterschiedliche Sicherungssysteme eingesetzt. In Zeiten der Virtualisierung, wo man ganze SAP Landschaften in wenigen Dateien auf einem USB ablegen kann, erfordert es strikt einzuhaltende Vorgaben, um zu verhindern, dass die Unternehmensdaten im wahrsten Sinn des Wortes zur Tür herausgetragen werden. Zu Zeiten der guten alten Bandsicherung boten physische Grenzen einen gewissen Schutz. Man hätte dazu schon einen Rollwagen und die entsprechende Hardware benötigt, um Daten zu entwenden.
Heute kann dies jeder VM Administrator per Mausklick im laufenden System. Datensicherung erfordert Verschlüsselung und ein verteiltes und redundantes Ablegen der Daten.
Das aus IT-Security Sicht wichtigste Thema „Wie und wo verwahre ich meine Sicherungskopie?“ ist in Unternehmen nicht sehr prominent platziert. Es wird als reines Kostenthema wahrgenommen und kann auch nicht den Geldgebern die gewünschte ROI Rechnung geben.
Als IT-Bereichsleiter können Sie Gelder für aktuelle Hardware bewilligt bekommen, wenn die Schmerzgrenze schlechter Laufzeit bei den Anwendern erreicht wird. Bei Back-Up-Systemen funktioniert dieser psychologische Trick nicht. Hier gilt es, Kosten zu sparen, und das erreicht man durch Deduplizierung und Komprimierung.
Deduplikation vergleicht auf Byte Ebene verschiedene Datensegmente, was man als Fingerprinting bezeichnet. Erkennt es einen identischen Datenbereich, wird nur der Zeiger gespeichert. Dadurch kann man je nach Datenstruktur sehr hohe Einsparungen erreichen, z.B. wenn man 100 Windowsserver sichern möchte, die sich naturgemäß gleichen. Wie gut diese Komprimierung funktioniert, kann man vorher nicht voraussagen, aber man kann sicher sagen, dass dies bei Verschlüsselung nicht funktioniert.
Mittlerweile ist die Verschlüsselung bei Notebooks normal geworden. Die Vorstellung, dass ein „mobiles“ Notebook entwendet werden kann, ist naheliegend. Bei „stationären“ Systemen, gemeint sind die klassischen PCs, ist eine Verschlüsselung schon seltener anzutreffen. Vielleicht liegt es an der Vorstellung, man müsste den ganzen PC aus dem Unternehmen schleppen oder ein Angreifer müsste einen Schraubenzieher mitbringen, um die Festplatte aus dem Gehäuse zu entfernen. Bei Servern ist der Grad der Verschlüsselung noch seltener.
Selbst wenn die Datenbestände am Ende des Sicherungsprozesses verschlüsselt abgelegt werden, erfordert die kostenoptimierte Datenverarbeitung im Betrieb unverschlüsselte Systeme.
Die Prozesse der Datensicherung und der Wiederherstellung müssen jedes Jahr neu analysiert und getestet werden, um den ständigen Änderungen und Anforderungen an die Sicherheit, den Betrieb oder den gültigen Gesetzen gerecht zu werden.
In Zeiten der Virtualisierung ergeben sich neue Angriffsszenarien.
Ein SAP-System besteht je nach Größe nur aus wenigen 100 Gigabytes oder einigen Terabytes.
Die Plattenkapazitäten sind so groß geworden, dass man sich als Administrator einfach vor einem Update eine Sicherungskopie der gesamten virtuellen Maschine machen kann. Ich selbst habe diese technischen Features genutzt, um eine ganze SAP-Landschaft samt Subsystemen zu klonen und in einem eigenen virtuellen Netz zu betreiben. Abgesehen davon, dass dies bei Produktionssystemen aufgrund des Datenschutzes womöglich nicht erlaubt ist, zeigt diese technische Revolution neue Gefahren auf.
Ein Referent auf einer IT-Security Tagung der DSAG erzählte von einem filmreifen Erlebnis bei einem Kunden. Um an die Konsole des VM Systems zu kommen, musste er 3 Sicherheitsschleusen passieren und durfte selber auch keine Dateneingaben vornehmen, sondern musste diese einem Mitarbeiter diktieren. Ein bewaffneter Wachmann hatte zusätzlich die Aufgabe, auf die Einhaltung dieser Regel zu achten.
Sinn und Zweck der drei Sicherheitsschleusen waren nicht drei unterschiedliche Authentifizierungsmechanismen, sondern es sollte sichergestellt werden, dass jemand mindestens 20 Minuten braucht, um von Schleuse 1 bis 3 zu kommen. Sicherheit hängt eng damit zusammen, wie viel Zeit jemand braucht, um Schaden anzurichten.
Ein Klonen ganzer SAP-Landschaften wäre früher undenkbar gewesen. Vor 20 Jahren musste man persönlich mit dem Datenbankadministrator sprechen, um eine Datenmigration von 1 GB vorzunehmen.
Heute redet man über Terabytes und bei großen Rechenzentren über Petabytes. Über eine Endverbraucherleitung erreicht man Downloadgeschwindigkeiten von 1GBits pro Sekunde. Um 1 GB herunterzuladen, braucht es weniger als 1 Minute.
Die Virtualisierung stellt ganz neue Anforderungen auch an die SAP IT–Security. Man kann keine Sicherheitskonzepte mehr aufbauen, die darauf vertrauen, dass der Server hinter einer zugangsbeschränkten Türe steht, oder dass ein Hardwareswitch ein Ausspionieren des Netzwerkverkehrs verhindert oder dass das Deaktivieren einer Sicherheitseinstellung einen Neustart voraussetzt und damit vielleicht die Aufmerksamkeit anderer Personen erregt.
Es kann einem bei der Vorstellung angst und bange werden, dass die Administratoren überall aus dem Firmen-Netzwerk Zugriff auf die Webkonsole der VM Software haben und dem Browser erlauben ihre Kennwörter zu speichern.
Der Domain-Administrator ist der mächtigste Mann im Unternehmen, wenn man von einer Windowswelt ausgeht.
Um Zugriff auf das SAP-System zu erhalten, meldet er sich an der VM-Konsole an, kopiert die VM Maschine des SAPs im laufenden Betrieb, kopiert sich einen passenden DNS-Server, stellt das alles in ein virtuelles Netz, ändert das Passwort des SID-ADM Account und folgt den Anweisungen, um den SAP* -Benutzer zu initialisieren. Für die Umsetzung reicht ein Notebook. Dass dies möglich ist, wurde bereits auf der SAP TechEd vor 10 Jahren präsentiert.
| Montag | 7:30 - 16:30 Uhr |
| Dienstag | 7:30 - 16:30 Uhr |
| Mittwoch | 7:30 - 16:30 Uhr |
| Donnerstag | 7:30 - 16:30 Uhr |
| Freitag | 7:30 - 14:00 Uhr |
