Skalierung der Triage von Sicherheitswarnungen mit spezialisierten Agenten auf Databricks

Was wäre, wenn ein niedriger Schweregrad nicht gleichbedeutend mit niedriger Priorität wäre?

Databricks speist Petabytes an Sicherheitslogs aus einer Vielzahl von Quellen – darunter Endpoint-Sicherheitstools, Cloud-Aktivitätsprotokolle und Threat-Intelligence-Feeds – in unser Security Lakehouse ein. Unsere Erkennungsarchitektur überwacht diese Daten kontinuierlich auf böswillige Aktivitäten. Jedes identifizierte Signal landet in einer zentralen Alerts-Tabelle, wo es auf die Überprüfung durch einen Incident Response (IR)-Analysten wartet.

Eine echte Bedrohung in Tausenden von täglichen Sicherheits-Alerts zu finden, ist die klassische Suche nach der Nadel im Heuhaufen. Die meisten Teams bewältigen diese Last, indem sie Alerts nach Schweregrad priorisieren. Teams triagieren die HIGH- und MEDIUM-Meldungen und arbeiten die LOW-Meldungen ab, sobald Bandbreite vorhanden ist.

Bei Databricks bearbeitet unser IR-Team Sicherheits-Alerts über alle drei Prioritätsstufen hinweg. In der Vergangenheit priorisierte das Team HIGH- und MEDIUM-Alerts aufgrund des hohen Volumens und der geringen Aussagekraft (low fidelity) von LOW-Alerts. Jedes größere Sicherheitsteam steht vor demselben Kompromiss: die Anzahl der Analysten erhöhen, die Alert-Schwellenwerte anheben und blinde Flecken in Kauf nehmen oder einen Weg finden, den Prozess zu automatisieren. Wir haben uns für Letzteres entschieden und setzen Agenten ein, die logisch denken und Entscheidungen in großem Maßstab treffen können.

Das spricht für spezialisierte Agenten

Um zu validieren, ob Agenten Sicherheits-Alerts zuverlässig triagieren und eskalieren können, haben wir mit Alerts mit niedrigem Schweregrad begonnen. Unser Ziel war einfach: die Alerts zu identifizieren, die eine weitere Untersuchung rechtfertigen.

Wir haben anfangs einen naiven Ansatz gewählt, alle relevanten Alert-Daten in einen einzigen Prompt gepackt und ein Foundation Model entscheiden lassen, was eskaliert werden soll. Dieser Ansatz führte zu einer Eskalationsrate von 50 %. Die Hälfte aller Alerts an Analysten weiterzuleiten, war keine Triage, sondern nur eine andere Art von Rauschen.

Das Problem war der Kontext. Ein einzelner Agent, der über jeden Alert nachdenkt, hat keine Möglichkeit zu unterscheiden, wie ein abnormales Verhalten für die jeweilige Quelle aussieht. Alles, was für eine präzise Triage eines Alerts erforderlich ist – seine False-Positive-Muster, Verhaltens-Baselines und die relevante Anreicherung –, ist quellenspezifisch. Ohne diesen Kontext stand dem Modell nur allgemeines Cybersecurity-Wissen zur Verfügung, und das reichte für eine genaue Triage nicht aus.

Architektur: Eine Flotte von Agenten

Wir haben die Pipeline um 17 quellenspezifische Agenten herum neu aufgebaut, von denen jeder auf eine einzige Erkennungsquelle abgestimmt ist, da der für eine präzise Triage erforderliche Kontext stark quellenspezifisch ist. Eine einzige Quelle kann Dutzende verschiedener Erkennungen ausgeben, und der zugehörige Agent verarbeitet sie alle.

