Gerade in großen Unternehmen mit ihren komplexen IT-Systemen ist die Implementierung eines solchen Systems keine einfache Aufgabe. Häufig mangelt es an einer strukturierten Herangehensweise oder scheitert an der Bewertung der eingehenden Meldungen in Logs. SAP-Systeme, häufig als besonders große Herausforderung erachtet, machen es tatsächlich besonders einfach, ein SIEM zu implementieren. Wir erklären im Folgenden, wie sich die Einführung oder Optimierung eines SIEM gut in den Griff bekommen lässt.
Foto: santiago silver - Fotolia.com
Ohne ein Security Information and Event Management-System ist die Suche nach sicherheitsrelevanten Ereignissen im Unternehmen wie die sprichwörtliche Suche nach der Nadel im Heuhaufen. Hunderte verschiedene Arten von Meldungen, ihr unterschiedlich häufiges Auftreten und ihre schiere Anzahl bereiten den IT-Administratoren viel Arbeit. Im SAP-Umfeld bietet SIEM hier einen einfachen Ansatz: Alle potenziell auftauchenden Meldungen sind in einer Tabelle hinterlegt. Es gibt etwa 1.500 Vorlagen für mögliche Log-Einträge. Der Umfang dieser Tabelle variiert abhängig von der Version und den installierten Modulen.
Achtung, Masse!
Eine manuelle Überprüfung jeder Meldung ist angesichts der großen Menge nicht möglich und sinnvoll. Eine adäquate Reaktion auf jeden einzelnen Event wäre nicht möglich. Würde jede Meldung automatisiert im System ein Security Event auslösen, würde die IT ihnen irgendwann nicht mehr nachgehen. Zu viele Fehlermeldungen (False Positive) wirken demotivierend. Der einzig richtige Ansatz sind generische Vorgehen und Regeln im SIEM-Umfeld: Zunächst muss ein generisches Kategorisierungs- und Klassifizierungsmodell eingeführt werden.
Erster Schritt: Kategorisierungsmodell einführen
Hierzu werden die etwa 1500 theoretischen Meldungen in folgende drei Kategorien aufgeteilt:
Typische Meldungen für Security Events (wie etwa eine fehlgeschlagene Anmeldung);
Meldungen, die regelmäßig im System auftreten;
Meldungen, die in der Vergangenheit (beispielsweise letztes Jahr) nicht aufgetreten sind
Zweiter Schritt: Meldungen nach Dringlichkeit klassifizieren
Erst im zweiten Schritt werden die Meldungen der einzelnen Kategorien (1-3) nach Dringlichkeit ("very high", "high", bis "very low") klassifiziert. Das hilft dem IT-Team dabei, die Eskalationswege und die Priorisierung zu steuern.
Beispiele, die typischerweise einen Alarm mit hoher Priorität auslösen sollten, sind etwa:
Eine Anmeldung von SAP* oder SAPCPIC - egal, ob erfolgreich oder fehlgeschlagen. Denn: Wurde ein System entsprechend gängiger Best Practice-Beispiele konfiguriert, dann ist der Account SAP* gesperrt, hat keine Rechte und sollte gar nicht erst verwendet werden können. Auch der Account SAPCPIC sollte eigentlich gelöscht oder zumindest gesperrt sein, in der Regel wird er nicht benötigt.
Eine hohe Priorität des Alarms ist auch bei fehlgeschlagenen Anmeldungen von Remote-Function-Call-Usern, RFC genannt, mit hinterlegtem Passwort notwendig. Hier gilt grundsätzlich, dass RFC-User mit hinterlegtem Passwort nach Möglichkeit nicht zur Anwendung kommen sollen.
Anmeldungen von DDIC-, EARLYWATCH-, und Notfall-Usern müssen - ebenfalls gleich, ob erfolgreich oder fehlgeschlagen - in jedem Fall einen hoch priorisierten Alarm auslösen. Der Nutzer DDIC wird für bestimmte Upgrades und Patches jedoch benötigt. Deshalb muss der Change-Management-Prozess dokumentieren, warum die Nutzung des Accounts notwendig ist. Hier sollte unbedingt auch das Security-Management-Team eingebunden werden. Je nach verwendetem SIEM-System können die Regeln vorübergehend deaktiviert werden. Ähnliches gilt für den Benutzer EARLYWATCH und unternehmensspezifisch eingerichtete Notfall-User.
Auch hoch zu priorisieren sind Debugs mit Replace in SAP-Protokollierungen: Werden Feldwerte beim Debug mit Hilfe der Debug-Funktion verändert, muss das System Alarm schlagen. Hier steht sogar das Testat des Wirtschaftsprüfers auf dem Spiel, der ein solches verweigern kann, wenn dies bei den Finanzmodulen FI oder CO geschieht und es keine sehr genaue Dokumentation des Vorgangs gibt.
Auf fehlgeschlagene RFC- oder Webservice-Calls sollte ebenfalls direkt ein Alarm hoher Priorität folgen. Denn ist ein System ausführlich getestet, werden keine entsprechenden Einträge ausgelöst. Geschieht dies aber dennoch, dann ist das ein klarer Hinweis auf einen Angreifer, der gerade testet, welche potenziellen Einfallstore er nutzen kann.
Selbstverständlich muss auch ein priorisierter Alarm folgen, wenn der Security Audit Log verändert oder gar abgeschaltet wird. Unter all den oben genannten Alarmbeispielen ist dies sogar der wichtigste - der Log ist nämlich die Voraussetzung dafür, dass alle anderen Fälle festgestellt werden.
Weitere Szenarien
Es gibt aber auch zahlreiche Fälle, für die eine geringere Priorität genügt, etwa im Fall der Nutzung eines Firefighter Accounts im Einsatz von SAP GRC mit der Funktion "Superuser-Berechtigungsverwaltung" oder auch Firefighter. Über den Vorgang zumindest informiert, kann das Security-Management-Team stichprobenartig Verwendung und die entsprechende Dokumentation prüfen.
Kategorie 1 - sicherheitsrelevante Ereignisse
Der einfachste Weg bei der Konfiguration führt über feste Eskalationswege für Meldungen der Kategorie 1 (Typische Meldungen für Security Events wie beispielsweise fehlgeschlagene Anmeldungen). Diese Meldungen haben Sicherheitsrelevanz, sollten also umgehend analysiert werden. Doch gibt es hier einige Fälle, die zu False Positives führen: Mitarbeiter vertippt sich, weiß nach dem Urlaub sein Passwort nicht mehr genau, tippt nach einem Passwortwechsel versehentlich das alte Passwort ein. Solche Fälle sollten keine Meldung auslösen.
Das Problem so zu lösen, dass nur noch auf gesperrte Accounts eine Reaktion erfolgen soll, ist jedoch unzureichend für Accounts, die im Routinebetrieb nicht verwendet werden sollen (beispielsweise Notfall-User wie root, sap<sid>) oder technische Accounts, die von Anwendungen, Batch Jobs oder ähnlichen benutzt werden. Hier kristallisieren sich schon die ersten Regeln heraus.
Regel Nummer 1: Accounts, die nicht im Regelbetrieb verwendet werden, müssen sofort eine Meldung bei einer fehlgeschlagenen Anmeldung auslösen, die Dringlichkeit des Events sollte entsprechend hoch klassifiziert werden. Treten bei technischen Accounts fehlgeschlagene Anmeldungen auf, so ist mit großer Wahrscheinlichkeit von einem Angriff auszugehen. Der Grund dafür ist der, dass Passworte technischer Nutzer in der Regel fest in Konfigurations-Dateien oder besser in Secure Wallets gespeichert sind und daher auch keine fehlerhafte Eingabe vorkommen kann.
Die Meldung ist an die zuständige Betriebseinheit und an den verantwortlichen Bereich für Informationssicherheit weiterzuleiten. Dort kann das Security Information and Event Management-System bei einem klaren Fehlalarm nach Absprache mit einem Security-Verantwortlichen geschlossen werden, falls ein berechtigter Fall vorliegt oder im ungeklärten Fall eine Recherche zur Aufklärung eingeleitet werden.
Regel Nummer 2: Accounts, die im Regelbetrieb genutzt werden (Konten von Administratoren und fachlichen Nutzern), brauchen bei fehlgeschlagenen Anmeldeversuchen nicht sofort ein Security Event auszulösen. Doch bei einer Häufung von fehlgeschlagenen Anmeldeversuchen bei einer Vielzahl von Accounts sollte eine Meldung mit hoher Dringlichkeit ausgelöst werden. Denn Angreifer versuchen es in der Regel nicht mit Brute Force an einem Account, sondern über mehrere Konten. Mit zunehmender Zahl von Accounts steigt die Wahrscheinlichkeit, dafür ein schwaches Passwort zu finden - beispielsweise der aktuelle Monat in Kombination mit der Jahreszahl - und somit für einen erfolgreichen Angriff.
Sind also sehr viele Konten in einem System vorhanden, dann sollte hierfür eine Regel eingerichtet werden, die diesen intelligenten Angriff erkennen kann, ohne andauernd False Postives auszulösen. Entsprechende Templates für eine solche Regel sind in SIEM-Systemen meist vorhanden.
Außerdem können im Lauf der Zeit individuelle Statistiken erstellt werden, die ein zeitabhängiges Grundrauschen von fehlgeschlagenen Anmeldungen, also ein typisches Verhalten im Unternehmen aufzeigt. Auf Basis dieser Information setzt man dann entsprechende SIEM-Regeln auf, die bei einer überdurchschnittlichen Abweichung eine Meldung auslösen. Die Dringlichkeit kann sich hierbei am Maß der Abweichung orientieren.
Bei überdurchschnittlicher Häufung von fehlgeschlagenen Anmeldeversuchen muss unbedingt die Einstufung in eine höhere Dringlichkeit erfolgen, da eine unmittelbare Störung der Verfügbarkeit vorliegt (Denial of Service). Diese Störung ist sowohl betrieblich als auch aus Sicht der Informationssicherheit unmittelbar kritisch.
Kategorie 2 - regelmäßig auftretende Meldungen
Es kann sein, dass die Meldung im Regelbetrieb systembedingt auftritt, dass ein betriebliches Problem vorliegt oder dass tatsächlich ein Angreifer das System auf Schwachstellen testet, um sich Zugang zu verschaffen.
Regel Nummer 3: Meldungen, die regelmäßig im System auftreten, können mit niedriger Dringlichkeit ("low") klassifiziert werden, wenn die Betriebsverantwortlichen sie kennen und erklären können. Meldungen, die nicht ohne weiteres nachvollziehbar sind, sollten hingegen schnell geklärt und entsprechend klassifiziert werden.
Betrieblichen Problemen und Angriffen ist natürlich entsprechend zu begegnen, doch das betrifft die wenigsten Meldungstypen, so dass der Aufwand überschaubar bleibt. Eine statistische Auswertung im Laufe der Zeit hilft dabei, Abweichungen zu erkennen und so systembedingte Meldungen im Regelbetrieb schnell von Problemen und Angriffen zu unterscheiden.
Kategorie 3 - neue Meldungen
In diese Kategorie gehören Meldungen, die zum ersten Mal oder nur sehr selten auftreten. Leider fällt ein großer Anteil der Meldungen in diese Kategorie - sie lassen sich oft nur mit großem Aufwand klären, weil Fehlermeldungen meist nicht sehr selbsterklärend sind und eine verständliche Dokumentation fehlt. Tritt eine solche Meldung auf, deutet sie auf ein bisher unbekanntes betriebliches Problem hin oder auf einen Angreifer, der gerade einen Weg ins System sucht. Deshalb gilt
Regel Nummer 4: Meldungen, die selten oder noch nie aufgetreten sind, sollten mit einer mittleren bis hohen Dringlichkeit - in Abhängigkeit von der Häufigkeit - versehen werden.
Datenkorrelation und Dokumentation
Wenn das betriebliche Monitoring die Kategorien 2 und 3 bereits behandelt, ist die Integration in das SIEM recht einfach. In diesem Fall reicht die Anbindung des betrieblichen Monitorings oder die Übernahme der Regeln in das SIEM. Darüber hinaus sollte ein SIEM auch Log-Meldungen über Applikations- und Systemgrenzen hinweg korrelieren. Hierzu liefert das SIEM-System vorgefertigte Regeln. Eine generelle Herangehensweise für die Einrichtung gibt es nicht, da es von der jeweiligen Konstellation der Systeme im Unternehmen abhängt und hier schnelle Ergebnisse nur mit Hilfe der vorgegebenen Templates und der Erfahrungen des unterstützenden Implementierers möglich sind.
Eine grundsätzliche Anforderung ist jedoch, Auffälligkeiten zu erkennen, die von einem System zum nächsten "wandern". Sind die Meldungen kategorisiert und nach ihrer jeweiligen Dringlichkeit klassifiziert, müssen die Maßnahmen und Eskalationswege zentral dokumentiert, die Betroffenen informiert und gegebenenfalls geschult werden. Die Maßnahmen können von "Ignorieren", über "Informieren", "Trennen von Systemzugängen" bis zu "komplette Abschaltung" reichen. Außerdem muss festgelegt werden, welche dieser Maßnahmen vom System automatisch eingeleitet werden können oder müssen. Anderenfalls sind Entscheidungsträger zu definieren, die einen gemeldeten Sicherheitsvorfall bewerten und das System gegebenenfalls wieder zügig in Betrieb nehmen.
Mit wenig Aufwand zum Security-Ziel
Die beschriebene Herangehensweise führt mit einem überschaubaren Aufwand zu einer deutlichen Erhöhung der Sicherheit von SAP-Systemen im Unternehmen und bildet eine gute Grundlage für weitere Optimierungen. In weiteren Schritten können die Meldungen der SAP-Systeme im SIEM-Gesamtkonzept mit anderen Anwendungen, Systemen und Infrastrukturen korreliert werden, wie kurz skizziert.
Die Klassifizierung der Meldungen sowie die Definition und Implementierung der notwenigen Maßnahmen müssen regelmäßig überprüft und aktualisiert werden. Denn neben Anpassungen in Systemen sind auch die Veränderungen bei den Angriffsmustern und bei den Meldungen zu berücksichtigen. Auch hierzu sind entsprechende Prozesse aufzusetzen. (sh)