Security-Audits von SAP-Systemen

Angreifern einen Schritt voraus

26. Januar 2018, 07:00 Uhr   |  Otto von Natzmer

Angreifern einen Schritt voraus

SAP-Anwendungen zählen zu den attraktivsten Zielen für einen Angriff. Mit einem SAP-Audit lassen sich Sicherheitslücken aufdecken, bevor Angreifer sie ausnutzen können. Der folgende Beitrag erläutert, wie ein solches Audit idealtypisch verläuft.

Die regelmäßige Überprüfung des externen und internen Sicherheitsniveaus gehört zum möglichen Instrumentarium einer jeden Organisation. Hierzu zählt zum Beispiel ein internes SAP-Audit, das eine ausgedehnte Analysephase durch Angreifer in einem überschaubaren Zeitraum simuliert. Auch ein externes Audit der SAP-Systeme mit Schnittstellen zum Internet - etwa durch das Betreiben eines externen Services, der auf SAP-Daten beruht - ist wichtig für den Erhalt eines hohen IT-Sicherheitsniveaus.

Ein weiterer guter Grund für ein SAP-Audit ist die Einbindung externer Partner, die technisch für die SAP-Landschaft kritisch sein kann - Stichwort Industrie 4.0.

Mit einem SAP-Audit lassen sich Risiken, die oft jahrelang unbemerkt bleiben und eine offene Flanke für Spionage darstellen, minimieren und die Vertraulichkeit und Integrität von Daten nachhaltig sichern. Im Fokus stehen - anders als bei Audits der Wirtschaftsprüfer - konkrete Angriffsszenarien; denn Angreifer könnten Prozesse manipulieren, die Unternehmensabläufe stören, kritische Unternehmensdaten abziehen und sogar für Sabotage die komplette Kontrolle über die IT erlangen.

Durchgeführt werden SAP-Audits von Security-Analysten: Für die Simulation eines Angriffs nutzen diese die gleichen Strategien, Taktiken und Tools wie die Angreifer. Durch den internen Zugriff, der vom Auftraggeber autorisiert sein muss, gewinnen sie Informationen über Schwachstellen im Zeitraffer, die sich Angreifer unter Umständen über Monate erarbeiten. Im Mittelpunkt stehen folgende Fragen:

  • Welche technischen Schwachstellen haben die SAP-Systeme, Infrastruktur oder Anwendungen der untersuchten Organisation? Hält unser SAP-System Angriffen stand? Wie einfach lassen sich die Anwendungen manipulieren?
  • Wie wirksam sind existierende Sicherheitsmechanismen, um Angriffe zu erkennen oder zu unterbinden?
  • Welchen Schaden kann ein Angreifer anrichten, der Schwachstellen ausnutzt und die Sicherheitsmechanismen umgeht?

Bestandteile eines SAP-Audits sind Schwachstellen-Scans und Penetrationstests, allerdings ausschließlich solche nicht-produktiver Systeme.

Den Betrieb produktiver Systeme darf ein Audit nicht beeinträchtigen. Penetrationstests sind die kreativste Form des simulierten Angriffs und damit die Kür unter den Sicherheitstests. Dem Security-Analysten reicht häufig eine einzige Schwachstelle entlang der Schnittstelle zwischen Internet und Unternehmensnetzwerk, um einen umfassenden Angriff auf Infrastruktur, Systeme oder Applikationen zu starten, nachgelagerte Sicherheitsmaßnahmen auszuhebeln und sich zu Sabotage- oder Spionagezwecken bis zu den "Kronjuwelen" vorzuarbeiten. Ein Penetrationstest ermöglicht einen tiefergehenden Blick auf die Sicherheitsmaßnahmen der Organisation und eine umfassendere Bewertung des IT-Sicherheitsniveaus als zum Beispiel eine Sicherheitsanalyse.

LL12NT04a
©

Ein SAP-Security-Audit muss zahlreiche Aspekte berücksichtigen. Bild: TÜV Rheinland

