Das Politikum SAP-Sicherheit: Historisch gewachsen unsicher

Mariano Nunez

© Shutterstock / Olivier Le Moal

Durch die Komplexität individueller SAP-Implementierungen und durch Fehlkonfigurationen entstehen enorme Risiken. Denn schon kleine Sicherheitslücken können unternehmenskritische Systeme und Daten gefährden. Außerdem verschlimmern oft ein mangelndes Sicherheitsbewusstsein, unklare Zuständigkeiten sowie ein oft nicht vorhandener Überblick über die tatsächliche Gefahrenlage die Situation. Das verlangt nach einer neuen Sicherheitspolitik und entsprechenden Lösungen.

Fehlkonfigurationen in SAP-Implementierungen erschließen Möglichkeiten zu Betrug, Spionage oder Sabotage. Betrügerische Aktivitäten umgehen dabei etwa klassische SAP-Sicherheitskonzepte wie Segregation of Duties (SoD), indem ein Angreifer sich die Zugriffsrechte eines anderen Anwenders verschafft. Dann legt er einen Strohmann als einen neuen Zulieferer an, schreibt Rechnungen für sich und veranlasst anschließend die Zahlungen. In entsprechend kleinem Rahmen bleibt ein solches Vorgehen möglicherweise lange unentdeckt.

Vielleicht noch gefährlicher ist, wenn der Angreifer intellektuelles Eigentum verletzt oder sensitive Daten ausliest. Kundeninformationen – wie Name, Adressen, Kreditkarten, aber auch Interna wie Lohnzettel oder Kalkulationstabellen für die Produktionsplanung – stehen offen, wenn Angreifer sich über dem Transaktionslevel etwa von SAP NetWeaver oder SAP HANA Zugriff verschaffen. Die zunehmende Vernetzung der digitalen Wirtschaft bietet zudem nicht nur internen, sondern auch externen Angreifern vielversprechende Wege für die digitale Industriespionage, wie etwa Kunden- und Lieferantenportale. Durch das Ausnutzen einer Schwachstelle können die Hacker dort Zugriff auf SAP-Portale und Prozessintegrationsplattformen sowie die damit verbundenen internen Systeme erlangen. Ebenso vielversprechend sind Angriffe auf Datenbanken über proprietäre SAP-Protokolle: Für diese Attacken werden Betriebssystembefehle mit den Rechten bestimmter Benutzer ausgeführt und Schwachstellen im SAP-RFC-Gateway ausgenutzt. Der Hacker erhält Zugriff auf jede in der SAP-Datenbank gespeicherte Information und kann diese auslesen und weiterleiten.

Die Sabotage eines SAP-Systems beginnt damit, dass Informationen verändert oder gelöscht werden. Ein weiterer Schritt ist der Angriff auf die Verfügbarkeit von Anwendungen für Produktionsplanungsdaten. Diese Angriffe beeinträchtigen die Produktionsabläufe und verursachen enormen Schaden. Im schlimmsten Fall kommt es zu einem Shutdown, dem völligen Abschalten eines ganzen SAP-Systems. Ein solcher Totalausfall hat enorme Folgen und verursacht mit jeder Minute Schäden in Millionenhöhe. Ein abgeschaltetes System ist aber für einen Angreifer alles andere als rentabel, sodass ein solcher Angriff in der Regel unterbleibt.

Betrug, Spionage und Sabotage verursachen einen enormen wirtschaftlichen Schaden für betroffene Unternehmen.  Die Corporate-Trust-Studie „Industriespionage 2014“ beziffert Schäden durch Angriffe auf alle IT-Infrastrukturen. Die Ergebnisse der Befragung von Unternehmen mit mehr als zehn Mitarbeitern oder einer Bilanzsumme von mehr als 1 Million Euro und die Hochrechnung des Schadens unter Berücksichtigung von 300 000 Unternehmen in Deutschland und 42 000 Unternehmen in Österreich zeigen die Dimension des Problems: Demnach beklagte jedes zweite Unternehmen in den Jahren 2012 und 2013 einen Spionageangriff oder Verdachtsfall. 26,9 Prozent in Deutschland und 27,1 Prozent in Österreich waren von einem konkreten Vorfall betroffen. Der jährliche finanzielle Schaden durch Industriespionage belief sich in Deutschland auf 11,8 Milliarden und in Österreich auf 1,6 Milliarden Euro.

