Rückblick auf die Geschichte: Die generative KI-Revolution im SIEM-Bereich

Diese erste Stufe der Erfassung von Sicherheitsprotokollen wurde als SEM (Security Event Management) oder SIM (Security Information Management) bezeichnet. Es wurde eine Kombination aus Protokolldaten erfasst, d.h. den digitalen Aufzeichnungen der Systemaktivitäten, und Ereignisdaten. Für die Analysten war dies ein Wendepunkt, da sie nun ein System unter ihrer Kontrolle hatten, das die zur Aufklärung des digitalen Verbrechens benötigten Daten enthielt. Im Grunde hatten die Sicherheitsteams jetzt ihr eigenes Datensilo. Diese Produktrevolution wurde vor allem durch die Notwendigkeit vorangetrieben, Daten für den Fall zu erfassen, dass etwas passiert, wie z. B. die Pflege eines forensischen Protokolls und die Möglichkeit, Auditoren und Ermittlern zu zeigen, dass diese Protokolle tatsächlich gesammelt wurden. Dieser Compliance-Anwendungsfall führte zur Einführung einer zentralen Erfassung von Sicherheitsereignissen.

Es gab Herausforderungen mit dieser neuen Art von Produkten. Das SOC benötigte nun Security Engineers, um große Datenmengen zu verwalten. Sie brauchten auch das Budget, um diese Informationen zu sammeln und zu speichern, da sie die Daten aus zahlreichen anderen Systemen in ein monolithisches, zentralisiertes System kopierten. Aber die Vorteile lagen auf der Hand: Beschleunigung der Erkennung und Behebung von Problemen, indem der Zeitaufwand für das Sammeln und Sortieren von Daten aus dem gesamten Unternehmen reduziert wird. Sobald ein Angriff gemeldet wird, können die Einsatzkräfte fast sofort mit der Arbeit beginnen.

Der nächste Schritt war die Anwendung einer Erkennungslogik auf der zentralisierten SIEM-Ebene. Früher war ein SIEM eine Kombination aus den Ereignisdaten in einem SEM und den Informationsdaten in einer SIM. Die SEM/SIMs waren sehr leistungsfähig in Bezug auf die Einhaltung von Vorschriften und die Sammlung von Beweisen, aber nach fast einem Jahrzehnt, in dem sie nur Daten sammelten und überprüften, erkannten die Analysten, dass sie mit zentralisierten Informationen viel mehr erreichen konnten. Anstatt lediglich Warnmeldungen aus anderen Systemen zu konsolidieren und ein zentrales System für gesammelte Protokolle und Ereignisse bereitzustellen, ermöglichen SIEMs nun die Analyse vieler Datenquellen. Detection Engineers konnten aus einer neuen Perspektive arbeiten – Bedrohungen aufspüren, die bei einer punktuellen Lösung, die nur eine Datenquelle analysiert, wie z. B. Ihren Virenschutz oder Ihre Netzwerk-Firewall, möglicherweise übersehen worden wären. 

Diese Entwicklung war mit einer Reihe von Herausforderungen verbunden. Neben dem größeren Bedarf an Fachleuten und vorgefertigten Regeln sammelten SIEMs zentral Warnmeldungen von zahlreichen Einzellösungen, von denen jede für sich eine Menge falsch-positive Meldungen produzierte und das Problem verschlimmerte. SIEM-Analysten mussten die gesammelten Netzwerk- und Desktop-Warnungen überprüfen. Dies führte zu einer häufig gestellten Frage eines SIEM-Analysten: „Wo soll ich anfangen?“, gepaart mit einer völlig neuen Reihe von Erkennungswarnungen aus dem SIEM selbst. Ihr SIEM enthält nun die Summe aller anderen Systemwarnungen im Netzwerk plus die Menge der normalerweise generierten Warnmeldungen. Es ist unnötig zu sagen, dass dies unglaublich überwältigend war.

Machine Learning (ML) verspricht eine bessere Erkennung unbekannter Bedrohungen bei geringerem Wartungsaufwand. Ziel ist es, abnormales Verhalten zu erkennen, anstatt sich bei der Erkennung jeder Bedrohung auf fest codierte Regeln zu verlassen.

