Mike Nichols und Jörg Hesske von Elastic im Gespräch KI soll SIEM-Systeme ersetzen

Anbieter zum Thema

Fsas Technologies GmbH

Bislang positionierten Anbieter KI-gestützter Security-Software ihre Lösungen gerne als Ergänzung bestehender SIEM-Systeme. Elastic tritt mit Elastic Security hingegen an, SIEM zu erübrigen – und den langweiligen Teil der Arbeit im SOC gleich mit. Wie die Automatisierung des SOC-Alltags funktionieren soll, erläutert dieser Beitrag.

Das Kernproblem im Security Operations Center (SOC) besteht laut Mike Nichols, Vice President Security von Elastic, darin, dass die Fachleute dort unterfordert sind: „Man stellt einen Detektiv ein und schickt ihn auf Streife“, sagt er. Dies reduziere die hochbezahlten Experten zu „Streifenpolizisten, die herumlaufen und Dinge tun, die keinen Spaß machen.“ Den unspaßigen Teil der SOC-Arbeit könne aber künstliche Intelligenz (KI) übernehmen.

Security: Die KI soll’s richten

Der Ruf nach KI erschallt in der Security-Welt allerorten. Die KI-Unterstützung erscheint dabei in der Regel als Blackbox: Das Security-Team kippt alle Daten hinein, die es zusammenkratzen kann, die KI lässt ihre algorithmische Alchemie walten, und dann ist der Angriff hoffentlich abgewehrt. Zeitgleich aber hat generative KI mit Halluzinationen zu kämpfen: Fehlt ihr benötigter Kontext, fabuliert sie munter drauflos. Diesen Kontext bilden im SOC aber sensible Unternehmensinterna. Entscheider möchten diese ungern in eine Public Cloud exportieren, damit die dortige KI verlässlicher arbeiten kann.

Wie will Elastic dieses Dilemma auflösen? Hier hilft ein Blick auf die Historie des Anbieters: Gegründet 2012 in Amsterdam und mit zweitem Hauptsitz im Silicon Valley, ist es das Unternehmen hinter der Suchmaschine Elasticsearch. Diese kommt bei tausenden Unternehmen für die Suche nach Inhalten ebenso zum Einsatz wie für die Analyse diverser Datenbestände, von Logdateien bis zu Geschäftsinformationen oder eben Security-Daten. „Wir sind die am häufigsten eingesetzte Vektordatenbank der Welt“, sagt Nichols stolz. Elastic weiß also, wie man mit Daten umgeht – und wie man sie so aufbereitet, dass eine KI etwas damit anfangen kann.

Unternehmenskontext für das LLM

Es geht also darum, einem KI-Sprachmodell (Large Language Model, LLM) Unternehmensdaten auf verlässliche, skalierbare und datenschutzkonforme Weise zu liefern. „Es gibt verschiedene Möglichkeiten, wie Sie Ihren Kontext in diese Modelle einbringen können“, sagt Nichols. Das Problem: „In der Regel ist das Training eigener Modelle oder die Feinabstimmung von Modellen ein teures Unterfangen. Außerdem ändern sich Sicherheitsdaten so häufig. Jede Sekunde gibt es neue Warnungen im System.“

Statt auf proprietäres Modelltraining setzt Elastic deshalb auf ein Verfahren namens Retrieval Augmented Generation (wörtlich: um Datenabfrage angereicherte Erzeugung), kurz RAG – ein lustiges Akronym, bedeutet „rag“ im Englischen doch „Lappen“ oder „Putzlumpen“. Aber das Verfahren wischt ja in der Tat Datentröpfchen aus allen Ecken zusammen, um sie dann in einen gut transportablen Dateneimer zu wringen.

Elastics Security-Lösung basiert auf der hauseigenen Suchplattform, die der Anbieter letzten Sommer um einen KI-Assistenten ergänzt hat. Stellt man diesem eine Frage, durchforscht er die Daten automatisch.