Wir haben außerdem einen dedizierten Threat Intelligence (TI)-Agenten, der neben der Triage-Flotte von Agenten für niedrige Schweregrade läuft und von jedem Agenten aufgerufen werden kann, wenn dieser auf einen Indikator oder ein Verhalten stößt, das eine tiefere Untersuchung erfordert. Der TI-Agent fragt unsere Threat-Intelligence-Quellen ab und liefert eine strukturierte Bewertung zurück: Ist dieses Artefakt als bösartig bekannt, unbekannt oder harmlos. Das ist wichtig, da rohe Indicators of Compromise ohne Kontext bedeutungslos sind. Eine IP-Adresse ist nur eine Zahl. Dieselbe IP, angereichert mit „mit hoher Wahrscheinlichkeit mit einer C2-Infrastruktur der letzten 14 Tage verknüpft“, ist für den Agenten sofort verwertbar.

Mithilfe von Structured Streaming auf Databricks werden Alerts mit niedrigem Schweregrad direkt bei der Auslösung erfasst, vom TI-Agenten mit zusätzlichem Kontext angereichert und zur Überprüfung an den entsprechenden Sub-Agenten weitergeleitet.

Jeder Agent folgt denselben Designprinzipien:

Deterministische Filterung. Programmatische Prüfungen gleichen Alert-Titel und Kontextfelder ab, um als harmlos bekannte Signale zu unterdrücken (umgebungsspezifische Nuancen wie Listen vertrauenswürdiger IPs, Aktivitäten von Service-Konten, erwartetes Tool-Verhalten) und sofortige Entscheidungen ohne LLM-Aufruf zu treffen. Diese bewältigen je nach Quelle 30–95 % des Alert-Volumens. Dazu gehören Dinge wie „bekannte, sichere IAM-Rolle führt erwartete Operationen aus“ oder „Admin-E-Mail führt routinemäßige Workspace-Governance durch“. Die Filterung kann auf der Erkennungsebene oder direkt neben der Triage-Logik selbst stattfinden.

Kontextanreicherung. Bevor das LLM den Alert sieht, ruft der Agent den jüngsten Alert-Verlauf für die betroffene Entität, damit zusammenhängende Aktivitäten und andere relevante Signale ab. Agenten können während der Anreicherung auch andere agentische Funktionen aufrufen – beispielsweise den dedizierten Threat Intelligence-Agenten, wenn ein Alert eine untersuchenswerte IP oder Domain enthält.

Spezialisierte Prompt-Funktionen. Jeder Alert-Titel wird einer Prompt-Funktion zugeordnet. Beispielsweise gehen Alerts zu anomalem S3-Zugriff an eine Funktion mit Anweisungen zur Bewertung von IAM-Recon, und Alerts zur Rechteausweitung (privilege escalation) gehen an eine Funktion, die erwartete von unerwarteten Mustern bei der Rollenübernahme unterscheidet. Wenn keine dedizierte Funktion passt, verarbeitet ein generischer Fallback-Prompt den Alert. Prompt-Funktionen werden im Single-Turn-Modus (ein LLM-Aufruf) oder im agentischen Modus (Multi-Turn-Tool-Calling-Schleife) ausgeführt, je nachdem, ob der Alert zusätzlichen Kontext für eine sichere Triage benötigt.

Gemeinsame Tools. Tools sind optional und agentenspezifisch. Wenn die Triage mehr Kontext erfordert – rohe Cloud-Audit-Logs, quellübergreifend korrelierte Alerts oder den IdP-Aktivitätsverlauf –, statten wir den Agenten mit Tools aus, um diesen abzurufen, und das LLM entscheidet basierend auf der Eindeutigkeit der Beweise, ob und wann diese aufgerufen werden.

Gemeinsame Hilfsprogramme (Utilities). Um den Aufwand für die Verwaltung mehrerer Agenten zu minimieren, haben wir gemeinsamen Utility-Code in ein einheitliches Framework ausgelagert, das den Aufruf von Agenten, Wiederholungsversuche (Retries) und die Leistungsbewertung übernimmt. Die gesamte quellübergreifend konsistente Logik befindet sich hier, einschließlich der LLM-Aufrufschleife, des Parsens von Entscheidungen, des Tool-Dispatches, der Ergebnispersistenz in Delta-Tabellen, des Token-Trackings, des MLflow-Tracings und der Erkennung von Prompt-Injections.

