SIEM Use Cases Teil 1: Benutzer-Management

In praktisch allen Unternehmen existiert heute ein Active Directory. Meist ist dieser Dienst das zentrale und führende System für das Benutzer- und Accountmanagement. Manchmal existieren weitere Verzeichnisdienste für spezielle System-Gruppen, die eine eigenständiges Benutzermanagement abbilden.

In anderen Fällen sind es ERP-Systeme wie SAP oder auch Plattformen wie HCL Notes (früher Lotus Notes), die aus verschiedenen Gründen noch mit einem eigenen Benutzer- und Passwortbestand arbeiten.

Diese zentralen Benutzerdatenbanken sind das Herzstück jedes Benutzer- und Berechtigungs-Managements. Darum legen Standardisierungen wie ISO 27001 auch entsprechenden Wert auf die Überwachung und Kontrolle des Accountbestands und den zugeordneten Berechtigungen.

Ryoji Iwata on Unsplash

Normabweichungen: üblich oder risikobehaftet?

In der Regel sind Veränderungen im Bestand der Benutzer klar verknüpft mit neu eingestellten und ausscheidenden Mitarbeitern. Überwiegend laufen solche Prozesse voll- oder teil-automatisiert. So werden beispielsweise aus dem HR-System Informationen über die Veränderungen im Mitarbeiterbestand an das System zur Accountpflege übergeben.

Dieser legitime Prozess der Erstellung und Löschung von Accounts ist in der Regel mit strikten Leitplanken und Rahmenbedingungen versehen. Eine automatische Account-Provisionierung erfolgt normalerweise zu ähnlichen Uhrzeiten, von gleichen Systemen mit den stets gleichen Accounts und Berechtigungen. Stellt ein SIEM-System Abweichungen vom Normalzustand fest, ist von einem Ereignis auszugehen, dass eine genauere Überprüfung benötigt.

Warum sollte es zur illegitimen Erstellung von Accounts kommen? Hier sind mehrere Fälle denkbar. Ein interner Administrator könnte eine nicht legitime Tätigkeit planen, und zur Verschleierung als erstes einen Account anlegen, der niemandem konkret zuordenbar ist. Die Motivation des Administrators spielt hierbei keine Rolle. Von Erpressung durch Dritte bis Rache am Arbeitgeber ist hier alles denkbar und auch möglich.

Die Accounterstellung vorbei an allen etablierten Prozessen muss von einem Sicherheitsverantwortlichen hinterfragt und bewertet werden. Es könnte sich um eine der berühmten Ausnahmen handeln, um einen Test-Account. Oder eben um einen Angriff.

Der Account könnte auch von einem Außentäter im Rahmen eines Advanced Persistent Threats (APT) übernommen worden sein.  Solche Accounts dienen zur weiteren Absicherung der erreichten Ausbreitung im Unternehmen. Damit schaffen Angreifer eine Hintertür, die später wieder geöffnet werden kann, wenn beispielsweise der erste Account oder der Administrator-Account vermeintlich wieder gesichert wurde. Auch hier können Abweichungen von der Norm dazu führen, die unautorisierte Veränderung festzustellen.

Die Beschreibung dieses Use Cases führt nun zu Fragen, die ganz individuell beantwortet werden müssen: Wieviel Automation wird tatsächlich benötigt? Oder ist es nicht effizienter, wenn ein Sicherheitsverantwortlicher jede Woche eine Liste der Account-Anlagen manuell auf Ungereimtheiten prüft?

Das hat sicher auch etwas mit der Anahl der Accounts zu tun, die sich verändern. Ein Unternehmen mit ein bis zwei Neueinstellungen im Monat hat ist sicher nicht mit einem schnell wachsenden Startup oder einem großen Unternehmen vergleichbar, das 15 bis 20 oder noch mehr Neueinstellungen im Monat hat.

Warnung vor Ungereimtheiten

Einen Alarm zu definieren, der die Erstellung eines Accounts unter ungewöhnlichen Rahmenbedingungen anzeigt, kann dann auch direkt in einem SOC bewertet werden. Allerdings müssen auch hier alle Metadaten bekannt und definiert sein, um Fehlalarme weitgehend zu vermeiden. Nicht jede Anlage eines Accounts sollte händisch kontrolliert werden.

Werden Accounts beispielsweise manuell angelegt, ist auch oft die Prozedur “anlegen”, “löschen”, “anlegen” zu beobachten, weil beim ersten Versuch eine Einstellung nicht korrekt war. Auch hier können entsprechende besondere Maßnahmen und Kontrollen durchgeführt werden, um sicher zu sein, dass der Administrator tatsächlich diesen Fehler gemacht hat.

In der ISO 27002 werden die Empfehlungen für die sogenannte “User registration and de-registration” in Kapitel 9.2.1 festgelegt. Im BSI Grundschutz existiert mit der Anforderung ORP.4.A1 “Regelung für die Einrichtung und Löschung von Benutzern und Benutzergruppen [IT-Betrieb]“ auch eine Vorgabe, wie die Accountanlage umzusetzen ist, sodass die beschriebenen Mechanismen in der Nachverfolgung tatsächlich greifen können.

Schon dieser Use Case zur Kontrolle der Erzeugung eines neuen Accounts, zeigt, wie viele unterschiedliche und individuelle Anpassungen Unternehmen bei der Implementierung ihres SIEM-Systems vornehmen müssen. Ein SIEM mit ausgeprägter Security Intelligence bringt bereits eine große Anzahl von Regelwerken mit, um Angriffe und Anomalien frühzeitig zu identifizieren.

In der nächsten Folge bleiben wir beim Thema Benutzerverwaltung und beschäftigen uns mit SIEM Use Cases zu (hoch-)privilegierten Accounts.