Angriffe zielen auf Fehler in der Konfiguration

Angriffe auf SAP-Systeme zielen immer auf unsichere individuelle Konfigurationen von SAP-Instanzen ab. Die gefährlichsten Angriffe gelten dabei den verschiedenen Transaktionslayern wie etwa SAP NetWeaver, ABAP, SAP Mobile, SAP BusinessObjects oder J2EE, in Zukunft aber auch vor allem den SAP-HANA-Plattformen. Auf dieser Ebene erfolgt die Kommunikation zwischen den verschiedenen Instanzen, das Erteilen von Zugriffsrechten auf die Rechteverwaltung und Tabellen sowie die Festlegung der rund 1 500 Konfigurationsparameter, von denen geschätzt 20 Prozent sicherheitsrelevant sind. Die Komplexität historisch gewachsener SAP-Umgebungen, die zuallererst der Produktivität und nicht der Sicherheit dienen sollen, führt zu Sicherheitslücken in der einzelnen Implementierung. Angriffe auf den Transaktionslayer wirken sich dabei umgehend auf Geschäftsanwendungen und auf die Sicherheit intellektuellen Eigentums aus.

Dabei gehen viele Angreifer den Umweg über nicht produktive und daher oft schlechter geschützte Systeme aus der Entwicklung oder dem Qualitätsmanagement. Bei diesem Pivoting nutzen sie die oft nur unsicher konfigurierten, häufig lediglich mit Default-Credentials gesicherten Accounts von Entwicklungs- und Qualitätsmanagementsystemen, um darüber Zugriff auf die Produktivsysteme und die dort verwalteten Geschäftsinformationen und -prozesse zu erhalten.

Die unabhängige Organisation Business Application Security Initiative (BIZEC) analysiert seit Jahren die Sicherheitsrisiken der einzelnen SAP-Implementierungen. Angeführt wird die Liste der Risikofaktoren dabei vom Einsatz verwundbarer Software. Nicht eingespielte Updates erzeugen Lücken, die zum Teil mit schon lange verfügbaren Updates geschlossen werden könnten. Es folgt die Verwendung von Standardusern mit Defaultpasswörtern. Weitere zentrale Risiken sind:

  • ungesicherte SAP-Gateways
  • ungesicherte SAP-/Oracle-Authentifizierungen
  • ungesicherte RFC-Schnittstellen
  • ungenügendes Security Audit Logging
  • ungesicherte SAP-Message-Server
  • gefährliche SAP-Webapplikationen
  • ein ungeschützter Zugang zu Administrationsdiensten
  • unsichere Netzwerkumgebungen
  • unverschlüsselte oder nur schwach verschlüsselte Kommunikation
nunez_security_1

Abb.1: Inventur der Sicherheit: Erst die Analyse von Sicherheitslücken schafft einen Ausgangspunkt für IT-Sicherheit (Quelle: Onapsis)

Angriffe auf die Cloud folgen demselben Muster

Es spricht vieles dafür, dass diese Risikofaktoren auch in den neuen SAP-HANA-Implementierungen Bestand haben werden. SAP HANA ist eine zentrale Basistechnologie für alle SAP-Applikationen inklusive S4/HANA und der SAP HANA Cloud. Hauptkomponente der Plattform ist eine In-Memory-Datenbank, an die eine Reihe zusätzlicher Dienste angebunden ist. Durch die unmittelbare Verknüpfung von Datenbank und Anwendungen schlagen Attacken zum Beispiel über SQL-Protokolle direkt auf die Geschäftsprozessebene durch. Durch die erweiterte Anbindung von mobilen Geräten oder durch Cloud-Schnittstellen bieten sich zudem größere Angriffsflächen.

So steigt die Zahl der vom Hersteller gelieferten Sicherheitspatches kontinuierlich und hat etwa 2014 im Vergleich zum Vorjahr um 450 Prozent zugenommen. Diese Hilfestellungen sind absolut wirksam und sollten von den Unternehmen und Organisationen angenommen werden. Unterbleibt ein Einspielen dieser Patches, gefährdet dies alle SAP-HANA-basierten Applikationen. Manche Patches erfordern aber auch Änderungen in der Systemkonfiguration. Ansonsten können nicht authentifizierte Angreifer unter Umständen die vollständige Kontrolle über nicht ausreichend abgesicherte Systeme übernehmen sowie Geschäftsinformationen stehlen, löschen oder manipulieren.