LLM-Logik und Entscheidung (Disposition). Das Modell analysiert das Beweispaket und gibt eine strukturierte Ausgabe zurück, einschließlich einer Entscheidung (eskalieren, überwachen oder schließen) zusammen mit einer unterstützenden Analyse.

Kostenmanagement. Es gibt drei Kontrollmechanismen für die Ausgaben. Erstens stellt die deterministische Filterung sicher, dass Alerts, die bekannten harmlosen Mustern entsprechen, niemals ein LLM erreichen. Der günstigste Aufruf ist der, den man gar nicht erst tätigt. Zweitens summiert ein Cost-Tracker die geschätzten Ausgaben für jeden Batch und stoppt die Verarbeitung, wenn eine konfigurierbare Obergrenze erreicht wird, wobei verbleibende Alerts als übersprungen markiert werden. Drittens setzt ein tägliches Alert-Limit eine Obergrenze für die täglichen Gesamtkosten, unabhängig vom eingehenden Volumen. Innerhalb jedes Alerts verhindern Tool-Aufruf-Budgets pro Kategorie unkontrollierte Erkennungsschleifen, in denen ein LLM andernfalls unendlich lange nach zusätzlichem Kontext suchen würde.

Wenn der Agent entscheidet zu eskalieren, wird der Alert zu einem Ticket in der IR-Warteschlange, wo Analysten sowohl den rohen Alert als auch die Analyse des Agenten überprüfen, bevor sie eine endgültige Triage-Entscheidung treffen. Wenn ein Analyst der Eskalation eines Agenten widerspricht, wird das Ticket als False Positive gekennzeichnet, und dieses Feedback wird zur Feinabstimmung der Leistung des Agenten verwendet. Wir haben festgestellt, dass von Agenten eskalierte Low-Alerts etwa zehnmal häufiger True Positives waren als bestehende Alerts, die als HIGH- oder MEDIUM-Schweregrad priorisiert wurden.

Der menschliche Benchmark hinter jeder Agentenentscheidung

Wenn ein menschlicher Analyst ein eskaliertes Ticket überprüft, wird seine Entscheidung, den Agenten zu bestätigen oder zu überstimmen, zur Ground Truth für die Bewertung. Im Gegensatz zu deterministischen Programmen, bei denen man gegen eine feste Spezifikation testen kann, fällen Agenten Ermessensentscheidungen. Derselbe Alert kann bei verschiedenen Ausführungen unterschiedliche Ergebnisse liefern. Anstatt also gegen eine Spezifikation zu testen, testen wir gegen einen Standarddatensatz, der von IR-Analysten entwickelt wurde, die bereits wissen, wie eine qualitativ hochwertige Triage-Entscheidung aussieht.

Jede Agenten-Anfrage wird mit MLflow aufgezeichnet, wobei Eingaben, Zwischenschritte und Endergebnisse erfasst werden. Wenn IR-Analysten Tickets im Rahmen ihres normalen Workflows kennzeichnen (labeln), wird jedes Label direkt im entsprechenden MLflow-Trace als erwartete Antwort aufgezeichnet. Diese gelabelten Traces bilden einen Ground-Truth-Datensatz, der die Entscheidungen der Analysten in großem Maßstab erfasst. Dieser Datensatz wird zum Benchmark für die Bewertung zukünftiger Prompt-Änderungen, bevor diese produktiv gehen.

Um über False Positives hinaus zu messen, planen wir den Einsatz der Databricks Review App, einer Schnittstelle zur Überprüfung von Alerts und zur Kennzeichnung von MLflow-Traces. Analysten können die Eingaben, die Logik und die Entscheidung des Agenten für jeden Alert einsehen und das erwartete Ergebnis direkt im Trace festhalten. Dies ermöglicht es Analysten, auch nicht eskalierte Alerts zu überprüfen, wodurch die Ground-Truth-Abdeckung für Alerts, die der Agent überwachen oder schließen wollte, ausgebaut wird und wir einen vollständigen Standard für alle drei Entscheidungen erhalten.

Ergebnisse

Sicherheitsagenten überprüfen mittlerweile 100 % der Alerts mit niedrigem Schweregrad. Zu den wichtigsten Kennzahlen gehören:

• Agenten haben über 18.000 Alerts mit einer Eskalationsrate von 3,2 % triagiert
• Von Agenten eskalierte Alerts mit niedrigem Schweregrad waren etwa zehnmal häufiger True Positives als Alerts mit HIGH- oder MEDIUM-Schweregrad
• Mediane Triage-Zeit: 10,5 Sekunden
• Über 6.500 eingesparte Analystenstunden in den ersten 30 Tagen

Bemerkenswerte Erkenntnisse, die von Agenten eskaliert wurden:

• Reduzierung der False-Positive-Rate einer Alert-Quelle von 72 % auf 3,4 %
• Identifizierung von 22 verdächtigen, geparkten oder bösartigen Domains
• Aufdeckung eines Falls, in dem ein Benutzer gecrackte Software heruntergeladen und ausgeführt hat; der Agent markierte Verhaltensindikatoren, die auf einen Richtlinienverstoß und böswillige Absichten hindeuteten.

Was wir gelernt haben

LLMs halluzinieren bei Sicherheitsdaten mit hoher Entropie. Hashes, zufällige Subdomains und generierte Dateinamen sind für Sprachmodelle eine Herausforderung. Modelle sind gut darin, logische Schlüsse über Sprache zu ziehen, da Sprache Mustern folgt. Sicherheitsartefakte wie Hashes sind bewusst musterfrei, was sie für LLMs besonders schwierig macht. Um Genauigkeit zu gewährleisten, nutzen wir das Modell für logische Schlussfolgerungen und nicht für den Informationsabruf. Spezifische Artefaktwerte werden über Tool-Aufrufe aus autoritativen Quellen abgerufen, nicht aus dem Speicher des Modells.

Kontext ist alles. Die größten Leistungssteigerungen wurden erzielt, indem historische Warnmeldungsdaten, False-Positive-Raten pro Warnmeldungstyp und explizite Verhaltensmuster zu jedem Prompt hinzugefügt wurden. Bei der Verarbeitung einer Warnmeldung ruft der Triage-Agent den Warnmeldungsverlauf der letzten sechs Monate für den betroffenen Benutzer ab. In mehreren Fällen eskalierten Agenten Warnmeldungen nicht, weil das auslösende Ereignis für sich genommen eine hohe Konfidenz aufwies, sondern weil es das dritte oder vierte verdächtige Signal desselben Benutzers war. Diese Art von Verhaltenskorrelation ist etwas, das herkömmliche deterministische Erkennungsregeln nur schwer erfassen können.

Automatisieren Sie das Vorhersehbare und lassen Sie Agenten nur über das Unvorhersehbare urteilen. Wann immer möglich, sollten Sie sich für deterministische Workflows entscheiden, um den Bereich einzuschränken, den das LLM analysieren muss. Je offener die Anweisungen sind, desto höher ist die False-Positive-Rate. Präzise definierte Schritt-für-Schritt-Anweisungen für Agenten schnitten durchweg besser ab als vage Prompts. Die Anwendung einer regelbasierten Filterung, bevor das LLM eine Warnmeldung sieht, ist eines der effektivsten Beispiele hierfür.

Auf Databricks entwickelt

Dieses System wurde auf Databricks entwickelt. Es nutzt Spark Structured Streaming für die Erfassung von Warnmeldungen in Echtzeit, Delta-Tabellen für die Speicherung und Berichterstellung von Warnmeldungen, MLflow Tracing zur lückenlosen Erfassung jeder Agentenentscheidung und die Databricks Review App, damit Analysten Traces kennzeichnen und Ground Truth direkt aus Produktionsdaten erstellen können.

Bei Databricks entwickeln wir die Tools, die wir selbst nutzen. Dies ist ein Beispiel dafür, wie unsere eigene Plattform KI-native Sicherheitsabläufe unterstützt. Als Nächstes: Wie Databricks Genie Untersuchungen in natürlicher Sprache in das SOC bringen kann, sodass IR-Analysten Warnmeldungsdaten abfragen, den Kontext untersuchen und Bedrohungen im Dialog analysieren können.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag