Der Eckstein einer jeden SAP Security Strategie ist der Security Audit Log. Es sollte das Kernstück einer jeden SAP Security Strategie sein.
Dieser Log ist von SAP so implementiert worden, dass er alle sicherheitsrelevanten Protokoll-Einträge, von falscher Passwort-Eingabe über externen RFC-Aufrufe bis hin zu Manipulationen an Transaktionen via Debugger, in eine Datei auf dem SAP-Server mitprotokolliert. Dieser Audit-Log sollte immer angeschaltet sein, denn er ist die Grundlage, um aus diesen Einträgen sicherheitskritische Situationen (SIEM – Security Incident Events) zu extrahieren.
Event basiertes Security-Logging
Es gibt mehrere Dutzend Events, die so aufgezeichnet werden. Eine komplette Liste der Events sowie eine detaillierte technische Beschreibung gibt es auf dem sehr guten Blog von Frank Buchholz bei der SAP (Link im Nachgang zu diesem Artikel)
Das Fortschreiben dieser sicherheitsrelevanten Einträge und deren Analyse steht auch immer wieder auf der Forderungsliste von SAP-Auditoren und Revisoren und auch im Nachgang als Ergebnis aus SAP Penetration Tests. Denn viele dieser Angriffsvektoren sind eindeutig im SAL zu identifizieren. Deshalb kommt diesem auch eine Schlüsselrolle bei SAP-Abwehrstrategien zu.
Ein weiterer Stolperstein auf dem Weg zu mehr SAP Security ist aber auch der deutsche Datenschutz (dieser Faktor spielt außerhalb Deutschlands eine geringere Rolle). Man muss nämlich festlegen, welche Events und welche Benutzergruppen protokolliert werden sollen.
Umfang des Loggings festlegen
Analysten und SIEM-Spezialisten werden sofort sagen, dass alle Events für alle Benutzer protokolliert werden müssen. Denn nur so kann man auch statistische Methoden und SIEM-Systeme verwenden, um verhaltensbasierte Auffälligkeiten und untypische Zugangsmuster erkennen. Dies widerspricht aber in vielen Einzelheiten der Auffassung von Betriebsrat und Datenschutz.
Allerdings muss auch dagegen abgewogen werden, dass man nicht Benutzer überwacht, sondern kriminelle Muster finden will. Hier ist eine eindeutige Abwägung zu treffen, die auch die Gegenüberstellung von persönlichem Schutz, Firmenbelange und Straftatbestände (die auch Betrug einschließen) einschließt.
Obwohl an einer kompletten Protokollierung in Zeichen von Angriffen organisierter Kriminalität, Staatsspionage und interner Sabotage kein Zweifel an einer kompletten Erfassung der Sicherheits-Situation bleiben sollte, kann man als Kompromiss alle Events kritischer Benutzergruppen (System, Administratoren und SAP Poweruser) mitschreiben. Auch hier kann man schon einigermaßen gut kritische Events und Muster isolieren.
Security Audit Log im SAP System aktivieren
Der Security Audit Log (SAL) muss allerdings in vielen Releases noch manuell aktiviert werden. Dies muss über einen Schalter in den SAP-Konfigurationen geschehen. Danach (nach einem Neustart des Systems) beginnt das SAP-System, die eigenen Security Events zu protokollieren.
Jetzt beginnt aber der wohl kritischste Teil der Betrachtungen zu der Frage, wie ein Konzept zur Sicherheitsüberwachung mittels SAP Security Audit Log umgesetzt werden kann.
Es ist die Frage, wer und in welcher Häufigkeit diese Events kontrolliert. Denn in einem einzigen System mit mehreren hundert bis zu tausenden Benutzern tauchen Hunderte von Security Events auf, von informell bis kritisch eingestuft. Selbst wenn man nur ein System manuell überwacht, hat der Sicherheits-Betreuer eines SAP-Systems mehrere Hundert Events pro Tag zu analysieren, zu bewerten, zu verfolgen und anschließend zu dokumentieren. Aber auch die Frage nach der Dauer der Aufbewahrung ist im Sinne von betrieblichen Belangen und EUDSGVO zu klären.
SAP Security und das Security Operation Center (SOC)
In großen Firmen mit mehreren tausend Benutzern gibt es dazu das Konzept des „Security Operation Centers“ (SOC). Hier sitzen konstant mehrere Mitarbeiter, meisten an Konsolen zum Security Information Event Management (SIEM) wie splunk. Hier laufen die meisten sicherheitsrelevanten Informationen zusammen, meisten gespeist aus email-Überwachung auf Trojaner und Malware oder die Überwachung von Server-Logfiles. Die Überwachung von SAP ist hier noch sehr selten vertreten, aber der Security Audit Log wäre das erste und wichtigste Element für die SOC-Integration.
Wir haben verschiedene Varianten bei Kunden in den letzten Jahren implementiert:
Einige haben eine Schnittstelle zu splunk bzw. Arcsight oder QRadar jeweils über den SolMan integriert. Das war 2-3 Wochen Programmierung (ABAP) im SolMan und die jeweiligen Dashboards auf der anderen Seite. Klassische SIEM-Systeme sind häufig in der IT Security jenseits der SAP-Systeme zu finden, aber alle haben Partnerschaften mit der SAP.
Von SolMan aus werden die Logs aus den SAP-Systemen ausgelesen und per ODATA/REST-Schnittstelle (Web) repliziert. Das können alle SIEMs gleich gut.
Es hängt auch davon ab, wieviele Use Cases man live nehmen will. Weder splunk noch ArcSight noch QRadar haben signifikante SAP Controls im Standard, die muss man alle erstellen. Da ist viel Abstimmung, Projekt und Diskussion über SIEM, Standards und Log Files. Ein großer Kunde hat SecurityBridge von ABAP Experts, das ist ebenfalls ein sehr interessantes SAP SIEM.
Das SAP ETD ist die Königsdisziplin im Bereich SAP SIEM und ist hervorragend geignet für komplexe Auswertungen, APT Detection und Forensik. Viele SIEM-Systeme decken Basis-Funktionalität ab, aber wenige erreichen die Komplexität und Tiefe des ETD. Als reiner Schnittstellen-Lieferant ist das ETD aber überdimensioniert und unterfordert.
Wie diese Positionierung aus Sicht des SAP ETD aussieht, hat Martin Müller von der SAP in einem guten Blog beschrieben (Link siehe unten)
Aber für alle Lösungen gilt: Ohne dedizierte Personen, die sich um SAP Security Vollzeit kümmern, gehen alle technischen Lösungen ins Leere.
Meistens ist an diesem Punkt die Projektdiskussion „SAP Security Audit Log“ zu einem deutlichen Halt gekommen.
Allerdings führt an der Einführung einer solchen Verantwortlichkeit, einer solchen Ressource, kein Weg daran vorbei.
Aktuelle IT-Security Bedrohungslagen nicht unterbewerten
Um ein aktuelles Beispiel potentieller Bedrohungslagen zu zitieren, die ich direkt mit betreut habe: Zwischen dem 16. Dezember und Anfang Januar hatten wir (als „kleines“ SAP-Sicherheitsunternehmen) zwei bestehende Kunden und drei neue Kunden, die uns um sofortige Hilfe baten, da alle ihre Server von Ransomware betroffen und verschlüsselt waren, einschließlich eines vollständigen Cloud-Rechenzentrums. Dies hat bis zu 180 SAP-Server als „Kollateralschaden“ der Festplattenverschlüsselung zur Folge. In einem Fall war auch der gesamte Backup durch Trojaner unbrauchbar gemacht.
Und auch in den den aktuellen „Corona-Zeiten“ mit der massiven Verbreitung von „Homeoffice“ und Remote-Workload wird das Thema interner Bedrohung ein sehr wichtiges Element, das es zu kontrollieren und zu überwachen gilt. Hier erhöhen sich auch gerade die internen Angriffsvektoren.
Kann man dies im SAP Security Log sehen ? Ja, denn man kann den Übergang vom klassischen Netzwerk auf die SAP-Server sowie die Muster, mit gestohlenen Passwörtern Nutzer zu übernehmen können, durch forensische Analyse zusammen mit einem SIEM-System wie dem ETD und anderen sehen.
Das bedeutet, zum einen das Security Audit Log aktiv und überwacht zu haben und an ein zentrales SIEM System angebunden. Man hätte die Auffälligkeiten festgestellt und den Schaden durch die Ransomware minimieren können, wenn man parallel dazu ein sicherheitskritisches Zonenkonzept mit Risiko-Verteilung implementiert hätte.
Denn auch ein SOC und die Log File Überwachung ist ein passives Element. Es muss direkt korrespondieren zu einem Zonen-Konzept des Unternehmensnetzwerkes, das Benutzer-Geräte und Clients separiert, aber auch Test- und Produktivsysteme trennt sowie ein spezielles Administrator-Netzwerk-Segment hat., Nur so lässt sich im Ernstfall eine flächendeckende Verschlüsselung aller Systeme verhindern.
Direkte Auswertung des Logs
Wie man an diesem Beispiel sieht, ist der SAL der Eckstein, auf dem die anderen, ebenso wichtigen Elemente (Netzwerk-Trennung, SIEM-Analyse, Security Operation Center) aufbauen.
Denken Sie immer noch daran, dass dies Ihr Unternehmen nicht treffen wird? Dann sollte wenigstens damit begonnen werden, dass SAP Security Audit Log anzuschalten und die Events zeitnah zu protokollieren. Und wenigstens eine Ressource im Unternehmen zu haben, die sich diese Logs ansieht.
Weiterführende Informationen
Das Buch SAP Security (siehe rechte Leiste, Kapitel 14)
Der SAP-Blog von Frank Buchholz
Blog von Martin Müller (SAP) zum Thema Enterprise Threat Detection und SIEM