Security Information- und Event-Management automatisieren SIEM-Systeme richtig konfigurieren und einsetzen

Autor / Redakteur: Udo Sprotte, (ISC)²-zertifizierter CISSP / Stephan Augsten

Security Information- und Event-Management (SIEM) gewinnt immer mehr an Bedeutung, denn die IT hat in der Finanzbranche schon lange übergreifend Einzug gehalten. Doch trotz aller Vorteile birgt SIEM auch Herausforderungen, wie dieser Beitrag zeigen wird.

Udo Sprotte, CISSP: „Trotz der Weiterentwicklung von SIEM-Systemen sind viele Probleme noch ungelöst.“
Udo Sprotte, CISSP: „Trotz der Weiterentwicklung von SIEM-Systemen sind viele Probleme noch ungelöst.“

Der Einsatz von mobilen sowie stark vernetzten IT-Systemen ist in nahezu sämtlichen Geschäftsprozessen wiederzufinden. Immer deutlicher zählt die dabei eingesetzte IT-Infrastruktur zum wertvollen, besonders zu schützenden Gut eines Unternehmens.

Zugleich ist sie dem Einwirken komplexer Ereignisse – resultierend aus Missbräuchen oder auch Fehlbedienungen – auf sicherheitskritische Eigenschaften der Geschäftsprozesse ausgesetzt. Für die Finanzbranche entstehen auf diese Weise Schäden, die sehr vielfältig ausfallen können.

Bereits ein einzelner Fall von Computermissbrauch kann eine bedrohliche Schadenssumme von mehreren Milliarden Euro bedeuten. Ein gutes Beispiel dafür ist der Fall der Schweizer Großbank UBS.

Ein Kreditinstitut zahl Lehrgeld

Ein Investmenthändler hatte die Bank mit unerlaubten Transaktionen schwer geschädigt. Wie Zeit online (dpa, Reuters, AFP) am 15. September 2011 berichtete, war die Bank ist Opfer von kriminellen Spekulationsgeschäften geworden.

Das Bankhaus gab in der Zeitung bekannt, es habe insgesamt 1,46 Milliarden Euro verloren, weil einer ihrer Händler nicht genehmigte Geschäfte abgeschlossen hatte. Die Aktien der UBS brachen am Vormittag nach der Bekanntmachung ein: Im Züricher Handel sackte der Kurs um 4,57 Prozent auf 10,42 Franken pro Aktie ein.

Die Schweizer Bank schloss nicht aus, dass sie wegen der aufgedeckten Transaktionen im dritten Quartal einen Verlust machen würde. Nun sucht die UBS verstärkt nach Spezialisten mit SIEM-Spezialkenntnissen und Erfahrungen.

Von automatisiertem SIEM profitieren

Allumfassend steht die Finanzbranche vor der Herausforderung, Compliance und die damit verbundenen Gesetze und Regelungen zu erfüllen und nicht den Überblick über den IT-Betrieb zu verlieren. Das betrifft insbesondere den Umgang mit der Datenflut von sicherheitsrelevanten Ereignissen.

Ein gut angepasstes SIEM- und Log-Management kann dabei helfen, eine riesige Menge entsprechender Events automatisch zu überwachen. So produziert das über 700 Server starke Rechenzentrum der Commerzbank nach Aussage von ArcSight eine Flut von mehr als 10 Millionen Ereignissen.

Das macht sich in der Einsparung der vom IT-Personal benötigten Arbeitszeit bemerkbar, da sie sonst diese Ereignisdaten manuell analysieren müssten und wie „Don Quixote de la Mancha“ den Kampf gegen Windmühlen sicher verlieren würden. Besonders wichtig ist dies für Organisationen, die nicht über ausreichend spezialisiertes Sicherheitspersonal verfügen.

Insbesondere trifft dies auf Firmen zu, die ihre Kernaufgaben auf einem anderen Gebiet sehen, als im IT-Betrieb und dem damit verbundenen Sicherheitsmanagement. Aber auch IT-Dienstleistungsunternehmen mit vielen und großen Rechenzentren sowie sensiblen und sicherheitsbewussten Kunden sehen hierin den einzigen Weg, deren Sicherheitsbedürfnis gerecht zu werden.

Dass mit dem SIEM ein so beachtlicher Mehrwert zu erzielen ist, kann darauf zurückgeführt werden, dass sich der Begriff SIEM zu etablieren beginnt und seit Mitte der 90er Jahre aus einem simplen Skript auf den UNIX-Servern, dem Logwatcher, eine stetige Weiterentwicklung stattfindet.

Ein SIEM-System ist nur die halbe Miete

Trotz der starken Weiterentwicklung von SIEM erfüllen diese Systeme „out of the box“ noch längst nicht alle Bedürfnisse der Kunden. Die Probleme dieser Systeme sind immer noch sehr vielfältig. In einem Punkt ist sich die Fachwelt trotzdem einig: Standsicherheitsprobleme können mit diesen Systemen bereits gelöst werden. Damit haben diese Systeme schon einen großen Teil ihrer Aufgabe gut erfüllt.