Die solchen Angriffen zugrunde liegenden Mechanismen sind dabei nicht neu. Interne wie externe Angreifer übertragen klassische Cybercrimemethoden auf das SAP-Umfeld. Dazu gehören zum Beispiel:

  • Remote-Code und Remote Command: Das ferngesteuerte Ausführen von Schadcode ist die wohl größte und auch weit verbreitetste Gefahr. Dies erfolgt zum Beispiel sowohl nach einem Log-in über HTTP- als auch über SQL-Datenverkehr. Gerade die unmittelbare Verzahnung von Datenbanken und Anwendungen bei SAP HANA steigert das Risikopotenzial von SQL-Protokollen und verlangt von den Verantwortlichen in Zukunft Security-, Netzwerk- und Datenbankkompetenzen.
  • Angriffe auf Verfügbarkeit: Eine solche Fernsteuerung durch einen Angreifer kann die Verfügbarkeit der Systeme beeinträchtigen – bis hin zum Abschalten eines Systems. Auch das unautorisierte Anlegen oder das Kopieren, Löschen, Überschreiben sowie Verschieben von Dateien und Ordnern kann zum Ausfall von Systemen führen.
  • Auslesen von Dateien: Auf der Suche nach dem intellektuellen Eigentum eines Unternehmens, wie etwa Kundendaten, Informationen zur Produktionssteuerung oder Kalkulationen, können Angreifer nach Belieben geschäftsrelevante Informationen auslesen oder Dateien kopieren.
  • Stoppen von Anwendungen: Bei manchen nicht gepatchten Schwachstellen können externe Anwender ohne Authentifizierung mit entsprechenden privilegierten Accounts ganze Geschäftsprozesse stoppen.
  • Suche nach weiteren Sicherheitslücken: Angreifer spähen Infrastrukturumgebungen aus, indem sie etwa Logeinträge mit technischen Informationen über Systeme auswerten. Mit diesem Wissen starten sie dann später gefährlichere Attacken.

Das Sicherheitsrisiko der einzelnen SAP-Implementierungen im Einsatz resultiert aber nicht nur aus diesen technischen Möglichkeiten. Mangelnde Ressourcen machen es scheinbar unmöglich, konfigurationsbedingte Sicherheitslücken zu beheben. Unklare Kompetenzen führen zu einer falschen Sicherheitspolitik.

Trügerisches Sicherheitsgefühl

Außerdem herrscht oft ein falsches Sicherheitsgefühl vor. In der Komplexität von SAP sehen viele Verantwortliche eine vermeintliche Schutzmauer. Wie soll ein Externer die eigenen Instanzen durchschauen und zielgerichtet angreifen? Ein solches Sicherheitsgefühl ist trügerisch. Denn solche Angriffe sind längst nicht mehr nur das Werk von SAP-Experten. Angaben des Marktforschungsunternehmens IDC aus dem Jahr 2014 belegen, dass lediglich in drei Prozent der Angriffe auf Enterprise-IT komplexe Malware genutzt wurde. Grundkenntnisse in Netzwerk und Sicherheit oder auch über Social Engineering genügen. Informationen über konkrete SAP-Systeme können online ohne irgendwelche Autorisierungsdaten gefunden werden.

Falsches Inseldenken

Viele Verantwortliche übersehen auch, dass es rein interne Netzwerke nicht mehr gibt. Sie sind sich der Folgen nicht bewusst, die sich aus der Anbindung externer Zulieferer oder mobiler Mitarbeiter ergeben. Fast jede IT-Infrastruktur verfügt mittlerweile über Zugänge, über die externe Anwender, wie Zulieferer, auf Plattformen und Geschäftsprozesse zugreifen. SAP-Systeme sind beispielsweise über Webanwendungen, SAP Mobile, aber auch über SAP-Umgebungen, die in der Cloud eingerichtet werden, an das Internet angebunden. Ein Zugang über eine App kann auch als Zugang zu allen SAP-Instanzen benutzt werden. Ebenso eignen sich Kundenportale als Einfallstor, wie der Fall NVIDIA aus dem Jahr 2014 zeigt.

