Vergangenes Jahr betrieb die Corporate Trust GmbH eine Studie mit dem Titel "Industriespionage 2012 - Aktuelle Risiken für die deutsche Wirtschaft durch Cyberwar". Sie brachte unter anderem ans Licht, 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. 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-Systems (SIEM). Es 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 beziehungsweise auch Abweichungen vom Normalverhalten können nahezu in Echtzeit erkannt und entsprechende Gegenmaßnahmen eingeleitet werden. Durch die zentrale Sammlung von Log-Meldungen werden auch forensische Auswertungen erheblich erleichtert.

PRISM im Unternehmen?

Es stellt sich aber auch die Frage, was zum Schutz vor Angriffen erlaubt ist. 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 entgegenzuwirken.

Um die aufgeworfene Frage richtig betrachten zu können, muss zuerst das Vorgehen eines SIEM-Systems verstanden werden. Dieses lässt sich in folgende 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.

• Auf 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 -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 nahezu in Echtzeit auf die 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 Ereignis, das inhaltlich alle an der Korrelation beteiligten Events umfasst. Weiter können Warnmeldungen beziehungsweise andere Formen der Benachrichtigungen generiert werden. Diese triggern Prozesse, welche die Analyse des potenziellen Angriffs übernehmen und diesem gegebenenfalls entgegenwirken.

Gefahr des gläsernen Mitarbeiters

Kernstück eines jeden SIEM-Systems sind die vorhandenen Regeln. Mit der Qualität der Regeln steht und fällt die Leistungsfähigkeit eines jeden SIEM-Systems. Um die Performance sicherzustellen, werden Mitarbeiter benötigt, die zum einen ein sehr breites Wissen über verschiedenste Techniken besitzen, zum anderen 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-Prozesses erforderlich, 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 liegt der Verdacht nahe, ein SIEM-System führe automatisch zu gläsernen Mitarbeitern, ähnlich dem in der Presse viel zitierten und kritisierten PRISM der NSA. Das muss jedoch nicht so sein.

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. Allerdings existieren sowohl technische als auch organisatorische Möglichkeiten, dies zu verhindern:

Log-Policies können für Datensparsamkeit sorgen

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 beziehungsweise 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-Anwender möglichst klein und diese müssen namentlich benannt sein.

Anonymisierung schützt Identität des Log-Verursachers

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 Nutzer zugeordnet werden können. Dieser Personenbezug stellt eine der größten Herausforderungen beim Aufbau eines SIEM-Systems dar, für die aber mittlerweile meist technische Lösungsmöglichkeiten existieren.

Anonymisierung beziehungsweise 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).

Datenschutz mit Hilfe der Pseudonymisierung

Pseudonymisierung ist nicht ganz so strikt definiert. Hierunter versteht man das Ersetzen des Namens oder anderer Identifikationsmerkmale durch ein Kennzeichen zum 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 (zum Beispiel AES256) oder asymmetrische Verschlüsselungsverfahren (zum Beispiel Public-Private-Key-Verfahren) zum Einsatz kommen. Letztere eignen sich aufgrund der geringen Geschwindigkeit verglichen mit symmetrischen 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 einbezogen 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.

Regelmäßige Revision des SIEM-Systems

Weiter verbleibt die regelmäßige Kontrolle der SIEM-Lösung beziehungsweise 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 jedes 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 weitervermittelt, 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 sie die Möglichkeit, das Projekt aktiv mitzugestalten, ist ihre Unterstützung meist sicher.

Fazit

Insgesamt stehen organisatorische und 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. (pg)