Suchen

Mehr Sicherheit durch SIEM-(In)fusion SAP – der blinde Fleck im Security Operations Center

Autor / Redakteur: Andreas Mertz / Ulrike Ostler

Kann es das geben? Obgleich SAP-Systeme in höchstem Maße kritisch für das Kerngeschäft von Unternehmen sind, verkörpern noch immer den „Blinden Fleck“ im IT-Security Monitoring. Mache Sie einmal einen Reality Check: Wie sicher sind Ihre SAP-Anwendungen wirklich?

Firmen zum Thema

Kaum zu glauben: IT-Security deckt kritische Anwendungssysteme allzu oft nur unzureichend ab.
Kaum zu glauben: IT-Security deckt kritische Anwendungssysteme allzu oft nur unzureichend ab.
(Bild: IT-Cube)

Aufgrund ihrer Bedeutung, Informationsdichte, Komplexität, Architektur und ihres Schwachstellenpotenzials unterliegen sie einer besonderen Kritikalität. Kein Wunder also, dass allein die enorme Informationsdichte die SAP-Systeme in den Fokus vieler „Interessenten“ rückt: staatlich subventionierte Industriespionage, aggressive Wettbewerber, korrupte Angestellte sind hier die Stichworte.

Denn in keinem anderen IT-System werden geschäftskritische Informationen derart konzentriert verfügbar gehalten:

  • FI: Finanzdaten, Kennzahlen, Planungszahlen, etc.,
  • HR: Personaldaten, Gehälter, Kontendaten,
  • PLM: Geschäftsgeheimisse, Entwicklungsmuster, Rezepturen,
  • SRM: Preislisten, Einkaufspreise, Ausschreibungen, Angebote,
  • CRM: Kundendaten, Umsätze, Opportunity Pipe, Forecasts.

SAP-Systeme in Großkonzernen sind hochkomplexe IT-Landschaften, die unterschiedlichste Technologien bündeln, zum Beispiel Applikations-Server, Datenbanken, Middleware, Web-Server, Betriebssysteme und Identity-Management-Systeme. Diese Komplexität verursacht oft gravierende Kompromisse zu Lasten der IT-Sicherheit. Zum Beispiel kann der Zugriff von SAP-Systemen auf externe Datenquellen als bidirektionaler Datenaustausch zwischen SAP und JDBC-konformen (Java Database Connectivity) RDBMS-Systemen (RDBMS = Relational Database Management) erfolgen.

Problematisch wird es, wenn beispielsweise SCADA-Systeme (SCADA = Supervisory Control and Data Acquisition) am selben RDBMS angekoppelt werden. Eine so geschaffene intrinsische Vertrauensbeziehung lässt sich leicht manipulieren, um Zugriff aus einem mit Schwachstellen behafteten SAP-System in ein SCADA-Netz und somit auch ein Einfallstor für Sabotageakte zu ermöglichen.

SoD-Checks greifen nicht!

Bildergalerie
Bildergalerie mit 6 Bildern

Eine weitere Ursache für die immanente Security-Schwäche von SAP-Systemen liegt im allgemeinen Verständnis von IT-Sicherheit. In den vergangenen Jahren hat sich ein ganzer Industriezweig etabliert, um historisch gewachsene Berechtigungssysteme und Prozesse zu auditieren. Kontrollmaßnahmen, Prüfungsintervalle, Kontrollkalender und Verantwortlichkeiten werden im GRC-Management ( GRC = Governance Risk Compliance) des Unternehmens abgebildet.

Zweifellos ist die Prüfung von SoDs (Segregation of Duties) ein wesentliches Element im internen Kontrollsystem, aber sie helfen nicht die Penetration einer technischen Schwachstelle zeitnah zu erkennen und bei der Alarmierung. SoD-Checks greifen nicht, wenn der Angreifer gar keinen User-Account benötigt, um in Systeme einzudringen.

Lesen Sie 'mal das Passwort!