„Zuerst sucht er mit Elastic, vektorisiert den relevanten Inhalt und fügt ihn dann zusammen mit dem von uns aufbereiteten Prompt [Eingabeaufforderung, d.Red.] zum Kontextfenster hinzu“, erklärt Nichols. „Der Prompt ist die Frage, das Kontextfenster enthält zusätzliche Daten. Diese fließen dann an das LLM.“ So erlaube es der RAG-Ansatz, mittels Daten aus dem Internet trainierte LLMs mit unternehmenseigenem Kontext zusammenzuführen, um spezifische, relevante Antworten zu geben.

Offenheit als Alleinstellungsmerkmal

Nun ist Elastic längst nicht der einzige Anbieter, der Daten mittels RAG aufwischt: Hyperscaler wie Google und Amazon nutzen das Verfahren, ebenso Enterprise-Softwareanbieter wie IBM oder Cohesity. Was Elastic vom Rest der Putzkolonne abhebt, ist Offenheit. Damit ist nicht nur gemeint, dass die Elastic-Lizenz Open Source ist; vielmehr ist der Anbieter auch offen in der LLM-Wahl.

„Im Cybersecurity-Bereich haben sich die meisten unserer Konkurrenten für das Finetuning eines eigenen Modells entschieden“, so Nichols. Damit sei der Anwender an das jeweilige Ökosystem gebunden. „Wenn in Deutschland andere Datenschutzbestimmungen gelten, kann es sein, dass man ein Modell, das bei einem Cloud-Anbieter in einem anderen Gebiet gehostet wird, nicht verwenden kann“, warnt er.

Deshalb verfolgt Elastic einen agnostischen Ansatz: „Wir arbeiten im Grunde mit jedem Modell, das es gibt. Und natürlich haben unsere Anbieter, die diese Modelle hosten, z.B. Google, Rechenzentren in Frankfurt“, so Nichols.

On-Premise-Betrieb möglich

Im Security-Kontext ist aber vor allem von Vorteil, dass Elastic die gewünschte Kombination von Suchplattform und LLM auch lokal betreiben kann. „Viele unserer Kunden bevorzugen eine vollständig entkoppelt Umgebung“, sagt Nichols. So könne ein Unternehmen z.B. das LLM des französischen Anbieters Mistral AI in einer isolierten On-Premise-Umgebung betreiben.

Mit Blick auf den DACH-Markt ergänzt Jörg Hesske, Area Vice President EMEA Central bei Elastic: „Nur wenige Unternehmen gehen voll in die Cloud, weil sie all diese Compliance-Probleme usw. haben. Deshalb wollen die meisten von ihnen eine gemischte Umgebung nutzen.“ Elastic schlage die Brücke zwischen internen Daten und den Daten aus dem öffentlichen Internet, die ein Unternehmen für seine KI nutzen will.

Schneller mit KI durchstarten

RAG verkürzt laut Nichols die Einführungszeit für die KI-gestützte Security-Analyse praktisch auf null: „Der Punkt ist, dass wir diese Modelle nie trainieren müssen“, sagt er. Zugleich sinke das Risiko der gefürchteten Halluzinationen, die schon so manchen LLM-Einsatz spektakulär aus den Ruder laufen ließen.

„Halluzinationen treten [im SOC, d.Red.] typischerweise als falsch-positive Warnungen auf“, so Nichols. „Sie entstehen in der Regel, wenn etwas zu weit gefasst oder nicht spezifisch genug für Ihre Umgebung ist. RAG fügt den spezifischen Kontext hinzu, der Ihre TTPs [Taktiken, Techniken und Prozeduren, d.Red.] kennt, oder auch Dinge wie die Art und Weise, wie Sie zuvor auf einen Vorfall reagiert haben.“ Dies senke die Wahrscheinlichkeit von Halluzinationen zwar nicht auf null, verringere sie aber erheblich. „Jedes Modell, das wir verwenden, ist also ‚out of the box‘ einsetzbar“, sagt Nichols.

Normalisierte Daten und Fokus auf Angriffsmuster

Wie aber weiß die RAG-Lösung, welche Unternehmensressourcen die kritischsten sind? „Der erste wichtige Schritt ist ein offener Standard für Ihr Datenmodell. So haben wir schon früh ein offenes Schema oder einen offenen Standard für die Normalisierung von Daten entwickelt“, so Nichols. Dieses habe Elastic an das OTel-Projekt (Open Telemetry) übergeben. „Sie können jede beliebige Datenquelle einbinden, und die Felder, die wir verwenden, um dem Modell im RAG-Kontext Priorität mitzuteilen, sind immer dieselben.“

Der zweite Schritt besteht laut Nichols darin, den Prompt korrekt anzupassen. Hier verwende Elastic MITRE ATT&CK, um Angriffe zu priorisieren – und nicht nur einen einzelnen Alarm. Deshalb benötige ein Unternehmen, um Angriffe zu erkennen, keine Details zu den betroffenen Systemen oder Benutzern: „Was man betrachtet, ist eine Abfolge von Ereignissen, von denen man weiß, dass sie mit einem bekannten Angriff, einer bekannten Taktik oder Technik aus dem MITRE-Framework verbunden sind“, sagt der Security-VP. „Das Gute daran ist, dass die Priorisierung auf der Grundlage des Angriffs phänomenal gut funktioniert, selbst wenn Sie keine Informationen über Ihr Objekt haben.“ Mit Kontext aus Quellen wie der CMDB könne man die Priorisierung lediglich noch verfeinern.

Drittsysteme und Threat Intelligence einbinden

Über offene APIs kann ein Anwenderunternehmen die Lösung an Drittsysteme wie bestehende Security-Lösungen anbinden und auch Threat Intelligence Feeds integrieren. Diese lassen sich dann heranziehen, um den Kontext um zusätzliche aktuelle Warnungen anzureichern.

„Sehr spannend“ ist laut Nichols „die Tatsache, dass Informationen oft eher in der Grauzone liegen. Sie sind nicht spezifisch genug, um eine Warnung auszulösen, aber wichtig genug für einen Analysten, um sie bei der Untersuchung zu berücksichtigen.“ Er meint damit Aspekte wie Benutzer, bei denen es in der Vergangenheit schon wiederholt Probleme gab. Auch dies lasse sich integrieren, und zwar zum Zeitpunkt der Analyse: „Analysten erhalten sozusagen eine Just-in-Time-Untersuchung.“

Das Ergebnis ist laut dem Elastic-Mann ein Fokus auf die tatsächlich relevanten Angriffsversuche: „Wir nehmen das Wichtigste heraus und erstellen sozusagen ein neues Dashboard, das sagt: ‚Hey, schau dir das an!‘“

Nachfolger von SIEM-Systemen

Das wirft die Frage auf, ob ein SOC dann überhaupt noch ein SIEM-System (Security Information and Event Management) braucht – außer höchstens noch für Dokumentationszwecke zum Nachweis der Compliance mit DSGVO, NIS 2 etc. „Viele Kunden wechseln von ihren bestehenden SIEMs zu Elastic, aber das braucht Zeit“, sagt Nichols. „Letztendlich ist die Idee, dass wir das zentrale SIEM oder das zentrale Analysesystem innerhalb des Ökosystems sind.“

DACH-Chef Jörg Hesske verweist hier auf die Wirtschaftslage: „In einem wirtschaftlich schrumpfenden Umfeld muss man Kosten senken.“ Elastic unterstütze die Unternehmen bei der Migration: „Wir helfen ihnen, und wenn sie dann soweit sind, können sie die Tools abschalten. In der Tat gibt es eine ganze Reihe von Unternehmen, die das bereits planen.“