Ressourcen fehlen

Schon für das Einspielen der aktuellen Patches stehen zu wenig Zeit und Personal zur Verfügung. Es werden vorrangig solche Patches implementiert, die die Funktionalität des Systems verbessern und technische Probleme beseitigen. Sicherheitsrelevante Patches sind aber bisweilen oft noch aufwendiger und verlangen eventuell mehr Einsatz. Wer sie ohne eine vorherige Analyse der bestehenden Infrastruktur und der eigenen Geschäftsabläufe einspielt, schafft unter Umständen neue Risiken. Davor und vor dem Aufwand schrecken viele IT-Verantwortliche zurück. In der Folge vergeht zwischen dem Auftreten einer neuen SAP-spezifischen Bedrohung und der tatsächlichen Implementierung viel Zeit – nach Einschätzung unserer Experten bis zu 18 Monate. So ist es nicht verwunderlich, dass nach Schätzung von IDC-Experten aus dem Jahr 2014 rund 75 Prozent der Angriffe auf Enterprise-Anwendungen allein durch Patches geschlossen werden könnten. Das gilt auch für SAP-Systeme.

nunez_security_2

Abb. 2: Echtzeitüberblick der Bedrohungslage: Ein Dashboard zeigt Angriffe und auffälliges Nutzerverhalten auf (Quelle: Onapsis)

Sicherheitskonzepte reichen nicht aus

Viele Unternehmen beschränken ihre Abwehr auf klassische Konzepte der Anwendungssicherheit wie Segregation of Duties oder Governance, Risk und Compliance (GRC). Diese Instrumente sind ohne Zweifel sinnvoll und dürfen nicht vernachlässigt werden. Aber sie reichen nicht aus, weil sie die geschilderten Angriffe auf den Transaktionslayer nicht verhindern. Der Segregation-of-Duties-Ansatz schafft vermeintlich Sicherheit durch die Kontrolle von Nutzerrollen und Autorisierungen. Angriffe auf den Transaktionslayer hebeln etwa durch Erweiterungen bestehender Berechtigungen oder durch die Anlage neuer User den SoD-Ansatz aus.

Kompetenzprobleme bremsen

Zuständigkeiten sind oft schlecht verteilt oder die Beteiligten reden nicht miteinander. Nicht wenige CISOs beauftragen entweder IT-Sicherheitsadministratoren, die keinen Überblick und Einblick in die SAP-Plattform haben, oder SAP-Sicherheitsexperten, die wiederum die Transaktionsebene ausblenden. Bisweilen weisen sich auch Fachabteilungen, IT-Administratoren und CISOs die Verantwortungen gegenseitig zu. Fortschrittliche Unternehmen haben die Kompetenzen mittlerweile klar geregelt und technische Ressourcen bereitgestellt, damit jeder seine Aufgaben auch erledigen kann. Hier haben viele Organisationen aber noch Handlungsbedarf.

Es fehlt die Diskussionsgrundlage

Die SAP-Sicherheitspolitik in vielen Unternehmen leidet letzten Endes am fehlenden Überblick über die Risikolage, da eine Sicherheitsinventur über die bis zu 1000 Instanzen eines Enterprise-Systems und damit eine angemessene SAP-Sicherheitspolitik nicht möglich ist. Neben dem Auditing mangelt es auch an einer Korrelation der Gefahren mit den damit einhergehenden betriebswirtschaftlichen Auswirkungen. Sie würde eine Priorisierung der Gefahrenabwehr je nach Dringlichkeit und nach den eigenen Kriterien eines Unternehmens ermöglichen. Ebenso schwierig ist oft auch das Reporting von Sicherheitsanstrengungen etwa durch Deltaberichte: Nur mit enorm hohem Aufwand können Unternehmen so ihren Complianceverpflichtungen nachkommen, weil sie ihre Maßnahmen nicht nachweisen können.

Eine wirkliche Übersicht der Sicherheitslücken als Diskussionsgrundlage für eine effiziente und durchführbare Sicherheitspolitik, die alle Beteiligten an einem Tisch zusammenbringt und auf deren Basis sich Kompetenzen verteilen lassen, fehlt häufig. SAP-Sicherheit landet im schlimmsten Fall im toten Winkel der Verantwortlichkeiten: Was keiner leisten kann, will keiner verantworten.

nunez_security_3

Abb. 3: Echtzeitüberblick der Bedrohungslage: Ein Dashboard zeigt Angriffe und auffälliges Nutzerverhalten auf

Sicherheit durch kontinuierliches Assessment, Detection und Response

Wie verschafft man sich den notwendigen Überblick über die eigene Sicherheitslage, und wie startet man in der Folge die Umsetzung einer solchen Sicherheitspolitik? Nur mit einer automatisierten kontinuierlichen Inventarisierung aller Sicherheitslücken in einer implementierten SAP-Landschaft ist Sicherheit möglich. Scans möglicher Schwachstellen zeigen nicht nur konfigurationsbedingte Lücken, sondern auch deren Effekt auf Geschäftsprozesse und Anwendungen, wenn sie ausgenutzt werden. Darauf aufbauend können CISO, IT-Admin und Fachabteilung Gefahren individuell bewerten und Abwehrmaßnahmen nach ihren Bedürfnissen priorisieren. Mit entsprechenden Lösungen sind solche Überprüfungen eine Sache von Minuten. Bei regelmäßiger Durchführung dokumentieren Deltaberichte die getätigten Anstrengungen und belegen zudem die Compliancebemühungen des CISOs.

Die Inventur der Sicherheitslage in Fastechtzeit ist aber nur der erste Schritt, auf den die schnelle Abwehr von Bedrohungen ebenso in Fastechtzeit folgt. Ein solches Warnsystem verzeichnet ab dem Bekanntwerden einer neuen Bedrohung die Lücken und fordert zu deren Schließen auf. Es registriert auch verdächtige Konfigurationsänderungen, wie etwa das Einrichten neuer Anwender mit kritischen Berechtigungen, verdächtige Logaktivitäten oder auch Zugriffe von Dritten und Vertragspartnern, die in eine SAP-Struktur eingebunden sind. IT-Verantwortliche schätzen anhand dieser kontext-sensitiven Berichte die Auswirkung der Angriffe auf die Geschäftsprozesse sowie deren Erfolgswahrscheinlichkeit ein und können notwendige Abwehrmaßnahmen individuell priorisieren.

Zugleich spielt die Beobachtung auffälliger Aktivitäten innerhalb der SAP-Landschaft, die auf böswillige Aktivitäten von externen oder internen Angreifern hindeuten, eine wichtige Rolle. Wenn ein Mitarbeiter aus der Research-and-Development-Abteilung plötzlich zu ungewöhnlichen Zeiten oder während seines Urlaubs auf Kundenlisten, Rechnungsdaten oder Lieferantendatenbanken zugreift, deutet ein solches Verhalten auf kriminelle Aktivitäten durch Mitarbeiter oder durch Externe hin.

Wirksame SAP-Sicherheit lässt sich in Fastechtzeit durchsetzen. Patches, Segregation of Duties und GRC-Regeln als die klassischen Tools der SAP-Sicherheit erhalten hier die entscheidende Ergänzung für eine praktikable und effektive Sicherung von SAP-Konfigurationen. Das gilt auch für die SAP-HANA-Implementierungen der Zukunft.

Aufmacherbild: Button with the word risk via Shutterstock / Urheberrecht: Olivier Le Moal

Verwandte Themen:

Geschrieben von
Mariano Nunez
Mariano Nunez
Mariano Nunez ist CEO und Mitbegründer von Onapsis Inc. Er ist für die strategische Ausrichtung des Unternehmens verantwortlich. Außerdem ist er Experte im Thema Anwendungssicherheit sowie SAP-Cybersicherheit und veröffentlichte als erster SAP-Plattform-Risiken und bot Lösungen zu deren Minimierung an. Als Sprecher trat er auf Security-Konferenzen wie RSA, Black Hat, SANS, SAP GRC und SAP TechEd auf und hat mit zahlreichen Fortune-100-Unternehmen, Sicherheitsdienstleistern und militärischen Einrichtungen gesprochen. Er entwickelte als erster ein Open-Source-basiertes SAP- und ERP-Penetration-Test-Verfahren. Nunez wurde vom Massachusetts Institute of Technology in eine Liste führender Personen unter 35 Jahren aufgenommen, die Innovation maßgeblich vorantreiben.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: