Status
Grundlage des Security Information and Event Managements (SIEM) sind Protokolldaten der IT-Infrastruktur eines Unternehmens. Diese werden für historische bzw. forensische IT-Sicherheitsanalysen und -Berichte revisionssicher zentral archiviert, was als Security Information Management (SIM) bezeichnet wird und aus dem Log-Management hervorgegangen ist. Gleichzeitig werden diese Daten im Rahmen des Security Event Managements (SEM) nahezu in Echtzeit verarbeitet, um sicherheitskritische Ereignisse zu identifizieren und die verantwortlichen IT-Security-Experten zu alarmieren.
SIEM-Systeme, die auch in der Praxis einsetzbar sind, gibt es mit der Verfügbarkeit von Big-Data-Technologien seit mehr als 10 Jahren. Durch die horizontale Skalierung lassen sich technisch nahezu beliebige Mengen an Protokolldaten zentral und performant durchsuchbar speichern. Dabei spielt auch das Datenformat nahezu keine Rolle. Individuelle Korrelationen und Auswertungen können sehr flexibel und adhoc über den gesamten Datenbestand hergestellt werden.
Die Gründe für den Betrieb eines SIEM-Systems leiten sich oft branchenspezifisch aus regulatorischen Anforderungen und deren operative Umsetzung ab. Beispielhaft genannt seien hier die Bankaufsichtlichen Anforderungen an die IT (BAIT), Tz. 5. Operative Informationssicherheit: „Die regelbasierte Auswertung […] großer Datenmengen erfordert in der Regel den Einsatz automatisierter IT-Systeme.“[1] Das heißt, zusätzlich zu unserem Hauptwunsch, die IT-Sicherheit im Unternehmen in der Praxis zu verbessern, kann es auch Compliance-Gründe für den Betrieb eines SIEM geben.
Dabei hilft uns die regulatorische IT-Sicherheit auch in der Praxis. So werden z. B. die zu überwachenden Systeme, IT-Infrastruktur-Komponenten und (seltener) Fachanwendungen risikobasiert aus der regulatorischen IT-Sicherheit (z. B. anhand der Schutzbedarfsklassifizierung) bestimmt.
Die Auswahl der eigentlichen Use Cases (UC) und die Implementierung des Regelwerks zur Detektion von Cyber-Bedrohungen werden dann meist anhand von MITRE ATT&CK®[2] durchgeführt.
Durch den stark steigenden Einsatz von Künstlicher Intelligenz (KI) und Cloud-Technologien sind wir in einer technologischen Umbruchphase, die auch SIEM betrifft.
Herausforderungen
Die Einführung oder Erweiterung eines SIEM ist meist mit hohen Projektaufwänden für die Implementierung der UC und des Regelwerks verbunden. Auch im späteren Betrieb müssen die UC und Schwellwerte kontinuierlich anhand der Rückmeldungen aus der Incident-Bearbeitung im Security Operations Center (SOC) nachjustiert werden, um die False Positive Rate (FPR) zu senken. Dabei ist zu berücksichtigen, dass für den reinen SIEM-Plattformbetrieb und die Pflege des Regelwerks unterschiedliche Skill-Sets bei den Mitarbeitern vorgehalten werden müssen.
Bezogen auf Threat Detection, Investigation, Response (TDIR) kann ein klassisches SIEM im Wesentlichen den Bereichen Detection und Investigation zugeordnet werden und unterstützt den ebenso kritischen Bereich Response ohne Erweiterungen (z. B. SOAR) nur unzureichend.
Zudem fallen Protokolldaten vermehrt direkt in der Cloud an, deren Einleitung in ein On-Prem-SIEM aufwändig, kostenintensiv und somit meist nicht sinnvoll ist.
Lösungen
Die neue Produktgeneration kann z. B. basierend auf MITRE ATT&CK® per Knopfdruck das Regelwerk für eine Sammlung von Muster-Use Cases durch KI anhand realer Protokolldaten automatisch erstellen (vgl. [3]). Bei der nicht KI-getriebenen Regel-Entwicklung sollte man sich stark an den Verfahren der Software-Entwicklung (Staging, Version Control, Modular Programming, Release Management) orientieren, um dauerhaft eine effiziente Wartbarkeit zu gewährleisten.
Mit SIEM as a Service lässt sich der Plattform-Betrieb auf das Onboarding von neuen Daten-Quellen reduzieren, wobei dieser Vorteil meist durch die Ausleitung der On-Prem-Protokolldaten Richtung Cloud mit den damit verbundenen Datenschutzrisiken „erkauft“ wird.
Nur in Kombination mit SOAR (Security Orchestration, Automation and Response) kann der Bereich Response hinreichend automatisiert werden und die verbleibende manuelle Incident-Bearbeitung der Analysten durch Data-Enrichment ohne zeitintensive Systembrüche durchgeführt werden.
Fallen Protokolldaten im SIEM On-Prem und in der Cloud an, so kann eine „Klammerung“ der Alarme in SOAR erfolgen.
Fazit
Bestehende SIEM-Systeme sind im Bereich der regulatorischen und operativen Informationssicherheit weiterhin wichtig. Der zentrale Speicheransatz von SIEM ist bezogen auf den Einsatz von Künstlicher Intelligenz (KI) aktueller denn je, nur das diese Plattformen fast ausnahmslos in der Cloud betrieben werden.Perspektivisch können nur durch den Einsatz von KI und einem sehr hohen Automatisierungsgrad im Bereich Response die erforderliche Mean Time to Detect (MTTD) und Mean Time to Respond (MTTR) erreicht werden. Es ist anzunehmen, dass daher SIEM und SOAR weiter verschmelzen werden, was sich bereits durch die jeweiligen strategischen Zukäufe der SIEM- bzw. SOAR-Hersteller[4] gezeigt hat.
Wie unter diesen Entwicklungen das eigene ideale Lösungsszenario aussieht, ist sehr stark von der Ausgangssituation, den Anforderungen und dem angestrebten IT-Zielbild abhängig und muss deshalb individuell analysiert und bewertet werden.
Referenzen
[1] https://www.bafin.de/ref/19595164
[3] https://www.paloaltonetworks.de/resources/techbriefs/cortex-xsiam
[4] https://www.splunk.com/en_us/newsroom/press-releases/2018/splunk-closes-acquisition-of-phantom.html