Anzeige

Fünf Mythen zur SAP-Sicherheit

Thomas Werth
Autor: Thomas Werth

Zur SAP-Sicherheit schwirren einige Mythen im Universum. Wir baten daher unseren Gastautoren und Security-Experten Thomas Werth, mit den wichtigsten, weit verbreiteten Irrtümer zur SAP-Sicherheit aufzuräumen. SAP ist doch „out-of-the-box“ sicher … und wenn nicht, kümmert sich unser Dienstleister darum, oder?

In seinem aktuellen Gastbeitrag lehnt er sich augenzwinkernd an eine bekannte Filmreihe an … aber lesen Sie selbst.

 

 

„Es war einmal vor langer Zeit in einer weit, weit entfernten Systemlandschaft. Die Systembetreiber sind in Aufruhr, denn eine kleine Gruppe von Hackern greift vereinzelt Systeme aus dem Hinterhalt an. Doch der Administrator baut bereits an der ultimativen Lösung – DEM SICHEREN SAP-SYSTEM …“

Kürzen wir die Geschichte an dieser Stelle ein wenig ab. Jeder weiß doch, dass — wie im Star-Wars-Film — am Ende die kleinen Rebellen das Super-System zerstören konnten. Widmen wir uns lieber der Frage: Wie konnte es dazu kommen? Ein Blick auf einige weit verbreitete Mythen zur SAP-Sicherheit hilft uns sicher dabei, diese Frage zu beantworten.

 

„Ein geschickter Angreifer agiert, wo die Verteidiger nur reagieren können und er wählt gut überlegt aus, WO und WANN er WIE zuschlägt. Kennt man diese Strategien nicht und verlässt sich auf Standard-Abwehrmaßnahmen, haben Hacker gute Chancen kleinere und größere Schlachten zu gewinnen!
Thomas Werth – Geschäftsführer werth IT

 

1. Das interne Netzwerk ist sicher

SAP Sicherheit

Lord Security wundert sich immer noch. Wie konnten die Hacker nur Zugang zu den kritischen Kern-Systemen erhalten und die geheimen Pläne stehlen? Diese stehen doch gut geschützt im Zentrum der Macht. Der Administrator wird toben vor Wut!

Die Annahme, das interne Netzwerk sei ein sicherer und isolierter Hafen für SAP-Systeme, ist heutzutage nicht mehr gültig. Mitarbeiter, Systeme und auch Services benötigen Zugriff auf das Internet. Dazu kommen Homeoffice, Support via VPN und angebundene Zweigstellen. Ebenfalls sind die Methoden der Angreifer deutlich raffinierter geworden. Mehrmals im Jahr liest man in der Presse, wie es wieder ein bekanntes Unternehmen erwischt hat … und die Angreifer Monate lang unentdeckt im internen Netzwerk aktiv waren.

Dies läuft oft nach demselben Schema ab: Ein Mitarbeiter klickt in einer Mail auf den Anhang oder Link. Der Besuch der „falschen“ Webseite oder das Öffnen des Dokuments infizieren den Arbeitsplatz mit Schadsoftware. Die Angreifer steuern den Computer fern und können sich von dort weiter im Netzwerk bewegen. So erhalten Sie auch Zugang zu den SAP-Systemen oder AD-Servern. Die Robustheit des SAP-Systems gegen Cyberangriffe ist an dieser Stelle die letzte Hoffnung gegen die Angreifer – auch wenn aus Story-Sicht der Ordensritter Owe Lan Kaputti besser passen würde.

 

2. SAP ist „out-of-the-box“ sicher

Immer noch ungeklärt ist für Lord Security, wieso der Angriff nicht abgewehrt werden konnte. Die Anschaffung der Komponenten aus Mon-Calldorf kostet schließlich Unsummen, da kann man doch einiges an vorinstallierten Sicherheitsmaßnahmen erwarten. Es muss ja nicht gleich ein Turbolaser sein.

SAP-Systeme bieten gewiss vielschichtige Schutzmaßnahmen zur Absicherung des Systems. Viele sind auch direkt bei Inbetriebnahme aktiv. Doch was ist wirklich sicher und wo muss nachgebessert werden?

Das SAP-Gateway ist inzwischen per Default abgesichert. Dennoch muss man hier aufpassen. Falls man ältere Systeme lediglich aktualisiert, bleiben die alten möglicherweise unsicheren Einstellungen aktiv und der Schutz ist nicht aktiv.

Weiterhin sind alle bekannten Standardzugangsdaten abzuändern. Das sicherste System ist wirkungslos, wenn jeder den Schlüssel kennt. Dies gilt auch für das Verfahren zur Vergabe von Initialkennwörtern bei einem Passwort-Reset oder neuen Benutzern. Wird hier ein bekanntes Passwort oder Schema verwendet, lassen sich Zugangsdaten erraten.

Ebenso können die eigenen Anwender zur Gefahr werden, wenn die vergebenen Berechtigungen nicht restriktiv kontrolliert werden. Selbst wenn man den Anwendern blind vertrauen kann, besteht immer noch die Gefahr durch die Kompromittierung des Arbeitsplatzes und damit der Übernahme dessen SAP-Accounts durch einen Angreifer. Aufgrund der stetigen Änderungen bei Benutzern und Berechtigungen, existiert hier ein sehr dynamischer Sicherheitsbereich.

Ähnlich dynamisch verhält es sich mit den Sicherheitsupdates. Einmal im Monat veröffentlich SAP Security Notes für die Systeme. Mit der Veröffentlichung der Notes lassen sich die Angriffswege nachstellen und ausnutzen. Ein schnelles Handeln für kritische Lücken ist hier notwendig.

Dies sind nur einige Punkte, die es zu bedenken gilt. Man kann einfach nicht erwarten, dass ein System zum Zeitpunkt X (gerne auch die Inbetriebnahme) absolut sicher ist — und dies auch ohne weitere Pflege bleibt. Vor allem da im Internet verschiedene Angriffsbeschreibungen und
Angriffswerkzeuge frei verfügbar sind. Somit können selbst Praktikanten Angriffe durchführen und nicht nur „hochkompetente“ Angreifer.

 

3. Der Dienstleister ist für Sicherheit verantwortlich!

Wie konnte bisher nur so viel schieflaufen? Lord Security ist auf dem Weg zu dem Befehlshaber der Hosting-Truppen. Es ist doch sicher deren Aufgabe gewesen, für die Erhaltung der Sicherheit zu sorgen. Lord Security reagiert empfindlich auf Vernachlässigung von Pflichten, da krümmt sich schnell mal seine Hand zur leicht geöffneten Faust …

Ist der Dienstleister tatsächlich vertraglich zur Sicherheit der Systeme verpflichtet?

Ein Blick in das Vertragswerk bringt viel zu oft Ernüchterung beim Auftraggeber. In der Regel finden sich keine Vereinbarungen zur regelmäßigen Aktualisierung bezüglich Security Notes. Auch keine Pflicht zur Einhaltung einer definierten Funktionstrennung bei der Vergabe von Berechtigungen. Ebenso fehlt die Vorgabe von Security-Richtlinien für die Erstellung von Custom Code. Nicht mal die Einhaltung der Vorgaben aus dem DSAG-Prüfleitfaden zur sicheren Konfiguration findet sich dort.

Vielmehr finden sich Details zu dem Betrieb des Systems und Servicelevel zu Ausfallzeiten sowie Supportanfragen.

Zudem muss man sich fragen, welche Aufgaben der Dienstleister in der täglichen Administration wirklich übernimmt? Wer legt die Benutzer an und weist die Berechtigungen zu? Wer erstellt Custom ABAP Code? Wer konfiguriert die Sicherheitsparameter des Systems?

Selbst wenn der Dienstleister all dies übernehmen würde und vertraglich die Sicherheit fixiert ist, reicht das wirklich?

Gemäß der Rechtsprechung ist es als Auftraggeber nicht ausreichend, die Security zu delegieren. Im Rahmen des Risikomanagements obliegt dem Auftraggeber unausweichlich auch die Kontrollpflicht. Er ist und bleibt verantwortlich für die Sicherheit seiner Daten und Systeme und muss mindestens kontrollieren, dass die vertraglichen Vorgaben eingehalten werden. Gut für den, der hier eine leistungsfähige Security-Monitoring-Lösung im Einsatz hat.

 

4. Nur produktive Systeme benötigen Schutz

Es dreht sich noch immer im Kopf von Lord Security. Diese ganzen Vertragsklauseln und missverständlichen Zuständigkeiten. Aber die produktiven Einheiten haben doch besonderen Schutz erhalten und sind sogar jährlich durch die Inquisitoren der Wirtschaftsprüfer inspiziert worden. Da ist es nie zu Beanstandungen gekommen. Wieso waren die Hacker trotzdem erfolgreich?

Verständlicherweise widmen sich viele verstärkt dem Schutz der produktiven Systeme. Dort liegen ja letztlich die kritischen Daten, und auch die Geschäftsprozesse laufen hier. Was soll schon groß passieren – sofern diese Systeme hoch sicher sind?

Nun es ist doch klar, dass sich niemand gern die Zähne ausbeißt. Daher gehen auch Angreifer den Weg des geringsten Widerstandes. Wozu das hochsichere Systeme attackieren, wenn man doch das stiefmütterlich behandelte Legacy-System viel einfacher unter Kontrolle bekommen kann? Dort finden sich sicher auch einige Schätze.

Man mag sich jetzt fragen: Was für Schätze? Das System hat doch gar keine Bedeutung mehr?
Nun auch in diesen Systemen existieren Benutzer und deren Zugangsdaten. Im einfachsten Fall werden hier teilweise dieselben Zugangsdaten benutzt, wie im hochsicheren System, und man kann die erbeuteten Passwörter einfach wiederverwenden. Manchmal erkennt man auch ein Schema in den Passwörtern wie <SID><Mandant>.

Technische Benutzer erweisen sich als echter Schatz, da diese meist systemübergreifend starke Berechtigungen besitzen und aufgrund der automatischen Verarbeitung dieselben Zugangsdaten verwenden. Gerade Benutzer in Zusammenhang mit einem Solution-Manager öffnen viele Türen.

Aber auch der Weg über die RFC-Verbindungen kann sich lohnen. Hier sucht man Trusted Verbindungen oder solche mit einem stored-user, der kritische Berechtigungen im Zielsystem besitzt. Mit diesen kann man leicht und sicher von System zu System „reisen“ bis man im produktiven Zielsystem angekommen ist, und sich die Türen auf dem Weg öffnen, wie von der Macht gesteuert.

 

5. Audit-Projekte sind zeitaufwändig

Lord Security muss dem Administrator erklären, wie es zu dieser Kettenreaktion kommen konnte. Er grübelt, wie er aus der Nummer herauskommen kann. Leider ist der Administrator kein Domino-Fan, das hätte den Themenwechsel leichtgemacht. Jetzt dreht sich alles um die Frage, ob man einen solchen Angriff vorhersehen konnte? Vielleicht wäre sogar eine Strategie zur Abwehr möglich gewesen? Ach, dazu wäre ja ein Probeangriff nötig gewesen! Ha! Der Administrator hat doch alle Ressourcen in das Projekt zum Bau des Systems gesteckt. Er braucht dem Administrator nur aufzuzeigen, dass das galaktische ITerium somit nicht über die notwendigen Ressourcen für einen Probeangriff verfügt hat.

In dem normalen Arbeitsalltag sind die Ressourcen meist stark in Projekten zur produktiven Nutzung und Betrieb der Systeme eingebunden. Selten ist Zeit für ein großes Security-Projekt. Aber hier hat sich ein Fehler in der Annahme eingeschlichen: Bei Projekten mit Zero-Footprint Ansatz ist der Aufwand in der Vorbereitung minimal. Selbst die Durchführung solcher Probeangriffe lässt sich rasend schnell umsetzen. Wir erleben oft verblüffte Kunden, die kaum glauben können, welche Ergebnisse in kürzester Zeit zur Verfügung gestellt werden. Das kennen die Systembetreiber nicht einmal von Projekten die Wochen dauern.

Selbst für die Einrichtung eines kompletten Security-Monitorings können die Tage an zwei Händen abgezählt werden. Die Zeiten von aufwendigen Security-Projekten zur Erkennung von Risiken sind vorbei. Smarte automatisierte Werkzeuge erledigen die Prüfaufgaben in Minuten, die zuvor ein schwarzes Loch an Manntagen gewesen sind.

Natürlich sehen einige die Einführung von HANA als neue Hoffnung. Doch hier muss man sich nur Fragen, ob die unter 2. aufgeführten Beispiele nicht auch für HANA gelten.

 

Schlusswort von Thomas Werth

Falsche Annahmen im Bereich der Systemsicherheit können zu unbewussten Risiken führen. Diese enden im schlimmsten Fall mit einem Schaden. Die Geschichte von Lord Security und dem Administrator soll ein wenig sensibilisieren.

Es bleibt zu wünschen, dass jeder die Sicherheit des internen Netzwerkes sowie die Basis-Sicherheit von SAP-Systemen oder auch die Aufgaben seines Dienstleisters richtig einschätzen kann. Ebenso ist es wichtig, Risiken transparent zu machen. Bekannte Risiken kann man akzeptieren, zur Not zeitlich begrenzt. Unbewusste Risiken können dagegen zur Stolperfalle werden.

Dem Schutz der Daten und Geschäftsprozesse sollte man Priorität geben, bevor es zu einem Schaden kommt. Erst nach einem Schaden zu handeln, überlasst man doch lieber Lord Security in einer fiktiven Geschichte.

 

Wir danken Ihnen, wenn Sie diesen Artikel jetzt weiterempfehlen:

Anzeige

Über die Redaktion IT-Onlinemagazin

SAP-Community Nachrichten, die Entscheider kennen sollten: Abonnieren Sie jetzt unseren IT-Onlinemagazin Newsletter. Lesen Sie Umfrageergebnisse, Insights aus dem SAP-Ecosystem, Interviews und Artikel ... und Sie bleiben kompakt informiert.

Lesetipp für Sie:

DSAGTT24

DSAG-Event bringt Klarheit — aber auch neue SAP-Fragen

Was waren die wichtigsten Erkenntnisse der DSAG-Technologietage 2024 in Hamburg? SAP-Kunden fordern vom Hersteller SAP …