Aufbau eines SIEM- und SOC-Systems

Brute Force und Pass-the-hash Angriffe, Phishing, CEO Fraud, Ransomeware und viele weitere Methoden werden von Kriminellen genutzt, um an Geld oder Informationen von Firmen, Banken und Instituten zu gelangen. 2019 belief sich der gesamte Schaden durch Cyberkriminalität auf 87,7 Millionen Euro in Deutschland. Sowohl die zunehmende Anzahl der Ressourcen, die Kreativität der Cyberkriminellen als auch die notwendigen  Anpassungen, die aus den Vorgaben aufsichtsrechtlicher Behörden (wie bspw. der BaFin) resultieren, verpflichten Unternehmen dazu,  ihre IT-Sicherheitslösungen zu professionalisieren.

Ein optimiertes SIEM (Security Information and Event Management) und ein leistungsfähiges SOC (Security Operations Center) stellen hier eine starke Verteidigungslinie gegen die kriminellen Energien des heutigen digitalen Zeitalters dar.

Aufsichtsrechtliche Anforderungen für einen SIEM- und SOC-Betrieb finden sich im Rundschreiben der BaFin 10/2017 in der Fassung vom 14.09.2018 unter Punkt 38. Dort werden unter geeigneten Vorkehrungen für die Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität von produktiven Anwendungen folgende Punkte gelistet:

• Prüfung der Eingabedaten
• Systemzugangskontrollen
• Nutzer-Authentifizierung
• Transaktionsauthentifizierung
• Protokollierung von Systemaktivitäten
• Prüfpfade (Audit-Logs)
• Verfolgung von sicherheitsrelevanten Ereignissen
• Behandlung von Ausnahmen

Weitere Erläuterungen zu den Veröffentlichungen finden sich unter anderem im S&P Unternehmerforum >>>

Kurzgesagt: was genau sind SIEM und SOC?

Ein SIEM ist grob beschrieben eine Konsole, die Logdaten aus angebundenen Logquellen überwacht und nach konfigurierten Regeln Alarme generiert. Die konfigurierten Regeln werden als Use Cases bezeichnet. Ein klassischer Use Case kann ein „Brute Force“-Angriff auf einen Server mithilfe eines Admin -Accounts sein.

Mitarbeiter in einem SOC sind Cyber Security Experten, die mithilfe einer SIEM Appliance und definierten Runbooks, ggf. weiteren Tools sowie ihrem Expertenwissen auf Bedrohungen und Angriffe reagieren. Eine Überwachung erfolgt dabei in einem 24x7 Betriebsmodell. Das eigene SIEM-System (oder das eines Kunden) wird dabei überwacht. Meldet das SIEM einen, nach einem Use Case definierten, Alarm, greifen die Mitarbeiter des SOC auf das korrespondierende Runbook zurück und führen die darin beschriebenen Prozesse aus, um die Bedrohungslage einzudämmen und Gegenmaßnahmen zu ergreifen. Zudem bietet ein SOC Threat Intelligence-Daten von sicherheitsrelevanten Informationen aus Nachrichten und sozialen Medien.

Mit dem Three-Lines-of-Defense Modell können Risiken, die in einem Unternehmen auftreten können, systematisch entdeckt, analysiert und bewertet werden. Ziel der Einhaltung dieses Modells ist ein effektives Risikomanagement. Die First Line of Defense wird in diesem Modell vom Security Operations Center gebildet. Die Aufgabe der Second Line of Defense ist die Überwachung und Unterstützung der First Line of Defense und wird vom Incident Response gestellt. Die Third Line of Defense wird durch die interne Revision als unabhängige Instanz repräsentiert.

Use Case und Runbook-Abwicklung – Reaktion auf Bedrohungen

Theorie schön und gut: doch wie kann das ganze nun in der Praxis aussehen? Folgendes Beispiel soll Ihnen das zeigen:

Ein Unternehmen überwacht seine produktiven IT-Appliances nach Administratoren-Aktivitäten. Ein Brute Force-Angriff mithilfe eines erbeuteten Admin-Users ist hier ein relevantes Sicherheitsrisiko. Versucht nun ein Angreifer mithilfe des Admin Users einen Brute Force-Angriff durchzuführen (wiederholte Login-Versuche bei unbekanntem Passwort) wird ein Alarm nach definiertem Use Case generiert: so wird beispielsweise nach 10 gescheiterten Login-Versuchen vom Admin User Account der Alarm im SIEM ausgelöst. Das SOC erhält nun eine Benachrichtigung und kann anhand des Alarmes das korrespondierende Runbook abarbeiten. Inhalt des Runbooks kann hier das Sperren des Admin User Accounts im Nutzerverwaltungssystems sowie das Erstellen eines Tickets im System sein.