Beispielsweise kann die Kopplung eines SAP-Applikations-Servers und einer Oracle-Datenbank zu penetrierbaren Schwachstellen führen (vgl. SAP Security Note #1623922). Hat ein Angreifer Zugriff auf Netzwerk und Datenbank, so kann er ohne weitere Authentisierung die UserID und das verschlüsselte Passwort aus der SAP-User Tabelle lesen und das Passwort mit Hilfe der passenden Bibliothek entschlüsseln.

Im Ergebnis hat er mit diesen Anmeldedaten Vollzugriff auf alle Datenbankobjekte. Dort angekommen kann er für beliebige SAP-Accounts den Passwort-Hash austauschen. Noch einfacher wird es für den Angreifer, wenn er auf technische Accounts mit fest-codierten Passwörtern trifft, die für Backup, Replikation und Synchronisation der Datenbanken verwendet werden.

Programmierfehler sind Fallen

Auch Programmierfehler sind die Wurzel vieler Schwachstellen. Das trifft uneingeschränkt auch für den ABAP-Code zu. Beim Standardcode steht SAP in der Pflicht, diese zu finden, zu veröffentlichen und zu beheben.

Die in den letzten drei Jahren deutlich gestiegene Anzahl der SAP-Security Notes zeigt, dass der Hersteller sich dieser Verantwortung stellt. Dennoch sind Schwachstellen in SAP hinsichtlich ihrer Kritikalität anders zu bewerten als zum Beispiel eines „Windows Server 2008“. Der Grund dafür ist, dass SAP®-Applikationen fast immer kundenspezifisch angepasst werden und dabei schnell 2-3 Millionen Code-Zeilen zusammenkommen.

Bildergalerie
Bildergalerie mit 6 Bildern

Unsauber programmierter Code ist oft die Regel und die daraus häufig resultierenden Schwachstellen ermöglichen:

  • Directory Traversal Attacks − Lesen und Schreiben beliebiger Daten auf dem Application Server, was zu unmittelbarer Verletzung von Vertraulichkeit, Integrität und Verfügbarkeit führen kann,
  • ABAP Command Injections − Ausführung von Befehlen zur Laufzeit welche durch Benutzereingaben ausgelöst werden
  • Aufruf beliebiger RFC-fähiger Funktionen, die eine ungeahnte Anzahl Angriffsvektoren bergen − in SAP NW7.01 ECC gibt es über 33.000 Funktionen.

Schwache Bereinigung der Schwachstellen

Ein weiteres Risiko birgt die mangelhafte Schwachstellenbehebung. Da SAP-Systeme geschäftskritische Daten speichern und verarbeiten, verursacht jede Abschaltung signifikante Kosten. Ungeplante Ausfälle infolge fehlerhafter Patches sind kaum tolerierbar.

Oft sind daher die mit dem SAP-Betrieb betrauten Mitarbeiter nicht Willens, das Ausfallrisiko zu tragen und spielen Sicherheits-Patches zeitverzögert oder gar nicht ein. Das führt in einigen Fällen dazu, dass Schwachstellen über Jahre hinweg existieren.

Lauernde Gefahren

Eine weitere große Unbekannte ist das Potential unentdeckter Gefährdungen, denn im Vergleich zu Web-Servern oder Windows Domain Servern sind SAP-Systeme bisher kaum nennenswert von einer weltumspannenden „Cracker-Gemeinde“ durchgängig penetriert und analysiert worden.

Es gibt eine Reihe von Ereignissen in SAP, die im laufenden Betrieb passieren und die in der Konsequenz ernsthafte Bedrohungen darstellen, Was sind die Wichtigsten im SAP Umfeld? (siehe: Abbildung 2):

  • Passwort Sniffing in Kommunikationsbeziehungen die das DIAG-Protokoll nutzen,
  • Aktivierung des Debugging auf Qualitätssicherungs- und Produktivsystemen,
  • Aufruf von Betriebssystemkommandos über SAPXPG,
  • Ausführung von Diensten durch SAP®-Web-Server ohne weitere Authentisierung,
  • Unbeschränkter Systemzugriff durch externe Programme über das SAP®-Gateway,
  • Aufruf von Funktionsbausteinen per SOAP RFC Service.

Alle diese Ereignisse betreffen den kaum überwachten Business Runtime Layer („Netweaver“/Basis). Sie führen zu Informationsdiebstahl, Datenmanipulation, Missbrauch und Sabotage und tragen zu ungleich höheren Risiken als SoD-Verletzungen bei. Um Angriffe auf dieser Ebene zu entdecken, bedarf es einerseits der lückenlosen und vollständigen Erfassung aller sicherheitskritischen Ereignisse sowie Parameter und andererseits der Kontinuität durch eine permanente Abfrage.

Beides lässt sich nur durch Automatisierung erreichen. Was aber gehört ins Monitoring?

Monitoring-Aufgaben

Um Risiken zu minimieren und Gefahren zu erkennen, müssen Daten aus Log-Dateien, Tabellen und Profil-Parameter erfasst, korreliert und gegen Policy-Vorgaben geprüft werden. Aber es wäre zu kurz gedacht, die SAP-spezifischen Parameter und Ereignisse im SIEM für sich allein zu betrachten.

Denn SAP-Systeme existieren nicht im Vakuum. Durch Cross Device / Cross Event – Korrelation lassen sich SAP-Events mit denen aus der übrigen Systemlandschaft in Beziehung setzen. Zum beispiel lässt sich so herauszufinden, welche Accounts in SAP existieren / benutzt werden, die nicht im DS (Directory Service) / IM (Identity Management) vorkommen. Das Bild wird vollständiger und False Positives können reduziert werden (siehe: Abbildung 3).

Holistisch versus Tool-Zoo

Befragt man Unternehmen zu den eingesetzten Security-Werkzeugen, so trifft man auf oft einen ganzen Tool-Zoo, dessen Bestanteile jedoch oft nur Teilaspekte der IT-Sicherheit für ein oder mehrere SAP-Systeme abdecken. „SAP GRC Access Control“ beispielsweise hilft bei der Definition und Implementierung eines Rollenkonzeptes und unterstützt auch beim Monitoring oder dem Audit von Berechtigungen in den Systemen sowie der Nutzung von Notfallusern. Leider ist es nicht geeignet, um Quellen wie SAL, System Log, System Parameters, Gateway Log, Table Logging auszulesen oder etwa technische Konfigurationsparameter zu prüfen.

Bildergalerie
Bildergalerie mit 6 Bildern

Die Prüfung der Konfigurationseinstellung gegen Policy-Vorgaben, zum Beispiel Passwort-Richtlinien oder SAP-Gateway-Vorgaben, kann teilweise mit dem „SAP-Security Optimization Service“ geprüft werden. Für das Code Scanning existieren ebenfalls verschiedenen Lösungen am Markt.

Mit dem Report „RSECNOTE“ kann eine Übersicht offener und bereits implementierter Security Patches ausgegeben werden. Transaktions-Monitoring, also die Überprüfung etwa der Einhaltung von Workflows und Vorgaben zu einzelnen Geschäftsprozessen beispielsweise sind immer kundenspezifisch und auch hier existieren Punktlösungen, die das Monitoring einzelner Prozesse erlauben.

Das Wurmloch in der Erfassung

Keine der aufgeführten Lösungen verfolgt jedoch den Ansatz, zeitnah sicherheitsrelevante Ereignisse und Parameter der gesamten SAP-Landschaft zu erfassen, geeignet aufzubereiten und in einen Workflow zur Problemanalyse und -beseitigung (Remediation Life Cycle) zu überführen. Dabei wären SIEM-Systeme prädestiniert als Security Cockpit auch für SAP-Landschaften in die Überwachung einzubeziehen.

Um die enorme Anzahl sicherheitsrelevanter Ereignisse auswerten zu können, kommen heute in den meisten größeren Organisationen derartige SIEM-Systeme ohnehin zum Einsatz. SIEM-Lösungen können Analyse und Korrelation von Sicherheitsereignissen in Echtzeit mit Logdatenaufkommen von 75.000 Events Per Second (EPS) und mehr automatisiert durchführen.

Sie geben Sicherheitsspezialisten einen Überblick zu aktuellen Bedrohungen und ermöglichen Trendanalysen und forensische Vorfalluntersuchungen. Durch Erfassung, Normalisierung, Aggregation und Korrelation der Log-Events unterschiedlicher Systeme verschiedener Hersteller (Cross-Device & Cross-Vendor Data) können aus Zehntausenden von Events diejenigen identifiziert werden, die eine tatsächliche Bedrohung kritischer Anwendungen und Daten darstellen. Was spricht dagegen, diese intelligenten Systeme nicht auch für SAP zu nutzen?

SIEM – zentrales Fenster in die IT-Sicherheit

Aus dem Bereich Netzwerk-Sicherheit kommend, unterstützen heute alle führenden SIEM-Hersteller, etwa HP mit “HP Arcsight“, IBM mit “QRadar“ und McAfee mit “Nitro“, „Log Rhythm“, die Integration mehrerer hundert gängiger Produkte aus Network, Device und Database Layer. Vielen Unternehmen, die substanzielle Investitionen in SIEM Systeme getätigt haben, ist das jedoch zu kurz gedacht:

Was fehlt, ist die Integration geschäftskritischer Anwendungen, insbesondere der ERP-Systeme ( wie von SAP, Oracle, Peoplesoft, Microsoft) ins zentrale Security Management. Die Lücke ist umso gravierender, da die etwa mit Firewalls, Proxies, Intrusion Prevention Systemen abgesicherten Perimetergrenzen durch Mobile Access, WLAN, Cloud Computing und Internet-Portale durchlässiger geworden sind.

Die gängige Aussage: „Unsere SAP Systeme stehen in geschützten Umgebungen“ ist so in vielen IT-Umgebungen nicht länger zutreffend. Die Applikationen und die darin verarbeiteten und gespeicherten Daten müssen zunehmend als zu schützendes Asset betrachtet werden (siehe: Abbildung 4).

Blind-Spots im Security Monitoring

Ein prinzipielles Problem der Integration sicherheitsrelevanter Ereignisse aus SAP-Landschaften in SIEM Systeme ist das Fehlen einer einheitlichen Schnittstelle in SAP. Die abzufragenden Informationsquellen in SAP liegen verstreut und nutzen unterschiedliche Formate und Schnittstellen.

Bildergalerie
Bildergalerie mit 6 Bildern

Das hatte bisher zur Folge, dass SIEM-Produkte allenfalls in der Lage waren, das SAL (SAL = Security Audit Log) zu lesen. Leider stellen die im SAL enthaltenen Informationen keine hinreichende Basis für eine objektive Vorfallbewertung da. So ist es beispielsweise möglich, Berechtigungsänderungen an Benutzern zu detektieren, jedoch ist aus dem SAL nicht ersichtlich was geändert wurde; siehe: Log-Ausgabe SAL versus Agile SI bei SAP_ALL-Profilerweiterung:

SAL-Message: Authorizations for User D.OWNLOAD ChangedagileSI-Message: BNAME="D.OWNLOAD" ACTION="Profile added" OLD_VAL="" OLD_TEXT="" NEW_VAL="SAP_ALL" NEW_TEXT="All SAP System authorizations"

Korrelationsregeln, grafische Aufbereitung oder Berichte, die sich am DSAG-Prüfleitfaden orientieren, gab es von keinem einzigen SIEM-Hersteller. Hier liegt die Herausforderung in dem hochgradig interdisziplinären Wissen, was nötig ist um die SAP-SIEM-Lücke zu über-winden. Da SAP lediglich eine von typischerweise 250 bis 400 unterstützten Ereignis-Quellen (Devices) für das SIEM darstellt ist, kann SAP-Security Know-how nicht unbedingt als Kernkompetenz der SIEM-Hersteller vorausgesetzt werden.

Hier kommt das Know-how der Systemintegratoren ins Spiel, die beide Welten beherrschen und in der Lage sind, Antworten auf folgende Fragen zu liefern :

  • Wo liegen in SAP die Informationen?
  • Wie müssen die Informationen interpretiert werden?
  • Wie und wie oft können diese extrahiert werden?
  • Wo liegt das Optimum der Intervalle in Hinblick auf Security und Logvolumen?
  • Wie müssen die Daten aggregiert und formatiert werden?
  • Welche neuen Variablen und Kategorisierungen müssen im SIEM eingeführt werden?
  • Wie müssen die Daten im SIEM zur Interpretation aufbereitet werden?

Security Intelligence – vom Buzzwort zur Realität in drei Schichten

Der zentrale Ansatz für eine intelligente Verarbeitung sicherheitsrelevanter Ereignisse basiert auf Echtzeitauswertung und der Integration mit marktführenden SIEM-Produkten. Mit einer simplen 3-Ebenen-Architektur, bestehend aus Agenten, Middleware und SIEM ließe sich ein hochflexibles, adaptier- und erweiterbares Monitoring-Framework, mit dem auch kundenspezifische SAP-Tabellen und Transaktionen überwacht werden können, realisieren:

Die Agenten extrahieren kontinuierlich alle benötigten Informationen aus SAP-Systemen und werden zentral konfiguriert und gesteuert. In der Middleware erfolgen Vorverarbeitung und Übergabe in einem standardisierten Format an das jeweilige SIEM-System. Die Administration von Core und Agenten könnte über ein zentrales Web-(Dynpro)-Frontend erfolgen. Im SIEM finden Kategorisierung, Korrelation, Bewertung der Kritikalität, Visualisierung, Notification und Alerting sowie das Reporting statt (siehe: Abbildung 5).

Die in Dashboards aus Grafiken, Tabellen und Alarmanzeigen dargestellten Informationen müssen sich an allgemeingültigen Metriken der IT-Sicherheit, zum Beispiel Severity und Risk Level orientieren, um auch für ein SOC-Team ohne SAP-Expertenwissen interpretierbar zu sein. Gleichzeitig ist es wichtig, die SAP-Terminologie so beizubehalten, dass die Berichte als Nachweis im Rahmen von Audits verwendet werden können (siehe: Abbildung 6).

Agile SI – 360 Grad SAP-Security Monitoring von IT-Cube

Seit 2012 ist mit „Agile SI“ eine automatisierte und SAP-zertifizierte Lösung am Markt, die kontinuierlich ganze SAP-Landschaften scannt und dabei unter anderem Schwachstellen in Systemkonfigurationen, Fehler in Zugriffsrechten, SoD-Verletzungen, Manipulationen in kritischen Transaktionen und verdächtige Aktivitäten privilegierter Benutzer im SIEM aufbereitet darstellt. Die Software ist mit HP/ArcSight ESM, IBM/QRadar, LogRhythm, LogPoint und Splunk integrierbar und unterstützt alle gängigen und in Mainstream Maintenance befindlichen Versionen der SAP Enterprise Suite von NW 7.01 und neuer.

Andreas Mertz ist Gründer und Geschäftsführer bei IT-Cube. Das Unternehmen bietet mit "Agile SI" ein derzeit gefragtes Security-Tool für SAP-Anwendungen an.
Andreas Mertz ist Gründer und Geschäftsführer bei IT-Cube. Das Unternehmen bietet mit "Agile SI" ein derzeit gefragtes Security-Tool für SAP-Anwendungen an.
(Bild: IT-Cube)
Die Implementierung erfolgt durch Einspielen eines Add Ons, für das ein eigener Namensraum existiert. In puncto Sicherheit wurde darauf geachtet, dass Agile SI als eigenständiges Berechtigungsobjekt behandelt wird, per SNC kommuniziert und dafür definierte technische User verwendet.

Der Autor:

Andreas Mertz ist Gründer und Geschäftsführer der IT-Cube Systems GmbH. Der Dienstleister konzentriert sich ganz auf IT-Security-Themen.

(ID:42240767)