SIEM Use Cases Teil 2: Privilegierte Benutzer

Administrative Benutzer der zentralen Benutzer-Datenbanken müssen unter besonderer Beobachtung stehen. In diesem Umfeld muss vor allem der korrekte Einsatz überprüft werden.

Im ersten Artikel zu den Benutzer-Datenbanken ging es um die Veränderung der Anzahl der Benutzer und daraus resultierenden Risiken. Nun geht es um die spezielle Kontrolle der administrativen Benutzer und hoch privilegierten Accounts und insbesondere deren korrekten Verwendung im täglichen und nicht alltäglichen Arbeiten.

Windows-Umgebung

Die zentrale Infrastruktur-Komponente ist in den meisten Unternehmen das Windows Active Directory. Die Use Cases im Umfeld der privilegierten und hoch-privilegierten Accounts im Windows-Umfeld richten sich sehr stark nach dem etablierten Sicherheitskonzept im Windows Active Directory.

Initial gehen wir davon aus, dass jeder Administrator für seine normalen Office-Tätigkeiten wie E-Mails lesen und Surfen einen „normalen“ Account besitzt und ihn für das tägliche Arbeiten benutzt. Alle administrativen Tätigkeiten, und nur diese Tätigkeiten, müssen mit einer zusätzlichen administrativen Benutzerkennung durchgeführt werden. Diese Benutzerkennung ist ebenso personalisiert und wird entsprechend kontrolliert. Zusätzlich gibt es immer einige Accounts, deren Verwendung auf ganz spezielle Einsatzzwecke zielt, wie beispielsweise der Schema-Admin des AD.

Grundsätzlich müssen hier einige Dinge in der Windows Infrastruktur umgesetzt sein, bevor eine Überwachung der Aktivitäten dieser Accounts und Gruppen umgesetzt werden kann. Neben der Umsetzung eines Sicherheitskonzeptes, wie beispielsweise das von Microsoft empfohlene, sind auch die notwendigen Logs zu generieren. Auch hier gibt es eine Empfehlung von Microsoft welche Events denn für eine sinnvolle Überwachung geloggt werden müssen und auch wie man sie kontrolliert.

Überblick & Auswertung

Danach können die entsprechenden Dashboards und Reports für den Einsatz der privilegierten Accounts erstellt werden. Ebenso können auch die Veränderungen in den zugehörigen Gruppen überwacht werden. Wenn beispielsweise für eine Schema-Änderung temporär der durchführende Account in die Gruppe der Schema-Admins aufgenommen wird, die Änderungen durchführt und danach der Account wieder aus der Gruppe entfernt wird, sollte dieses Vorgehen durch einen entsprechenden Change oder ein Ticket gedeckt sein.

Auch das Surfen im Internet mit den Berechtigungen der administrativen Benutzer sollte unterbunden sein.  Ebenso sollten keine Mailboxen für die Accounts existieren. Versuche für solche Zugriffs-Versuche sind entsprechend zu analysieren und zu bewerten.

Neben der Windows-Infrastruktur gibt es weitere Systeme, beispielsweise Linux-Server oder auch Netzwerk-Komponenten wie Switches, Router und Access-Points kritische Bestandteile der Netzwerk-Infrastruktur mit administrativen Accounts.

Roter Apfel in einer Reihe
Bild von Gerd Altmann auf Pixabay

Linux-Systeme

Bei den Linux-Systemen ist die Überwachung der administrativen Logins ebenfalls sehr stark vom Administrations-Konzept abhängig. Diesem Prinzip folgend sind hier die Logins die zur Durchführung von Kommandos mit root-Berechtigung zu kontrollieren. Bei den Netzwerk-Komponenten ist es essenziell, Konfigurations-Änderungen zu überwachen und zu bewerten.

Beispielsweise sollte es nicht notwendig sein, im normalen Betrieb auf einer Firewall eine Secure Shell Verbindung zu öffnen und sich auf dem System einzuloggen. In der Regel passiert dies nur bei speziellen Anpassungen, Updates oder im Debugging komplexer Sachverhalte. Hier sind die jeweiligen Zugriffe und erfolgreichen Anmeldeversuche mit den zugrunde liegenden Tickets abzugleichen.

Netzwerk-Komponenten

Bei Switches und Routern ist das oftmals schon komplizierter, weil im Rahmen einer Automation manchmal auch diese Secure Shell-Schnittstelle bewusst verwendet wird, um  Konfigurationen automatisiert auszurollen. In einem solchen Fall müssen automatisierte von manuellen Änderungen unterschieden werden.

Außerdem besteht oftmals noch die Möglichkeit über andere, parallel existierende Schnittstellen wie SNMP, Web-Interfaces oder ein Web-API Änderungen an der Konfiguration vorzunehmen. Auch diese Änderungen müssen nachvollziehbar und einem Administrator zuordenbar sein.

Ebenso erfolgt die Integration mit einem Network Access Control (NAC) System  oftmals über die beschriebenen Schnittstellen und muss gesondert bewertet werden. Die Logs des NAC-Systems sind ebenfalls zu bewerten und mit den durchgeführten VLAN-Zuordnungen zu korrelieren. Falls das NAC-System bei unbekannten Systemen von sich aus keine Alarmierung verschickt, kann auch das SIEM an dieser Stelle diese Aufgabe übernehmen.

Langfristig können hier auch weitere Wochen- oder Monats-Auswertungen zu betroffenen Netzwerk-Ports, Räumen oder Geräten erfolgen. Auch in der Regel sehr statische Zuordnungen wie Drucker und Telefonie-Geräte können einfach auf Veränderungen überwacht werden. Die fehlgeschlagenen Logins auf den Netzwerk-Geräten sind auf allen Schnittstellen zu analysieren, also für SSH, Telnet, SNMP oder HTTP und HTTPS.

Ziel dieser Maßnahmen ist nicht die Qualitäts-Kontrolle der Administratoren. Klar kann man auch feststellen, welcher Administrator eine mögliche Fehlkonfiguration vorgenommen hat, aber das muss in der Fehlerkultur des Unternehmens oder der IT-Abteilung gelöst werden. Aus der Sicht der IT-Sicherheit ist nur wichtig, dass es sich um einen Fehler und nicht um eine missbräuchliche Verwendung des Accounts mit dem Ziel einer Sabotage gehandelt hat.

In der nächsten Folge der SIEM Use Case Reihe geht es um die gezielte Auswertung von Firewall-Logs. Oftmals werden diese Logs nur untersucht, wenn konkrete Störungen vorliegen. Darüber hinaus geht es um die Mehrwerte für die Sicherheit des internen Netzwerkes und der dort befindlichen Server.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

CAPTCHA *