Erfahrene Security-Analysten setzen bei Sicherheitsanalysen und Penetrationstests Tools ein, die tausende Checks automatisch durchführen. Aufgrund ihrer Erfahrung identifizieren sie auch Sicherheitslücken, die sich aus Konfigurationfehlern und selbstgeschriebenem Code ergeben. Dadurch erhalten die Security-Analysten ein realistisches Bild des Angriffspotenzials. Der Prozess verläuft in der Regel zweistufig. Bei Bedarf wird er mehrfach wiederholt, um neu gewonnene Kenntnisse in den anderen Phasen zu berücksichtigen:

1. Die Security-Analysten identifizieren Sicherheitslücken und werten sie aus. Dies wird über authentifizierte Scans der SAP-Systeme sowie des darunterliegenden Systems stark vereinfacht (White-Box-Ansatz).

2. Die Analysten nutzen die detaillierten Informationen, um mit minimalen oder ohne Berechtigungen innerhalb des Netzwerks die SAP-Systeme zu übernehmen. Dazu entzieht man dem Pen-Tester alle zuvor zugeteilten Berechtigungen. Ab diesem Zeitpunkt greift er das System unter realen Bedingungen an. Ziel ist es letztendlich, Zugriff auf mindestens einen Benutzer mit SAP_ALL-Berechtigungsprofil auf den Systemen zu erlangen. Insbesondere hierin besteht der Mehrwert eines SAP-Audits: Denn dieser Schritt ermöglicht im Anschluss die Ableitung realistischer Gegenmaßnahmen mit dem Ziel, Sicherheitslücken zu eliminieren oder auf ein für die Organisation akzeptables Maß zu reduzieren, bevor ein echter Angreifer sie ausnutzen kann.

Durchführung auf virtuellen Systemen

Wie der SAP-Penetrationstest konkret abläuft, richtet sich stets nach der IT-Infrastruktur vor Ort und der Fragestellung des Auftraggebers. Die zu untersuchenden Punkte variieren deshalb stark. Im Vordergrund stehen Aspekte wie die Aktualität der verwendeten Software, darunter Betriebssysteme und Server-Dienste, der Schutz vor Schadsoftware, die Passwort- und Benutzersicherheit oder Konfigurations- und Administrationsfehler. Die Tester prüfen die Zielsysteme auf Schwachstellen, die sich durch unsichere Architekturentscheidungen, Konfigurationen und Codes ergeben.

Um mögliche sicherheitsrelevante Schwachstellen zu ermitteln, nehmen die Tester in der Regel zunächst bei den Diensten des Server-Plattform einen authentifizierten Schwachstellen-Scan mit möglichst hohen Berechtigungen vor. Eine weitere Maßnahme ist der authentifizierte Schwachstellen-Scan des SAP-Applikations-Servers über RFC (Remote Function Call). Die Analyse erfolgt auf den Ebenen der Systemhärtung, Anmeldesicherheit, SAP-Basis-Berechtigungen, Patch-Level, Sicherheit der RFC-Schnittstellen, Betriebssystem-Sicherheit, Log-Analyse und des Quellcodes im Kundennamensbereich.

Den eigentlichen Penetrationstest der Systeme führen Security-Analysten manuell durch. Dies ist der eigentliche Mehrwert, denn nur Security-Analysten (statt automatisierter Tools) können die im Rahmen von Vulnerability Scans ermittelten Informationen im Kontext des Kundensystems und auf Basis der bisherigen Projekterfahrung wirklich bewerten. Gleiches gilt für den ABAP-Code-Review: Hier liegt der Fokus auf der manuellen Analyse und Bewertung auffälliger Codestellen.

Die Tester führen den Penetrationstest und die authentifizierten Schwachstellen-Scans meist ohne gültige Benutzerkennung ausgehend vom internen Büro-Netzwerk durch. Zur Umsetzung nutzen sie virtuelle Systeme, die man auf Standard-Client-Systeme kopiert und dort startet. Dieses Vorgehen hat den Vorteil, dass die Tester so nur auf Kundenrechnern arbeiten und während des Tests anfallende Daten nicht das Unternehmensnetzwerk verlassen. Technische Voraussetzung dafür ist genügend Arbeitsspeicher, ausreichender Plattenplatz und BIOS-Einstellungen, die die Virtualisierung erlauben. Der Auftragnehmer stellt dabei die virtuellen Systeme bereit und scannt sie vor ihrem Einsatz nochmals auf Malware.

Zur Anmeldung an den Standard-Client-Systemen stellt der Auftraggeber personalisierte Windows-Benutzer bereit, die sich an den SAP-Systemen im Geltungsbereich anmelden können. Des Weiteren stellt er einen technischen SAP-Benutzer bereit, der eine spezielle Rolle zur Durchführung des authentifizierten Schwachstellen-Scans erhält. Diese Rolle ist sehr eng gefasst und beinhaltet so wenig Berechtigungen wie möglich, insbesondere fast keine Schreibberechtigungen.

Kritikalität bewerten

Die Tester ordnen die Ergebnisse den zuvor definierten Risiko-Klassen zu. Dies erfolgt ausschließlich aus der Perspektive der IT-Sicherheit, mit Blick auf Systeme und Daten im Geltungsbereich. Risiken bezogen auf Geschäftsprozesse des Unternehmens lassen sich daraus nicht unmittelbar ableiten. Angesichts der Abhängigkeit der Geschäftsprozesse von der IT sollte hier allerdings eine enge Abstimmung zwischen den Abteilungen Risiko-Management und interner IT erfolgen.

Die Bewertung der Kritikalität orientiert sich daran, welche Auswirkungen die ermittelten Schwachstellen auf die IT-Sicherheit der Systeme oder Daten haben können, inwieweit die Findings von Best Practices der IT-Sicherheit abweichen und inwiefern es sich um Vorbedingungen für einen Cyberangriff handeln könnte. Basis sind Standards wie der IT-Grundschutz des Bundesamtes für Sicherheit in der Informationstechnik (BSI) sowie die ISO/IEC-Standards 27001:2013 und 27033:2010.

Einteilung in verschiedene Risikokategorien

In der Regel ordnet man die Ergebnisse in die Kategorien "Hohes Risiko", "Mittleres Risiko", "Niedriges Risiko" und "Empfehlungen" ein: Bei der Klassifizierung "Hohes Risiko" weisen die Schutzmaßnahmen zur Aufrechterhaltung der Vertraulichkeit, Integrität und oder Verfügbarkeit der betroffenen Systeme oder Daten erhebliche Defizite auf. Die identifizierte Schwachstelle hat erhebliche Auswirkungen auf die IT-Sicherheit der betroffenen Systeme oder Daten und lässt sich leicht für einen Angriff ausnutzen. Best Practices der IT-Sicherheit sind nicht oder nur in geringem Umfang umgesetzt. Einige Beispiele für "Hohe Risiken" sind:

  • länger nicht eingespielte Patches, was unter anderem dazu führen kann, dass Systemzugriffe ohne gültige Benutzerkennung oder sogar das Ausführen von Befehlen als (unautorisierter) SAP-Service-Benutzer möglich wird;
  • die Mehrfachverwendung von Passwörtern für technische Benutzer auf unterschiedlichen Ebenen, sodass ein unsicheres SAP-System potenziell administrativen Zugriff auf weitere SAP-Systeme erlaubt und damit gegebenenfalls die Manipulation geschäftskritischer Daten ermöglicht;
  • Dienste der SAP-Applikations-Server, die unverschlüsselt kommunizieren. Die mögliche Folge: Jede Anmeldung an den betroffenen Diensten ermöglicht einem Angreifer in einer "Man in the Middle"-Position den Zugriff auf die Benutzer-Session sowie potenziell das Mitschneiden gültiger Anmeldedaten. Auch dies birgt die Gefahr von Datendiebstahl oder -manipulation.

"Mittlere Risiken" sind zum Beispiel:

  • Auf bestimmten Systemen ist auf technischer Ebene kein durchgängiges Vier-Augen-Prinzip umgesetzt. Dies kann bei Wirtschaftsprüfungen ein Problem sein, da das Risiko eines wirtschaftlichen Schadens durch Innentäter besteht, der unter Umständen nicht sofort auffällt.
  • Zwischen dem internen Büro-Netzwerk und den SAP-Systemen beschränkt die Firewall den Zugriff nur ungenügend, was die Verwundbarkeit administrativer Dienste deutlich erhöhen kann.

