SIEM - Das bessere PRISM?
Der NSA-Skandal bekräftigt den Einsatz von SIEM-Systemen bei der Erkennung von Bedrohungen
Kernstück eines jeden SIEM-Systems sind die vorhandenen Regeln. Mit der Qualität dieser steht und fällt die Leistungsfähigkeit eines jeden SIEM-Systems
Von Michael Sepp und Thomas Mörwald, Secaron AG
(16.01.14) - Die Angst vor Angriffen aus dem Cyberspace wird immer größer. Glaubt man den einschlägigen Zeitungsberichten, dann ist dies nicht unbegründet. Als Hauptverantwortliche gelten gut organisierte Netzwerke von Cyber-Kriminellen, wobei ein wichtiger Aspekt oftmals übersehen wird: der eigene Mitarbeiter. Unabsichtlich oder auch mit Vorsatz können sie dem eigenen Unternehmen Schaden zufügen. Im Jahr 2012 führte die Corporate Trust GmbH eine Studie mit dem Titel "Industriespionage 2012 - Aktuelle Risiken für die deutsche Wirtschaft durch Cyberwar" durch. Darin heißt es, dass bereits 20 Prozent der befragten Unternehmen von Spionagevorfällen betroffen sind. Berücksichtigt man die nicht weiter konkretisierten oder nicht eindeutig nachgewiesenen Fälle steigt der Anteil auf 54 Prozent an. Dabei ist deutschlandweit ein Schaden von 4,3 Milliarden Euro entstanden. In mehr als der Hälfte der Fälle konnten Mitarbeiter als Urheber identifiziert werden.
Ein Ansatz um derartige Bedrohungsszenarien zu erkennen, ist die Einführung eines Security Information and Event Management (SIEM)-Systems. Dies bietet Möglichkeiten zur zentralen Sammlung und Auswertung von Log-Meldungen aller angebundenen Komponenten. Auch die Verknüpfung von Log-Meldungen unterschiedlicher Systeme (sogenannte Korrelation) ist möglich. Bekannte Angriffsmuster bzw. auch Abweichungen vom Normalverhalten können nahezu in Echtzeit erkannt und entsprechende Gegenmaßnahmen eingeleitet werden. Auch werden durch die zentrale Sammlung von Log-Meldungen forensische Auswertungen erheblich erleichtert. Doch stellt sich die Frage, was ist erlaubt beim Schutz vor Angriffen? SIEM-Systeme bieten die technische Möglichkeit, Mitarbeiter zu überwachen und detaillierte Profile zu erstellen. Der Schritt zu einem firmeninternen PRISM ist nicht mehr weit. Diesem gilt es mit Hilfe von Regeln und technisch sinnvollen Beschränkungen entgegen zu wirken.
Um die aufgeworfene Frage richtig betrachten zu können, muss zuerst das Vorgehen eines SIEM-Systems verstanden werden. Dieses lässt sich in drei Ebenen unterteilen. Auf der untersten Ebene finden sich Log-Meldungen, die von den angeschlossenen Systemen erzeugt werden. Abhängig von der Log-Quelle werden die Log-Meldungen selbständig an das SIEM-System übermittelt, wie es beispielsweise bei Routern konfiguriert werden kann. Auch ein periodisches Abholen der Log-Meldungen von der Log-Quelle ist abbildbar. Diese Situation kann beispielsweise bei der Anbindung von Firewalls vorliegen. In der mittleren Ebene erfolgt eine Vorverarbeitung der Log-Meldungen. Neben der Filterung und Normalisierung, was einem Überführen der verschiedenartigen Meldungen in ein einheitliches und vom Tool verständliches Format entspricht, werden die Log-Meldungen dabei auch zusätzlich aggregiert und kategorisiert.
Die Notwendigkeit hierzu leitet sich aus der schieren Vielzahl unterschiedlicher Log-Meldungen und Log-Formate ab. Nach Abschluss der Vorverarbeitung werden die verbleibenden Log-Meldungen als Events bezeichnet. In der obersten Ebene (Event Monitoring System) beginnt die eigentliche Aufgabe eines SIEM-Systems: Hier werden die Events korreliert. Dazu sind im Tool Regeln hinterlegt, die in nahezu Echtzeit auf die Menge der eingehenden Events angewandt werden. Eine Regel wird aktiviert, wenn mindestens ein passendes Event erkannt wurde; eine Regel "feuert", wenn alle notwendigen Events eingetroffen sind. In letzterem Fall wird zunächst ein sogenanntes Meta-Event erzeugt. Dabei handelt es sich um ein Event, das inhaltlich alle an der Korrelation beteiligten Events umfasst. Weiter können Warnmeldungen bzw. andere Formen der Benachrichtigungen generiert werden. Diese triggern Prozesse, welche die Analyse des potentiellen Angriffs übernehmen und diesem gegebenenfalls entgegenwirken.
Nichts geht ohne qualifizierte Mitarbeiter
Kernstück eines jeden SIEM-Systems sind die vorhandenen Regeln. Mit der Qualität dieser steht und fällt die Leistungsfähigkeit eines jeden SIEM-Systems. Um dies sicherzustellen werden Mitarbeiter benötigt, die zum einen ein sehr breites Wissen über verschiedenste Technologien besitzen. Zum anderen müssen diese aber auch in ständig wechselnden Spezialgebieten schnell tiefgreifendes Analysewissen aufbauen können. Nicht zu vergessen sind ausgeprägte organisatorische Fähigkeiten. Diese werden beispielsweise im Rahmen des Security Incident Handling Processes notwendig, der mit Entstehung eines Meta-Events gestartet wird. Folglich nimmt der SIEM-Mitarbeiter eine zentrale Rolle ein, die besondere Rechte und Pflichten zur Ausführung seiner Tätigkeiten bedingen. Dies ist besonders dann zu beachten, wenn sich Benutzerdaten in den Log-Meldungen finden - was praktisch niemals ausgeschlossen werden kann. Insofern ist der Verdacht naheliegend, ein SIEM-System führe automatisch zu gläsernen Mitarbeitern, ähnlich dem in der Presse viel zitierten und kritisierten PRISM der NSA. Dem muss jedoch nicht so sein.
Organisatorische und technische Maßnahmen verhindern den gläsernen Mitarbeiter
Technisch gesehen kann ein SIEM-System die Tätigkeiten von Mitarbeitern relativ exakt sammeln und auswerten, sofern eine möglichst lückenlose Protokollierung durchgängig konfiguriert ist. Ein gläserner Mitarbeiter wäre damit denkbar. Jedoch existieren technische als auch organisatorische Möglichkeiten genau dies zu verhindern:
Die erste Möglichkeit bilden Log-Policies. Diese Form von Richtlinien legen auf einer organisatorischen Ebene alle Anforderungen hinsichtlich der allgemeinen Protokollierung fest. Ein Beispiel hierzu ist die Generierung von erfolgreichen und nicht erfolgreichen Anmeldeversuchen. Basierend auf der allgemeinen Protokollierungsrichtlinie leitet sich pro Log-Quelltyp eine technisch konkretisierte Log-Policy ab. Hier werden alle notwendigen Konfigurationseinstellungen für die jeweilige Log-Quelle zur Umsetzung der allgemeinen Log-Policy detailliert beschrieben. Damit wird sichergestellt, dass möglichst nur die Ereignisse protokolliert werden, die später im Rahmen der Auswertung auch von Interesse sind. Dies geht Hand in Hand mit dem Prinzip der Datensparsamkeit bzw. Datenvermeidung aus dem Bundesdatenschutzgesetz (BDSG). Unabdingbar ist hier die Einbeziehung des Datenschutzbeauftragten und des Betriebsrats.
Eine weitere Möglichkeit besteht im Rollen- und Rechtekonzept des SIEM-Systems. So muss sichergestellt sein, dass dem Need-To-Know-Prinzip Rechnung getragen wird, das heißt die Zugriffsrechte der SIEM-Benutzer sind so restriktiv wie möglich zu definieren. Auch muss die Anzahl der SIEM-Benutzer möglichst klein und diese namentlich benannt sein.
Auch wenn ein ausgefeiltes Rollen- und Rechtekonzept zum Einsatz kommt, verbleibt ein Nachteil: Der SIEM-Benutzer kann die Identität des Log-Verursachers einsehen. Damit lassen sich möglicherweise Bewegungsprofile erstellen, die direkt einem Benutzer zugeordnet werden können. Dieser Personenbezug stellt eine der größten Herausforderungen beim Aufbau eines SIEM-Systems dar, wobei hierzu mittlerweile meist technische Lösungsmöglichkeiten existieren. Anonymisierung bzw. Pseudonymisierung ermöglichen das Verschleiern der wahren Identität. Beispielsweise wird aus dem Benutzernamen "Hr. Müller" der Wert " XHd73lfuaSJ87". Von Anonymisierung spricht man, wenn personenbezogene Daten derart verändert werden, dass die Einzelangaben über persönliche und sachliche Verhältnisse nicht mehr oder nur mit einem unverhältnismäßig großen Aufwand an Zeit, Kosten und Arbeitskraft einer bestimmten oder bestimmbaren natürlichen Person zugeordnet werden können (siehe BDSG 3 Abs.6). Pseudonymisierung ist nicht ganz so strikt definiert. Hierunter versteht man das Ersetzen des Namens oder anderer Identifikationsmerkmale durch ein Kennzeichen zu dem Zweck, die Bestimmung des Betroffenen auszuschließen oder wesentlich zu erschweren (siehe BDSG 3 Abs.6a).
Da die Anforderung der Auflösung des verschleierten Datums besteht, kommt bei SIEM-Systemen die Pseudonymisierung zum Einsatz. Aus technischer Sicht können hier zum Beispiel Hash-, symmetrische Verschlüsselungs- (z.B. AES256) oder asymmetrische Verschlüsselungsverfahren (z.B. Public-Private-Key-Verfahren) zum Einsatz kommen. Letztere eignen sich aufgrund der geringen Geschwindigkeit gegenüber symmetrischer Verfahren weniger zur Pseudonymisierung selbst. Eher noch sind sie zum Schutz der eigentlichen Pseudonymisierungsfunktion oder des symmetrischen Schlüssels geeignet. Zur Auflösung des Pseudonyms müssen organisatorische Verfahren abgestimmt und implementiert werden, die festlegen wann welche Unternehmensbereiche wie Datenschutz, Betriebsrat oder auch Revision miteinbezogen werden müssen und welche Mitspracherechte und -pflichten sie einnehmen. Die Kombination aus diesen Prozessen und der technischen Möglichkeit der Pseudonymisierung bestimmt dabei den Reifegrad des SIEM-Systems hinsichtlich des Datenschutzes.
Weiter verbleibt die regelmäßige Kontrolle der SIEM-Lösung bzw. der zurückliegenden Analysen und Auswertungen. Hierzu muss eine geeignete Stelle im Unternehmen gefunden werden. Naheliegend ist die Einbindung der Revision.
Es empfiehlt sich weiter eine breite Akzeptanz zum Thema Log-Auswertung und -Analyse im Unternehmen zu schaffen. Dies gelingt durch eine frühzeitige Einbeziehung eines jeden Einzelnen. So bietet sich beispielsweise die gemeinsame Erarbeitung von technischen Log-Policies mit den jeweiligen Fachbereichen an. In diesem Zusammenhang wird deren Fachwissen genutzt und die Funktionsweise eines SIEM-Systems weiter vermittelt, was letztlich in einem höheren Vertrauen auf Basis größerer Transparenz mündet. Darüber hinaus muss frühzeitig mit Betriebsrat, Datenschutz und Revision gesprochen werden. Haben diese die Möglichkeit das Projekt aktiv mitzugestalten, ist ihre Unterstützung meist sicher.
Fazit:
Insgesamt stehen damit organisatorische als auch technische Möglichkeiten zur Verfügung, die einen gläsernen Mitarbeiter verhindern. Im Gegensatz zu PRISM verfügt ein gut konfiguriertes SIEM-System über ähnliche Möglichkeiten, jedoch unter Wahrung der Persönlichkeitsrechte. Dies macht SIEM-Systeme zu einer unentbehrlichen Waffe im Cyberwar.
Die Autoren:
Michael Sepp ist Consultant bei der Secaron AG und arbeitet dort schwerpunktmäßig im Bereich Sicherheitskonzepte und Lösungen. Er ist zudem verantwortlich für die fachliche Weiterentwicklung der Themenbereiche Mobile Security und Security Information and Event Management (SIEM).
Thomas Mörwald ist Senior Consultant bei der Secaron AG und arbeitet dort schwerpunktmäßig im Bereich Sicherheitskonzepte und Lösungen. Er ist zudem verantwortlich für die fachliche Weiterentwicklung der Themenbereiche Service-Monitoring, Log-Management und Security Information and Event Management (SIEM).
(Secaron: ra)
Secaron: Kontakt und Steckbrief
Der Informationsanbieter hat seinen Kontakt leider noch nicht freigeschaltet.
