Unternehmen und öffentliche Einrichtungen setzen eine Vielzahl von IT-Systemen ein. Diese Lösungen müssen permanent überwacht werden, etwa ob Fehler oder sicherheitsrelevante Ereignisse (Events) aufgetreten sind. Für das Erfassen und Auswerten solcher Daten sind SIEM-Lösungen zuständig. In der Regel werden diese Systeme auf die Anforderungen eines Anwenders hin zugeschnitten. Es gibt jedoch einige Grundregeln, die für die Planung jedes SIEM-Systems gelten.
Foto: Jürgen Fälchle - Fotolia.com
Gesetzeslage kennen
Zunächst muss den IT-Verantwortlichen und Business-Entscheidern im Unternehmen deutlich gemacht werden, warum ein SIEM-System notwendig ist. In Deutschland machen Gesetze und Compliance-Vorschriften ein solches System unverzichtbar. Dazu zählen:
§91 Abs. 2 AktG (Früherkennung von Risiken);
§43 Abs. 1 GmbHG (Sorgfaltspflichten);
§11 des Energiewirtschaftsgesetzes, Stichwort angemessener Schutz gegen Bedrohungen im TK-Bereich;
Abs. 66 ff. des IDW-Pru?fungsstandards 330 (Institut der Wirtschaftsprüfer);
Kapitel 9 in den Mindestanforderungen an das Risikomanagement (MaRisk);
ISO 27002 - Code of Practice for Information Security Management.
Leistungsspektrum einordnen
SIEM-Systeme waren ursprünglich nur für das Sammeln sicherheitsrelevanter Meldungen zuständig. Heute erfassen sie weitere Informationen, etwa Meldungen von Antivirenprogrammen und IPS-Systemen, Statusdaten von Switches und Servern sowie Routing-Protokolle.
Ein SIEM-System lässt sich dadurch beispielsweise zur Root-Cause-Analyse (Fehler-Ursachen-Analyse) einsetzen. Wenn Mitarbeiter keinen Zugang mehr zu Terminal-Servern haben, prüft die Hotline, ob der Account der Mitarbeiter gesperrt ist. Wenn nicht, wird meist der Active-Directory-Administrator kontaktiert. Dieser analysiert die Log-Dateien des Active-Directory-Systems und wendet sich dann an den Netzwerkmanager. Letztlich stellt sich heraus, dass die Linecard eines Switches, der den Terminal Server mit dem Active Directory verbindet, fehlerhaft ist. Dauer des Prozesses: ein bis zwei Stunden.
Wären die Daten mit einem SIEM-System erfasst worden, hätte die Netzwerkabteilung die Fehlermeldungen des Switches gesehen und die Karte ausgetauscht. Ein weiterer Blick auf die Daten hätte ergeben, dass die Karte die Verbindung zwischen Terminal-Server und dem Active Directory bereitstellt. Der Netzwerkfachmann hätte dann den Helpdesk informiert. Dauer: 30 Minuten.
Risiken ermitteln
Log-Events nicht regelmäßig zu analysieren und zu bewerten, ist fahrlässig. Denn solche Untersuchungen liefern Informationen darüber, wer wann welche Aktionen auf einem System vornimmt. Ohne maschinelle Bearbeitung von Log-Events ist es nicht möglich, gesetzliche Vorgaben zu erfüllen, so dass strafrechtliche Konsequenzen für das Unternehmen ausgeschlossen sind.
Foto: McAfee
Wichtig ist zudem der Beitrag von SIEM zur internen Gefahrenabwehr. Denn die Systeme erfassen nicht nur Log-Events am Netzwerkrand, sondern auch interne Ereignisse. Dadurch lässt sich eine wirkungsvolle Data Loss Prevention implementieren, ebenso eine Kontrolle privilegierter IT-Nutzer. SIEM ist zudem erforderlich, um im Zusammenhang mit der Langzeitspeicherung von Daten forensische Analysen zu ermöglichen.
Betroffene Abteilungen kennen
Welche Abteilungen bei der Implementierung und Nutzung eines SIEM-Systems mit einbezogen werden, hängt vom jeweiligen Unternehmen ab. Dabei sollten folgende Faktoren berücksichtigt werden:
Welche Abteilung ist für den Betrieb zuständig, welche für die fachliche Auswertung?
Welche Abteilungen sind vom Ergebnis der Auswertungen betroffen und über welche Schnittstelle werden die Resultate kommuniziert?
Welche Fachleute sind für die Definition der Sicherheitsrelevanz der einzelnen Komponenten verantwortlich?
Welche Abteilungen müssen in Eskalationsstufen einbezogen werden, und wie sind die entsprechenden Service Level Agreements ausgeführt?
Wichtig ist: Ein SIEM-System per Order "von oben" einzuführen, wird in der Regel nicht zu den gewünschten Resultaten führen.
SIEM in bestehende Prozesse einbinden
Ein SIEM-System muss mit vorhandenen Systemen interagieren. Zu klären ist beispielsweise, ob bei einem hochkritischen Vorfall der Chief Security Officer oder gar die Geschäftsleitung informiert werden sollen, ob Forensik-Experten alle zur Aufklärung notwendigen Daten zur Verfügung stehen und ob Sofortmaßnahmen erforderlich sind wie die Sperrung des Zugriffs auf Systeme.
So wird deutlich, dass Security ein unternehmensumfassender, vernetzter Prozess ist. Es kann sogar angebracht sein, bei schwerwiegenden Events dem SIEM-System ein selbstständiges Handeln zu erlauben, etwa das Unterbrechen von Verbindungen. Das setzt eine Interaktion mit anderen Komponenten voraus, etwa einem Schwachstellenscanner oder Client-Management-Systeme.
Komponenten auswählen und priorisieren
Es muss klar sein, welche Priorität eine Komponente im Betrieb besitzt. Der Ausfall der zentralen Firewall ist mit Sicherheit problematischer als der eines tertiären DNS-Servers. Auch sollte der physische Standort der Elemente überprüft werden, um beispielsweise den Zugriff von externem Wartungspersonal auf zentrale Systeme einzuschränken.
Foto: McAfee
Komponenten entsprechend integrieren
Anschließend lassen sich die IT-Komponenten in die SIEM-Architektur integrieren. Wichtig ist dabei eine klar definierte Alarmkette:
Welche Alarme mit welchen Sicherheitsstufen sind vorhanden?
Wer ist für die Bearbeitung zuständig und wie lange darf ein Alarm unbearbeitet bleiben?
Wie sieht die Eskalationskette aus?
Wie lange soll der Event gespeichert werden, der den Alarm auslöste?
Wer darf bearbeitete Alarme quittieren?
Gibt es eine nachgelagerte Alarmbearbeitung, sprich müssen Änderungen an der IT-Infrastruktur vorgenommen werden?
Welche Abteilungen sind vom Alarm betroffen?
Welche Maßnahmen sind für die Verbesserung von Prozessen und der Infrastruktur erforderlich?
Systemanforderungen klären
Jedes SIEM-System ist nur so gut wie der Mitarbeiter, der es bedient. Deshalb ist die Absprache mit den Mitarbeitern im IT-Betrieb notwendig. Zu klären ist unter anderem, wer für den Systembetrieb verantwortlich ist und welche SLAs gelten. Zudem muss berücksichtigt werden, wann das SIEM-System aktiv ist, welche Support-Leistungen der Hersteller erbringt und welche Schulungen erforderlich sind.
Foto: McAfee
Reporting definieren
Log-Daten sollen nicht nur visualisiert, sondern auch in Berichten zusammengefasst werden. Diese sind wiederum die Grundlage für Verbesserungen. Daher sollte eine flexible Gestaltung der Reports gewährleistet sein, unabhängig, welche Daten ausgewertet und in welchen Kontext sie gestellt werden.
Regelmäßig überprüfen
Eine IT-Umgebung ist dynamisch. Daher sollte regelmäßig eine Evaluierung der SIEM-Lösungen erfolgen. Anhand dieser Bestandsaufnahme lässt sich beispielsweise ermitteln, welche Komponenten erweitert oder hinzugefügt werden müssen. Speziell dann, wenn ein Unternehmen Sicherheitszertifizierungen vornehmen lässt, etwa gemäß ISO 2700x, ist eine solche regelmäßige interne Standortbestimmung unabdingbar.
Fazit
SIEM ist ein zentraler Baustein jeder IT-Sicherheits- und Compliance-Strategie. Allerdings sollte Unternehmen bewusst sein, dass ein Security Incident and Event Management "gelebt" werden muss. Es reicht nicht aus, ein SIEM-System zu implementieren - und fertig. SIEM erfordert, dass die involvierten Abteilungen, Fachbereiche, Administratoren und die Geschäftsverantwortlichen eng zusammenarbeiten. Erst dann kann ein Security Incident and Event Management sein volles Potenzial entfalten. (sh)