Abb. 1 Beispielhafte Darstellung einer abstrakten Architektur

Gute Vorbereitung ist alles: wichtige Überlegungen vor dem Programm

Das klingt alles schön und gut – wie Sie sich aber sicherlich denken können, ist der komplette Aufbau einer solchen Security-Landschaft nicht von heute auf morgen erledigt. Vielmehr ist es ein langfristiges und kostspieliges Unterfangen. Je nach Verfügbarkeit von Budget, Komplexität der Ziellandschaft, bereits verfügbaren Lösungen, vorhandenes Know-how und verfügbaren Experten am Markt, kann ein solches Projekt weit über ein Jahr dauern. Besonders kritisch ist die aktuelle Marktsituation für Experten. Diese sind bei vielen Unternehmen für solche Themen heiß begehrt. Entsprechend wirkt sich das auf ihre Verfügbarkeit und Tagessätze aus. Möchten Sie das Fachwissen intern aufbauen, sehen die Herausforderungen ähnlich aus.

Sobald Ihr Unternehmen sich für die Durchführung eines Transitionprogramms entschlossen hat und entsprechende Budgets bewilligt wurden, muss entschieden werden, ob der Betrieb in Eigenleistung erbracht wird oder als Outsourcing-Leistung eingekauft wird. Zudem muss auch die Produktwahl beleuchtet werden, denn eine SIEM Appliance kann aus verschiedenen Produkten von verschiedenen Herstellern gewählt werden. Mögliche Optionen sind beispielsweise Splunk vom gleichnamigen Hersteller oder Qradar von IBM. Auch der Aufbau einer leistungsfähigen Appliance muss hier evaluiert werden. Gleichwohl kann die Hardware (und Software) auch als Service am Markt eingekauft werden. Die Entscheidungen sind hier stark vom Unternehmen abhängig. Faktoren, die hier mit reinspielen sind beispielsweise die interne Experten-Situation, die Größe der zu überwachenden IT-Landschaft oder die langfristige IT-Strategie.

Neben den grundsätzlichen Entscheidungen des SIEM-Betriebes sind ebenso Entscheidungen für den SOC-Service notwendig. Am wichtigsten ist die Entscheidung zwischen Eigenleistung oder Outsourcing. Da eine 24x7- Überwachung stattfinden muss, benötigt die Variante „Eigenleistung“ die entsprechende Expertise sowie ausreichend personelle Ressourcen in Ihrem Unternehmen. Es gibt zahlreiche IT-Dienstleister am Markt, die solch einen Service anbieten und geschultes Personal zur Verfügung stellen. Diese Lösung – trotz Outsourcing – kann durchaus die kosteneffizientere Option sein. Zudem profitieren Sie vom zentrierten Fachwissen des IT-Dienstleisters. Da ein solcher Service-Anbieter auch andere Kunden betreut, teilen sich die Kosten für das Personal und die Ressourcen, wie etwa Hardware, Büroflächen, Lizenzen etc. auf.

Die letzte und wichtigste Vorbereitung – und wohl die komplexeste – ist die Evaluierung der Use Cases und der korrespondierenden Runbooks, die für die Überwachung benötigt werden, um ein angemessenes Schutzniveau zu erreichen.

Eine gute Inspiration für die Grundlage von Use Cases ist das „Mitre Att&ck Framework“. Dabei handelt es sich um eine global zugängliche Sammlung an Angreifertaktiken und Techniken basierend auf echten Ereignissen. Ziel dieses Frameworks ist das Bereitstellen einer Wissensgrundlage für den Privatsektor, Regierungen und Cybersecurity-Anbieter zum Entwickeln von IT-Sicherheitslösungen.

Anbieter von SIEM-Lösungen bieten ebenfalls große Paletten von Regeln und Use Cases an, die auf die Bedürfnisse und Anforderungen des jeweiligen Kunden angepasst werden müssen.

Ist der Umfang der Use Cases bekannt, müssen die korrespondierenden Runbooks definiert werden. Das Runbook stellt eine prozessuale Reaktion auf einen oder mehrere Alarme dar, dabei kann ein Runbook beliebig komplex sein. Eine Reaktion kann beispielsweise sein, lediglich ein Ticket zu erstellen oder das einzelne Clients im Netzwerk isoliert und anschließend forensisch untersucht werden.

Hinweis: es liegt nahe, ein Mapping von Use Cases und Runbooks zu erstellen – Use Cases ohne Runbooks können nicht bearbeitet werden und Runbooks ohne Use Cases werden im SOC nicht ausgelöst.

Die schrittweise Programmplanung zum Aufbau Ihres SIEM und SOC-Services

Nachdem die eben aufgeführten Vorbetrachtungen abgeschlossen wurden, geht es nun in die detaillierte Programmplanung für den Aufbau eines SIEM/SOC-Services. Hierfür sollten Sie folgende Fragen systematisch abarbeiten und beantworten:

1. Von welchem Hersteller wird die SIEM-Plattform erworben?
2. Wird die SIEM-Plattform inhouse oder im Outsourcing betrieben?
3. Wird das SOC selbst oder von einem Dienstleister aufgebaut?
4. Was ist das benötigte Schutz-/Überwachungsniveau?

• Regulatorische Anforderungen
• Erfahrungen aus Taktiken und Techniken von Angreifern (Mitre Att&ck)
• Überwachung kritischer Systeme
• Umfang der Use Cases die erstellt werden sollen
• Umfang der korrespondierenden Runbooks, die erstellt werden sollen

Sobald die Punkte 1-3 geklärt sind und die entsprechenden Entscheidungen stehen, kann Punkt 4 als Studie oder Projekt durchgeführt werden. Darauf basierend folgen weitere Teilprojekte:

1. Erstellung der definierten Use Cases
2. Erstellung der definierten Runbooks
3. Aufbau der SIEM Appliance
4. Aufbau der notwendigen SIEM-Betriebsprozesse
5. Aufbau des SOC-Services
6. Aufbau der notwendigen SOC-Serviceprozesse

Hinweis: die Teilprojekte sind „weich“ voneinander abhängig – eine SIEM Appliance kann aufgebaut werden, ohne dass alle Use Cases vorhanden oder sogar bekannt sind. Auch ein SOC-Service kann bereits bereitgestellt werden, ohne dass Runbooks ausformuliert sind – jedoch ist der Mehrwert entsprechend eingeschränkt.

Abb. 2 Beispielhafter Porgrammplan

Erstellung der definierten Use Cases und Runbooks und Aufbau der SIEM-Plattform

Die Erstellung von Use Cases und Runbooks kann ein sehr langfristiges Thema sein. Am Anfang liegt es nahe, standardisierte Vorlagen zu erarbeiten, um das Format konsistent zu halten. Gerade bei Runbooks sollte eine Abstimmung mit dem Dienstleister frühzeitig erfolgen, um Nacharbeiten zu vermeiden. Dienstleister können ihre eigenen Formate und Vorgaben haben, die ggf. eingehalten werden müssen.

Die sehr techniklastigen Use Cases benötigen das entsprechende Fachwissen – dieses kann intern aufgebaut oder extern eingekauft werden. Es ist nicht verkehrt, langfristig auch internes Know-how zur Verfügung zu haben, um im Betrieb gelegentliche Konfigurationen selbst durchführen zu können.

Die Runbooks sind sehr prozesslastig und können viele Berührungspunkte im Unternehmen haben. Hier ist es wichtig eine frühe Abstimmung mit dem Service-Dienstleister über Umfang und mögliche Inhalte von Runbooks abzugrenzen. Es ist zu klären, für was SOC-Mitarbeiter befugt sind bzw. was aus sicherheitskritischen Blickwinkeln sinnvoll ist. Wichtig ist eine frühzeitige Einbindung des Datenschutzverantwortlichen und des Betriebsrates, da mit hoher Wahrscheinlichkeit personenbezogene Daten verarbeitet werden. 

Im nächsten Schritt muss die SIEM Appliance technisch aufgebaut werden, wenn diese nicht als Software as a Service eingekauft wird. Die Aufbauphase kann je nach Unternehmen und Produkt sehr individuell sein. Neben dem technischen Aufbau müssen die verschiedenen Logquellen der zu überwachenden Systeme angebunden werden. Unter Logquellen lassen sich unter anderem Systeme wie Windows Server, Linux Server, Clients, Antiviren-Software, Active Directorys, Datenbanken, Firewalls usw. verstehen.

Um die Weiterleitung der Log- und Eventdaten zu vereinfachen, können Collectoren aufgebaut und konfiguriert werden. Ein klassischer Event-Collector ist bereits Teil der SIEM Appliance und kann standortunabhängig aufgebaut werden. Dieser Event-Collector komprimiert und optimiert die Logdaten. Insbesondere bei Architekturen über Internetleitungen oder WAN-Verbindungen ist dies hilfreich. Für Windows-Systeme bietet bspw. IBM ein Wincollect – eine Software, die Logdaten von Windowssystemen einsammelt, optimiert und an einen Event-Collector und damit an die SIEM Appliance weiterleitet. Analog für Linux-Systeme gibt es Syslog-Konfigurationen. Die technischen Möglichkeiten sind ebenfalls sehr individuell. Ein Architektur-Bild sollte zu Beginn sorgfältig erarbeitet werden.

Hinweis: selbst ohne Use Cases kann aus einer SIEM Appliance mit angebundenen Logquellen Mehrwert gezogen werden – Logdaten können bei aktivem Einsehen der Konsole betrachtet werden.

Abb. 3 Beispielhafte Darstellung einer SIEM-Architektur

Abhängig von der Sourcing Lösung sollte ein Betriebskonzept erstellt werden, um…

• … das laufende System auf dem aktuellsten Patch-Stand zu halten.
• … Logquellen zu pflegen.
• … neue Logquellen anzubinden.
• … veraltete Logquellen zu entfernen.
• … die Qualität der gelieferten Log- und Eventdaten sicherzustellen.

Auch regelmäßiges Überprüfen vorhandener Use Cases sollte beachtet werden. Am Anfang des Betriebes sollte ein besonderes Augenmerk auf den Schwellwerten der Use Cases liegen. Diese Schwellwerte sollten optimiert werden, damit nicht zu viele oder zu wenige bis gar keine Alarme generiert werden.

Wie kann ein SOC-Service zielgerichtet aufgebaut werden?

Als Grundlage für die Bereitstellung der Services ist die technische Anbindung der SOC-Arbeitsplätze an die SIEM-Konsole, Ticketsystem, CMDB und Adressbuch notwendig. Dies erfordert ggf. eine WAN- oder VPN-Anbindung und die notwendigen Firewall-Freischaltungen. Außerdem benötigen die SOC-Mitarbeiter User Accounts und die notwendigen Berechtigungen für die oben genannten Tools. Dies setzt eine Datenschutzerklärung und sichere Passwortübergabe- und Änderungsprozesse voraus.

Eine umfangreiche Kommunikationsmatrix mit den entsprechenden Verantwortlichen, Kontaktmöglichkeiten, Verteilern und deren Rollen sowie Eskalationswege ist ebenfalls notwendig.

Vertraglich ist solch ein Service eine große Herausforderung, sobald er von einem Dienstleister erbracht wird. Eine frühe Einbindung der Rechtsabteilung ist empfehlenswert, um Fragen der Auslagerung und Haftung zu klären.

Als Grundlage für Runbooks und Alarmbearbeitung sollte ein generischer Incident Response-Prozess formuliert werden. Darunter wird eine grundlegende Reaktion eines Cyber Security Experten im SOC auf einen Alarm verstanden, sollte kein korrespondierendes Runbook vorhanden sein. Inhaltlich kann dieser Prozess beispielsweise das Erstellen eines Ticktes oder den Anruf bei einer Service-Hotline beinhalten.

Neben einem generischen Prozess für den Security Incident Response bietet es sich im Laufe der Service-Bereitstellung an, betroffene Prozesse im Unternehmen zu evaluieren und ggf. anzupassen. In Kombination mit der Erstellung der Runbooks können hier leicht prozessuale Schwachstellen und Inkonsistenzen aufgedeckt werden.

Vor dem Go-Life des SOC-Services sollte dieser auch intern kommuniziert werden, beispielsweise mit einer allgemeinen Rundmail oder einem Intranet-Eintrag. So werden die Mitarbeiter unter anderem darauf hingewiesen, dass sie ggf. Anrufe und Anweisungen eines Cyber Security-Mitarbeiters aus dem SOC erhalten werden, sollte es durch sicherheitsrelevante Ereignisse bzw. Runbooks notwendig sein.

Zudem ist es notwendig, gegebene Serviceprozesse für die Betriebsphase zu designen.  Regelmäßige Service-Meetings sollten abgehalten werden, um die offenen Punkte des Betriebes nachzuverfolgen. Sollte der SOC-Service über einen Dienstleister erbracht werden, müssen auch quartalsweise Providermeetings abgehalten werden.

Während des Projektes für die Bereitstellung der SOC-Services muss auch eine Vorlage für das Reporting erstellt werden. Die Reports sollten regelmäßig erstellt werden und einen Einblick auf die aktuelle Sicherheitslage bieten. So kann beispielsweise die Summe an Alarmen pro Monat, „false positives“, Abhandlungen einzelner Runbooks sowie Alarme nach Systemen dargestellt werden. Statistische Auffälligkeiten können guten Aufschluss auf strukturelle, technische oder prozessuale Schwachstellen bieten.

Im Großen und Ganzen ist es wichtig, dass Sie den Aufbau eines leistungsfähigen SIEM- und SOC-Services nicht unterschätzen – denn es handelt sich dabei um ein umfangreiches und ambitioniertes Unterfangen.  Es ist jedoch eine zunehmend notwendige Anforderung an die moderne und zukunftsfähige IT-Sicherheit, weshalb Sie - wenn nicht schon geplant bzw. vorhanden - Sie sich intensiv mit dieser Thematik auseinandersetzen sollten. Denn nur so ist es Ihnen möglich, langfristig anpassungsfähig zu sein und auf immer neue Bedrohungen reagieren zu können.