"Geringe Risiken" gehen von Schwachstellen aus, die die IT-Sicherheit der Organisation kaum beeinträchtigen, zum Beispiel Passwörter, die nicht den gängigen Anforderungen an die Passwort-Sicherheit entsprechen. Beim "Empfehlungen" schließlich handelt es sich um Optimierungen der Sicherheitssituation, ohne dass ein konkretes Risiko vorliegt, zum Beispiel die Einrichtung einer zusätzlichen Zutrittskontrolle zu den Büroräumen abseits des Empfangs.

Fazit: Wirksame Gegen-maßnahmen möglich

Das SAP-Audit bildet den aktuellen Zustand der SAP-Systeme ab und ist eine gute Grundlage, um die SAP-Sicherheit mit dem Risiko-Management zu vereinen. Security-Analysten sprechen Empfehlungen aus, was es dem Anwenderunternehmen ermöglicht, die relevanten Sicherheitslücken zu schließen. Das SAP-Audit legt offen, inwieweit der Angreifer in die Infrastruktur vordringen und in welchem Ausmaß er die Organisation schädigen kann. Es ist auch das Mittel der Wahl, wenn es darum geht, das Sicherheitsbewusstsein innerhalb der Organisation zu steigern oder dem Management einen tieferen Einblick in die tatsächlichen Risiken eines Unternehmens zu geben.

Ein Bericht fasst die jeweiligen Ergebnisse zusammen. Enthalten kann ein solcher Bericht kritische Gefährdungen durch Berechtigungen, Kommunikationsschnittstellen, Custom-ABAP-Code, bekannte SAP-Softwarefehler oder Fehlkonfigurationen. Daneben beinhaltet er "Proofs of Concept" für die Ausnutzbarkeit der kritischen Gefährdungen. Ein guter Bericht zeichnet sich dadurch aus, dass die Inhalte für die IT-Abteilung wie auch für das Management nachvollziehbar sind, das auf dieser Basis eventuell Budget- oder Investitionsentscheidungen zu treffen hat. Ziel muss es sein, Transparenz zu schaffen und die Awareness im Management zu erhöhen.

Der eigentliche Mehrwert der Analyse besteht darin, aus den Ergebnissen wirksame Gegenmaßnahmen abzuleiten, um die Sicherheit der Organisation dauerhaft zu steigern. Dabei stehen kritische Risiken und schnell umsetzbare Verbesserungen ("Quick Wins") im Vordergrund. Auftraggeber sollten sich nicht mit einer Auflistung rein technischer Ergebnisse zufriedengeben. Vielmehr sollten sie Wert darauf legen, dass der Tester mögliche strukturelle Ursachen wie etwa fehlende oder inkonsistente Prozesse und Verantwortlichkeiten aufzeigt und Empfehlungen abgibt, wie sich die Sicherheitsprobleme lösen lassen.

Es hat sich bewährt, die Ergebnisse im Rahmen eines Workshops zu besprechen. Hier lassen sich Fragen zu Kritikalität, Risikobewertung und Priorisierung klären und Empfehlungen des Dienstleisters für wirksame Gegenmaßnahmen eingehend erörtern.

Externe Anbieter können wertvolle Unterstützung leisten, wenn es darum geht, Maßnahmen und Risiken auf Basis der Findings detailliert zu begründen und diese in einen größeren Bedrohungszusammenhang einzuordnen.

Wichtig: Sicherheitsprüfungen wie diese SAP-Audits sind immer eine Momentaufnahme. Sowohl die Angriffe als auch die getestete Infrastruktur oder Anwendung entwickeln sich weiter, sodass die Ergebnisse eines Audits mit der Zeit an Wert verlieren. Daher ist es ratsam, solche Tests regelmäßig durchzuführen. Dabei muss man nicht immer alle Aspekte testen, sondern kann sich eventuell auf die Änderungen konzentrieren. Nach spätestens zwei Jahren ist jedoch in der Regel ein erneuter kompletter Test sinnvoll.

Otto von Natzmer ist Security-Analyst beim TÜV Rheinland, www.tuv.com.

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Das könnte Sie auch interessieren

Kopf nicht in den Sand
Radware erhöht DDoS-Abwehrleistung deutlich
Informationen verknüpfen für die Gefahrenabwehr

Verwandte Artikel

Bedrohungserkennung

SAP

Threat Detection