Security Incident and Event Management

SIEM leicht gemacht

Hans Wagner ist Principal Consultant bei der msg systems ag in Ismaning bei München.
Um ihre IT angemessen zu schützen, müssen Administratoren heute Sicherheitsrisiken frühzeitig erkennen und das Geschehen in ihrem Unternehmen beobachten. Dabei hilft ein Security Information and Event Management-System (SIEM), das ungewöhnliche Vorfälle erkennbar macht.

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.

Mit einem SIEM-System können Unternehmen sicherheitsrelevanten Meldungen konsolidieren und analysieren.
Mit einem SIEM-System können Unternehmen sicherheitsrelevanten Meldungen konsolidieren und analysieren.
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:

  1. Typische Meldungen für Security Events (wie etwa eine fehlgeschlagene Anmeldung);

  2. Meldungen, die regelmäßig im System auftreten;

  3. 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.

Inhalt dieses Artikels