Vor ML mussten die Detection Engineers einen Angriff analysieren, der bereits stattgefunden hat oder der stattfinden könnte (mit freundlicher Genehmigung von First-Party-Research) und Erkennungen für dieses potenzielle Ereignis schreiben. Wenn zum Beispiel ein Angriff entdeckt wurde, der bestimmte Argumente ausnutzt, die an einen Windows-Prozess gesendet werden, konnte man eine Regel schreiben, die nach diesen Argumenten sucht, um sie bei der Ausführung aufzurufen. Aber der Gegner konnte einfach die Reihenfolge der Argumente ändern oder sie anders aufrufen, um diese unzuverlässige Erkennung zu umgehen. Und wenn es legitime Verwendungszwecke für diese Argumente gäbe, dauerte es Tage (vielleicht sogar Wochen), um diese Fehlalarme aus der Erkennungslogik zu entfernen. 

Das Machine Learning versprach, diese Herausforderung erheblich zu verringern, und zwar auf zwei Arten:

• „Unbeaufsichtigte“ ML-basierte Anomalieerkennung: Analysten mussten nur entscheiden, in welchem Bereich sie nach unbekannten Verhaltensweisen suchen sollten, wie bei Anmeldungen, bei Prozessausführungen und beim Zugriff auf S3-Buckets. Dann lernte die ML-Engine das NORMALE Verhalten für diese Bereiche und markierte, was ungewöhnlich war. SANS DFIR gab 2014 ein berühmtes Poster mit der Aufschrift „Know Abnormal…Find Evil.“ heraus.

• Trainierte oder „überwachte“ ML-Modelle: Menschliche Analysten können etwas sehen, und ihr Gehirn kann die Punkte verbinden, wie es einem zuvor beobachteten Angriff ähnelt. Diese Experten sind in der Lage, zu erfahren , wie ein Angriff stattgefunden hat, und dieses Wissen anzuwenden, um unbekannte Angriffe zu finden, die einer ähnlichen Entwicklung folgen. Traditionell nutzten sie dieses Know-how bei der Bedrohungssuche, um Bedrohungen zu finden, die ihre Sicherheitsprodukte möglicherweise übersehen hatten. Mit maschinellem Lernen waren sie nun in der Lage, trainierte Modellerkennungen zu entwickeln, die in der Lage waren, aus früheren Angriffen zu lernen und neue Angriffe zu finden, die sich in ihrer Art und Weise ähneln. Die Konzentration auf das Verhalten – und nicht nur auf atomische Indikatoren wie Hashes, Zeichenfolgen in Dateien und URLs – ermöglicht Erkennungen mit einer längeren Haltbarkeit und einer höheren Rate an Angriffserkennung.

Wie wir gesehen haben, waren SIEMs früher eher historische Berichte über Probleme als echte End-to-End-Lösungen. SIEMs konnten Sie auf ein Problem aufmerksam machen, aber dann waren Sie auf sich allein gestellt, um es zu beseitigen. Das änderte sich mit der Einführung von SOAR: Security Orchestration, Automation und Response. Diese neue Produktlinie wurde entwickelt, um eine Funktionslücke in SIEMs zu schließen. Sie bietet einen Ort, an dem die Schritte, die ein Analyst zur Behebung eines Problems durchführen möchte, gesammelt und organisiert werden können, sowie Konnektoren zum Rest des Ökosystems, um die Reaktion einzuleiten. In unserer Analogie zur Polizei waren SOARs wie Verkehrspolizisten, die alle anderen Systeme anweisen, Befehle auszuführen. Sie waren der Klebstoff, der die Entdeckung des Angriffs durch das SIEM mit den Reaktionsmaßnahmen der anderen Systeme verband. 

Wie UEBA ist auch die Fähigkeit, Reaktionspläne zu organisieren und Aktionen von einer zentralen Stelle aus anzustoßen, zu einer Erwartung an moderne SIEMs geworden. Jetzt, im Lebenszyklus von SIEM 2.0, wird erwartet, dass SIEMs in der Lage sind, Daten in großem Umfang im gesamten Unternehmen zu sammeln (.gen 0), neue Bedrohungen zu erkennen, die Punktlösungen möglicherweise übersehen haben, und mithilfe von regelbasierten und auf Machine Learning basierenden Technologien (SIEM 1.0) über verschiedene Systeme hinweg zu korrelieren und die Planung und Ausführung von Reaktionsplänen zu ermöglichen (2.0). Es wurde sogar ein neues Akronym entwickelt - TDIR (Threat Detection, Investigation and Response) -, um die Fähigkeit zu beschreiben, das gesamte Ausmaß eines Angriffs zu erfassen.

SIEMs sind zu einer Grundlage für die Erkennung, Sichtung und Untersuchung von Bedrohungen in einem SOC geworden, obwohl sie eine grundlegende Herausforderung nicht angehen können: den massiven Fachkräftemangel in der Cybersicherheit. Eine von IBM in Auftrag gegebene und von Morning Consult durchgeführte Studie vom März 2023 ergab, dass SOC-Teammitglieder „nur die Hälfte der Warnungen erhalten, die sie an einem typischen Arbeitstag überprüfen sollten“. Das ist ein 50%iger blinder Fleck. Jahrzehntelange inkrementelle Verbesserungen zur Vereinfachung von Arbeitsabläufen, zur Automatisierung von Routineschritten, zur Anleitung von Junior-Analysten und mehr haben geholfen – aber nicht genug. Mit dem Aufkommen von verbraucherzugänglichen generativen Modellen der künstlichen Intelligenz mit Fachkompetenz im Bereich der Cybersicherheit ändert sich dies schnell. 

SIEMs sind traditionell sehr abhängig von den Menschen hinter dem Bildschirm – Alerting, Dashboarding und Bedrohungsjagd sind allesamt menschenintensive Vorgänge. Selbst frühe KI-Bemühungen wie KI-Copiloten hingen von der Fähigkeit des Analysten ab, diese Co-Piloten effektiv einzusetzen. Diese Revolution wird stattfinden, wenn die KI im Auftrag des Analysten arbeitet und die Notwendigkeit des „Chats“ entfällt. Stellen Sie sich vor, das System durchforstet alle Daten, ignoriert das Irrelevante und identifiziert das Kritische, entdeckt den spezifischen Angriff und erarbeitet spezifische Gegenmaßnahmen – und gibt so Ihren Experten den Freiraum, sich auf die Eindämmung der Auswirkungen auf das Geschäft zu konzentrieren.

Zum ersten Mal lernt die Technologie von erfahrenen Analysten und überträgt dieses Wissen automatisch auf jüngere Mitarbeiter. Generative KI hilft Sicherheitsexperten jetzt dabei, unternehmensspezifische Abhilfepläne zu entwickeln, Bedrohungen zu priorisieren, Erkennungen zu schreiben und zu kuratieren, Probleme zu beheben und andere routinemäßige und zeitaufwändige Aufgaben zu erledigen. Generative KI verspricht, die Feedback-Schleife zurück in das SOC zu automatisieren und so Tag für Tag kontinuierliche Verbesserungen zu ermöglichen. Wir können jetzt die OODA-Schleife mit diesem automatisierten Feedback und unserem Wissen schließen. 

Aufgrund der Natur großer Sprachmodelle (der Wissenschaft hinter der generativen KI) können wir endlich die Technologie nutzen, um über zahlreiche Datenpunkte hinweg zu argumentieren, genau wie ein Mensch es tun würde – allerdings in größerem Maßstab, mit höherer Geschwindigkeit und für ein breiteres Verständnis. Darüber hinaus können Nutzer mit großen Sprachmodellen in natürlicher Sprache interagieren, anstatt mit Code oder Mathematik, und so die Hürden für die Einführung weiter senken. Noch nie zuvor war ein Analyst in der Lage, Fragen in natürlicher Sprache zu stellen, wie etwa: „Enthalten meine Daten Aktivitäten in irgendeinem Bereich, die ein Risiko für mein Unternehmen darstellen könnten?“ Dies ist ein noch nie dagewesener Sprung nach vorn bei den Funktionen, die jetzt in ein SIEM für alle Mitglieder eines SOC eingebettet werden können. Generative KI hat sich zu einem leistungsstarken und präzisen digitalen SOC-Assistenten entwickelt. 

Die Produkte, die die KI-Revolution in den Arbeitsabläufen im Sicherheitsbetrieb nutzen, werden SIEM 3.0 bereitstellen.

In diesem Blog-Beitrag haben wir die Entwicklung von SIEM von der zentralen Datenerfassung über die Erkennung von Bedrohungen auf Unternehmensebene bis hin zur Automatisierung und Orchestrierung zur Beschleunigung der Problembehebung untersucht. Jetzt, in dieser dritten Phase der SIEM-Technologien, gehen wir endlich den massiven Fachkräftemangel im Bereich der Cybersicherheit an. 

Im zweiten Teil dieser Serie werden wir die Entwicklung von Elastic Security von einem TDIR zum weltweit ersten und einzigen KI-gesteuerten Angebot für Sicherheitsanalysen diskutieren. In der Zwischenzeit können Sie in diesem E-Book mehr darüber erfahren, wie Sicherheitsexperten auf das Aufkommen der generativen KI reagiert haben: Generative KI für Cybersicherheit: Eine optimistische, aber ungewisse Zukunft. Bleiben Sie dran für Teil zwei!