Die hauseigene Security-Lösung erleichtere es zudem, von der Erkennung zur Mitigation von Angriffen überzugehen. Elastic verfüge über Komponenten für die Remediation und unterstütze per API die Integration in Ticket-Systeme wie Jira oder ServiceNow. Zudem helfe Elastics KI-Assistent dabei, Abwehrmaßnahmen in Code zu gießen: „Wir glauben fest daran, dass alles Code ist, und deshalb legen wir Dinge gerne in einer Codebasis für die Mitigation oder Integration ab“, so Nichols. Generative KI habe sich bei der hocheffizienten Code-Entwicklung sehr gut bewährt.

Abwehraufgaben auf mehr Schultern verteilen

Der Personalnotstand im SOC rührt laut Mike Nichols nicht zuletzt daher, dass hier bislang nur Security-Spezialisten zum Einsatz kommen konnten. RAG und KI erlauben es seiner Einschätzung nach, den Einzugskreis für die Mitarbeit im Security-Umfeld zu vergrößern: „Wir sehen, dass KI mehr analytisch denkende Menschen, Finanzanalysten und andere, die vielleicht nicht aus dem IT-Bereich kommen, einbeziehen kann und ihnen die Möglichkeit gibt, die Business-Analyse vorzunehmen.“

„Sicherheitsanalysten sind eine seltene Spezies“, ergänzt DACH-Chef Hesske. Gerade die öffentliche Hand in Deutschland könne sich deren hohe Gehälter nicht leisten: „Sie haben wirklich Mühe, die Leute zu bekommen. Und die Leute, die sie haben, schauen sich den ganzen Tag lang Alarme an, was völlig ineffektiv ist.“ Elastic hingegen steigere die Effizienz der Analysten erheblich.

Verbrauchsbasierte Lizenzierung

Die Lizenzkosten hängen dabei vom Ressourcenverbrauch ab. „Der Preis richtet sich danach, wie schnell und wie lange man die Daten durchsuchen möchte“, sagt Nichols. „Kunden, die Antworten im Millisekundenbereich brauchen, nutzen eine ganze Menge Ressourcen für eine kleinere Datenmenge. Als Sicherheitsexperte brauchen Sie aber keine Reaktionszeiten im Millisekundenbereich.“

Dies lasse sich durch preiswerte LLMs ergänzen. „Es gibt einige Modelle, die extrem erschwinglich sind“, sagt Nichols. Sehr angetan zeigt er sich hier von Anthropics Claude 3.

Damit sei die RAG-Software für kleine wie auch für große Unternehmen von Interesse. „Unser ethisches Grundprinzip ist, dass Sicherheit demokratisiert werden muss“, sagt Nichols. Er verweist auf einen kleinen Anwender, den Ride-Sharing-Anbieter Bolt: „Die haben kein großes Security Operations Center, aber sie nutzen uns, weil die KI-Workflows ihr IT-Team in die Lage versetzen, für mehr Sicherheit zu sorgen.“ Zugleich biete Elastic die Konfigurierbarkeit und Flexibilität, um selbst in ein sehr anspruchsvolles SOC eines Großunternehmens zu passen.

Ebenso eigne sich die Lösung für MSSPs (Managed Security Service Provider). „Für den deutschen Mittelstand ist das sehr interessant, weil er sich kein eigenes Sicherheitsteam leisten kann“, sagt Jörg Hesske.

Wenn Elastics Security-Analytics-Lösung tatsächlich so effektiv, schnell und halluzinationsarm funktionert wie vom niederländisch-amerikanischen Anbieter versprochen, könnte also sogar hierzulande für manch einen MSSP der „amerikanische Traum“ wahr werden. Denn der sprichwörtliche Aufstieg „vom Tellerwäscher zum Millionär“ heißt im US-Sprachgebrauch „from rags to riches“ – von Lumpen zu Reichtümern. Lässt sich durch RAGs die Sicherheit der Anwenderunternehmen garantieren, seien die Reichtümer den MSSPs gegönnt.

(ID:50132783)