Es bleiben trotzdem noch viele Probleme ungelöst, wie die folgenden acht Beispiele verdeutlichen sollen. Hier sind die Spezialisten gefordert, um diese Herausforderungen teilweise in den Griff zu bekommen:

1. Hohe Verfügbarkeit der Ereignisdaten und Kontrolle der Verfügbarkeit

Wie hoch verfügbar sind die Ereignisdaten? Sicherheitsbewusste Kunden betreiben ihre IT-Systeme hoch verfügbar in zwei Rechenzentren. Würde das SIEM den Sicherheitsvorfall richtig erkennen und die Ursache zeitnah mitteilen, die beispielsweise zum Ausfall des ersten Rechenzentrums führte?

Die Sensoren des SIEM müssten in beiden Rechenzentren als Cluster aufgebaut sein, damit sie auch bei einem Ausfall sofort im Backup-Rechenzentrum Ereignisdaten empfangen können. Der SIEM-Managementserver wiederum soll im Cluster mit seiner Datenbank richtig funktionieren.

Gibt es Datenbanken, die bei stark veränderlichen Daten überhaupt online gesichert werden können? Können alle Ereignisdaten auch nach einem Datenbankausfall und zerstörten Datenbestand zeitnah wiederhergestellt werden?

2. Hohe Verfügbarkeit der Ereignisdatenquellen und Kontrolle auf Verfügbarkeit

Liefern die Devices garantiert immer ihre sicherheitsrelevanten Events oder können die internen Prozesse auf den Devices auch einmal ausfallen oder umkonfiguriert werden?

Wie geht der SIEM-Betrieb mit dem Ausfall einer Ereignisdatenquelle um? Wie verhält sich das SIEM, wenn zum Beispiel die Ereignisdatenquelle auf sein Hot-Standby-Gerät umschaltet oder im schlechtesten Fall vollständig ausfällt? Möglicherweise war für diesen Ausfall auch ein Sicherheitsvorfall die Ursache. Wird solch ein Vorfall auch vom SIEM richtig erkannt?

3. Das SIEM muss Ereignisdaten immer fehlerfrei interpretieren

Wie hoch ist der Aufwand alle relevanten Devices einzubinden? Unterstützen die Sensoren überhaupt alle nötigen Devices? Wenn sie selber keine Unterstützung bieten, ist es dann möglich sogenannte Flexconnectoren so anzupassen, dass diese Devices fehlerfrei erkennen?

Erkennt das SIEM alle Ereignisse noch richtig, nachdem ein Device ein Softwareupdate erhalten hat? Nach dem Update könnte sich das Format der Ereignisnachrichten geringfügig geändert haben. Es könnten auch weitere für den Sensor unbekannte aber sicherheitsrelevante Nachrichten hinzugekommen sein. Jede empfangene Nachricht wird vom Sensor als Erstes „normalisiert“. „Normalisieren“ bedeutet, dass Teile der Nachrichten auf einheitliche Begriffe übersetzt werden. Somit kann die Correlationengine des SIEM, device- und herstellerunabhängig Entscheidungen treffen.

Eine Netscreen Firewall, ein Cisco Router mit Firewallfeatureset (FWS) und eine Cisco ASA Firewall in einem SIEM fallen beispielsweise immer unter die Kategorie „Firewall“. Wenn Verkehr zugelassen wird, meldet die Netscreen „Permit“, der Cisco Router „permit“ und die Cisco ASA „accept“. Wird Verkehr hingegen verboten, meldet die eine Firewall „Deny“, die andere „denied“ oder „reject“. Check Point meldet in diesem Fall „dropped“. Für das SIEM gibt es immer nur zwei Kategorien, einmal das „/allow“ für den zugelassenen Verkehr und das „/deny“ für den unerlaubten Verkehr. Und immer wird der Verkehr durch die Kategorie „/Firewall“ zugelassen oder verboten.

Wie könnte denn das „Übersehen“ von Ereignisdaten automatisch erkannt werden und gemeldet werden?

4. Datendurchsatz von Sensoren, Datenbanken und Netzwerken

Firewalls aber auch Systemaudits verursachen große Mengen von Ereignisdaten. Obwohl der Umgang mit großen Datenmengen die Kernaufgabe eines SIEM ist, bleibt die große Herausforderung mit dem Ereignisverkehr optimal umzugehen. Die technische Umbesetzung muss wirtschaftlich vertretbar bleiben und trotzdem müssen alle sicherheitskritischen Events möglichst sicher und zeitnah erkannt werden.

Hier heißt es, Engpässe zu lösen. Die Datenbank des SIEM und das Zugangsnetzwerk zu den Sensoren müssen so dimensioniert sein, dass an keiner Stelle eine Überlastung auftritt. Sowohl das SIEM selbst, als auch der Produktionsbetrieb des Kunden könnte dabei negativ beeinträchtigt werden.

Oft müssen IT-Sicherheitsspezialisten hier Kompromisse eingehen und sofort an der Quelle den sicherheitsrelevanten Teil der Ereignisdaten herausfiltern. Gehen sie diese Kompromisse ein, nehmen sie in Kauf, Lücken in die Ereignisdatenkette zu reißen, relevante Events zu übersehen und den Datenbestand für eine forensische Analyse untauglich zu machen.

5. Firewall-Ereignisdaten weisen nicht zwingend auf Sicherheitsverstöße hin

In Fachkreisen ist bekannt, dass die Logdaten von Firewalls allein keinen Hinweis auf sicherheitskritische Ereignisse liefern. Grundsätzlich liefert eine Firewall immer nur die Information, dass Verkehr zugelassen oder geblockt wird. Beide Hinweise sagen jedoch nichts über ein sicherheitskritisches Ereignis aus:

a) Wenn Verkehr zugelassen wird, ist das offensichtlich so gewollt.

b) Wenn Verkehr geblockt wird, dann ist das auch so gewollt und ein möglicher Angriff wurde erfolgreich abgewehrt.

Ereignisdaten von der Firewall sind immer dann hilfreich, wenn der Analyst weitere Informationen hat, wie zum Beispiel das Risikoprofil der Firewall-Infrastruktur oder beispielsweise Informationen über die Netzbereiche, die als „unerlaubt“ oder „riskant“ gekennzeichnet sind.

6. Nachweis für die Wirksamkeit des SIEM

Ein entsprechender Nachweis ist für den Personenkreis wichtig, der den SIEM-Betrieb finanziert. Der muss wissen, ob die Investitionen und die Betriebskosten richtig und maßvoll sind.

Gibt es Methoden, die die Wirksamkeit eines SIEM kontinuierlich nachweisen? Um solch einen Nachweis zu führen, müssen automatisch Reports generiert werden, die aufzeigen, wie viele Ereignisse zu Alarmen korreliert wurden. Dann muss eine Auswertung zeigen, welche Alarme davon berechtigt waren. Stellt sich noch die Frage, wie viel Zeit verloren gegangen ist, bis diese Incidents erfolgreich geschlossen werden konnten?

Der Nachweis ist solange nicht vollständig, solange nicht festgestellt werden kann, wie viele sicherheitsrelevante Ereignisse übersehen wurden.

7. Datenschutz muss gewährleistet sein.

Werden diese Systeme dem Datenschutz gerecht? Und wenn sie die Anforderungen des Datenschutzes erfüllen, verlieren sie dabei nicht an Wirksamkeit? Personendaten die sich in den Spuren des Täters finden, führen immer schnell zum Täter.

Der Datenschutz verhindert allerdings, dass das SIEM für längere Zeit diese personengebundenen Daten speichern darf. Ein Einbruch kann dann nach wenigen Tagen nicht mehr vollständig zurückverfolgt werden, weil die Personendaten gemäß der Datenschutz-Vorgaben gelöscht werden mussten.

8. Missbrauchserkennung auf Applikationsebene

Wie sehen die Chancen auf der Applikationsebene aus, um Missbrauch zu erkennen? Wie können SIEM-Lösungen damit umgehen? Wie hoch ist der Anpassungsaufwand?

Niemand unterstellt einem SIEM, dass es unberechtigte Zugriffe an das Betriebssystem nicht erkennt. Erkennt es aber auch, wenn ein Investmenthändler eine unerlaubte Transaktion durchführt und die Datenbank, auf der diese durchgeführt wird, von einem SIEM überwacht wird? Wie würden die Regeln aussehen, die hier den Missbrauch erkennen könnten?

Das SIEM, dass die unerlaubte Transaktion erkennt, hätte der UBS im Jahr 2011 vor einer Schadenssumme von ca. 1,5 Milliarden Euro geschützt. Wie sieht aber der Arbeitsvertrag, des Analysten aus, der dieser Bank die Regeln im SIEM implementieren könnte?

Moderne SIEM-Systeme erkennen Zusammenhänge

Die nächste Generation von Security-Event-Management-Systemen enthalten zwei intelligente Kerne, einen im Sensor, der die Ereignismeldungen von völlig unbekannten Ereignisquellen selbstständig erkennt und einstufen kann. Und einen zweiten Kern im Korrelationsmechanismus, der eine sogenannte Unschärfekorrelation ausführen kann. Das soll am folgenden Beispiel verdeutlicht werden.

Heute erkennen die Systeme nur einen Einbruch, wenn der Einbrecher durch den Haupteingang in eine Bank einbricht. Ein Einbruch durch die Hintertür würde nicht erkannt werden, weil hier keine Kamera angebracht worden ist. Auch wenn nachts Licht in der Bank brennt, würde der Einbruch nur dann erkannt werden, wenn es dafür eine Regel im System gibt.

Systeme der neuen Generation mit einem intelligenten Kern lernen kontinuierlich hinzu und erkennen aufgrund ihrer Unschärfekorrelation ein ungewöhnliches Verhalten in der Bank. Das System würde den Einbruch mit einem Wahrscheinlichkeitshinweis melden. Würde der Administrator diesen Vorfall bestätigen, hätte das System dazugelernt und würde das nächste Mal dieses Ereignis mit hoher Wahrscheinlichkeit sofort anzeigen.

Über den Autor

Udo Sprotte ist (ISC)²-zertifizierter CISSP und Senior Security Consultant.

(ID:32559920)