Security Information- und Event-Management automatisieren

SIEM-Systeme richtig konfigurieren und einsetzen

Seite: 3/5

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?

(ID:32559920)