Wie Visas erster Elastic Workflow die Alarmtriage von 10–20 Minuten auf Sekunden reduzierte – dank eines kontrollierten KI-Schritts mit menschlicher Beteiligung

Im Rahmen einer umfassenderen Modernisierung seiner Sicherheitsabläufe von einem veralteten SIEM-System hin zu Elastic entwickelte das Team für Cybersicherheitstechnik von Visa seinen ersten agentenbasierten KI-Workflow im SOC: eine vierstufige Pipeline, die einen eingeschränkten, vom Menschen gesteuerten KI-Schritt verwendet, um IR-fähige Tickets zu erzeugen. Für eine Hochrisiko-Mainframe-Erkennung, die zuvor eine manuelle zweite Abfrage erforderte, sank die Triagezeit von 10–20 Minuten auf Sekunden, und das gleiche kontrollierte, prüfbare Muster ist nun auch bei anderen Erkennungen wiederverwendbar.

Visa migriert von einem veralteten SIEM-System zu Elastic und während dieser Migration baute das Cybersicherheit-Engineering-Team seine erste Elastic Workflow-Pipeline als Machbarkeitsstudie auf. Die gewählte Erkennung, eine Hochrisiko-Mainframe-Identitäts-Erkennung, erforderte zuvor, dass Analysten vom Alarm zu einer Folgesuche wechseln mussten, um den verantwortlichen Nutzer zu identifizieren, wobei die Ergebnisse je nach Analystenerfahrung mit Mainframe-Logs erheblich variierten. Das Team hat zwei Elasticsearch Query Language (ES|QL)-Abfragen verkettet, einen eingeschränkten KI-Schritt hinzugefügt, der eine strukturierte Zusammenfassung für das IR-Team erstellt, und einen Webhook verwendet, um das Ticket direkt in ihr IR-Ticketing-System zu übermitteln. Wenn der Alarm ausgelöst wird, ist die Triage nun in Sekundenschnelle statt in 10 bis 20 Minuten abgeschlossen, und das gleiche vierstufige Muster kann nun auch auf andere Erkennungen angewendet werden.

Visa sichert eine der größten Zahlungsumgebungen der Welt. Im Rahmen einer umfassenden Modernisierung von einem veralteten SIEM zu Elastic machte sich das Cybersicherheit-Engineering-Team daran, etwas zu schaffen, das Visa noch nicht skaliert hatte: eine kontrollierte, nachvollziehbare Möglichkeit, KI innerhalb der Sicherheitsoperationen zu nutzen. Das Balkendiagramm war spezifisch. Jeder KI-Schritt musste auditierbar, eng im Umfang und nachweisbar in den vom Team kontrollierten Daten verankert sein. Der erste Ort, an dem dieses Balkendiagramm getestet wurde, war eine hochriskante Mainframe-Identitätserkennung, bei der jeder Alarm das Incident-Response-Team 10 bis 20 Minuten manuelle Kontextsammlung kostete, bevor die Untersuchung überhaupt beginnen konnte.

Wenn diese Erkennung im alten SIEM-System ausgelöst wurde, musste sich das Incident-Response-Team einloggen, eine zweite Suche ausführen und herausfinden, welcher Nutzer hinter der Aktivität steckte. Die Erkennung hat das Ereignis erkannt. Der Analyst musste die Person noch identifizieren.

Die Herangehensweise des Teams war einfach: Wenn für jede handlungsrelevante Warnung eine zweite Abfrage erforderlich ist, bevor das IR-Team handeln kann, ist die Pipeline unvollständig. Verlagert man die zweite Abfrage nach vorn in die Pipeline selbst, erhält das IR-Team einen Fall, der bereits angereichert, zusammengefasst und bereit ist, an das Mainframe-Team zur Überprüfungen weitergegeben zu werden.

Das umfassendere Projekt von Visa ist die Migration der Erkennungslogik von einem veralteten SIEM zu Elastic. Bei dieser Art der Migration handelt es sich in der Regel um eine konzentrierte Regelkonvertierung. Das Team hat bewusst Raum geschaffen, damit Ingenieure neue Plattformfunktionen neben der Konvertierungsarbeit ausprobieren können.

Ein Ingenieur für Cybersicherheit im Team nahm an einer Elastic Workflows-Schulung teil, wählte eine Erkennung aus, die er bereits gut kannte, und arbeitete mit seinem Elastic Solutions Architect zusammen, um die erste Version zu erstellen. Das Elastic-Team erstellte repräsentative Testdaten aus den vom Ingenieur bereitgestellten Beispielen, entwickelte einen Starter-Workflow von Grund auf und gab ihn als Vorlage zurück, die der Ingenieur erweitern konnte.

Was bestehende Ansätze nicht bieten konnten, war eine native Automatisierung, die innerhalb derselben Sicherheitsplattform wie die Daten integriert war. Bei Visa wird die SOAR-Orchestrierung von einem separaten Automatisierungsteam betreut und auf einer separaten Platform ausgeführt, getrennt von den Erkennungen selbst. Mit Elastic Workflows läuft die gesamte Pipeline an einem Ort: Erkennung, Anreicherung, Validierung und Bereitstellung – alles nativ, alles in einer einzigen YAML-Datei, die der Ingenieur auf einem Bildschirm lesen und bearbeiten kann.

Workflows war aus einem bestimmten Grund auch der richtige Ausgangspunkt. Visa benötigte die vollständige Kontrolle darüber, was der KI-Schritt erhielt, was er produzierte und wie jede Entscheidung verifiziert werden konnte. Für eine regulierte Finanzdienstleistungsumgebung ist die Überprüfbarkeit die Voraussetzung für das Vertrauen in KI bei Sicherheitsoperationen. Workflows gaben dem Team ein Muster, das sie vollständig quantifizieren und verteidigen konnten, wobei jeder Schritt in einer einzigen YAML-Datei sichtbar war, bevor sie auf andere agentische Fähigkeiten auf Elastics Roadmap ausgeweitet wurden.

Im vorherigen Workflow war die Abfolge: Alarmierung, dann Untersuchung. Die Erkennung wurde ausgelöst. Das IR-Team meldete sich im alten SIEM an. Sie führten die Nachverfolgungssuche durch, um das Ereignis auf ein Terminal und einen Nutzer zurückzuführen. Mainframe-Protokolle sind für diese Art von Arbeit kein geeignetes Umfeld.

Drei Dinge machten den Vorzustand kostspielig:

• Die zweite Suche war unvermeidlich. Jeweils nur eine Person kann einem Terminal zugewiesen werden, aber Terminalwerte werden wiederverwendet. Um den Nutzer zu identifizieren, der hinter einem gemeldeten Ereignis steckt, musste ein Analyst nach dem nächstgelegenen vorherigen Login zu diesem Terminal, auf dieser Mainframe-Partition etwa zum Zeitpunkt des Ereignisses abfragen.
• Die Fähigkeiten der Analysten waren sehr wichtig. Erfahrene Analysten, die die Abfragesprache und die Mainframe-Ereigniscodes kannten, konnten dies schnell erledigen. Neuere Analysten, oder Analysten, die weniger mit Mainframe-Logs vertraut sind, haben deutlich länger gebraucht. Das Ergebnis war eine Abweichung sowohl in der Zeit als auch in der Qualität.
• Mainframe-Eventcodes sind komplex. Es gibt keinen einzigen Weg, ein Ereignis auf ein Ergebnis abzubilden. Die Analysten mussten häufig Systemcodes interpretieren, deren Bedeutung vom Kontext abhing, was die Arbeit verlangsamte und die Standardisierung des Ergebnisses erschwerte.

Zeit und Qualität flossen beide in die zweite Suche. Die Erkennung hatte das Ereignis identifiziert; der Analyst führte noch die Untersuchung durch, die eigentlich Teil des Ausgangs der Erkennung hätte sein sollen.

Die neue Pipeline läuft in vier verketteten Phasen innerhalb von Elastic Workflows:

1. Erkennung (primäre ES|QL-Abfrage): Auf einem fünfminütigen Timer mit einem zehnminütigen Rückblickfenster führt der Workflow eine schnelle, enge ES|QL-Abfrage gegen Mainframe-Protokolle durch und sucht nach der gezielten Identitätsaktivität. Die Erkennung ist absichtlich präzise; das Team erwartet nicht mehr als ein oder zwei Treffer pro Durchlauf, und historisch gesehen wird der Alarm nur wenige Male pro Jahr ausgelöst.
2. Anreicherung (sekundäre ES|QL-Abfrage): Für jedes zurückgegebene Ereignis führt der Workflow eine Folge-ES|QL-Abfrage, die den Terminalwert und die LPAR (Mainframe-Partition) vom primären Event nimmt und dann nach dem nächstgelegenen vorherigen Login zu diesem Terminal sucht. Da Terminals wiederverwendet werden, aber jeweils nur ein Benutzer zugewiesen wird, identifiziert der nächstgelegene vorherige Login den Benutzer hinter der Aktivität. Die Verifizierung ist schnell, weil die gleichen Abfragen, die das Ergebnis erzeugt haben, direkt für den Ingenieur zur Untersuchung vorliegen.
3. KI-Validierung: Das angereicherte Ereignis wird an einen vom Large Language Model (LLM) unterstützten Schritt übergeben. Das Modell erhält eine eingeschränkte Eingabeaufforderung: die Annahme, dass jeweils nur eine Person ein Terminal benutzen kann, die Details der primären Warnung und das Ergebnis der sekundären Abfrage. Seine Aufgabe ist es, zu überprüfen, ob die Daten die Schlussfolgerung stützen, und eine strukturierte Zusammenfassung zu erstellen, die den Namen und die ID des Nutzers, die Erkennung der ursprünglichen Warnung, und die Gründe enthält, warum diese Person der identifizierte Akteur ist. Das Modell entscheidet nicht über eine Eskalation; das tut das IR-Team.
4. Bereitstellung (Webhook): Die Zusammenfassung wird per Webhook an das IR-Ticketing-System geliefert. Wenn das Ticket erstellt wird, liest der IR-Ingenieur einen Fall, statt ihn zusammenzustellen.

Die wichtigste architektonische Entscheidung hierbei ist, dass die gesamte Pipeline nativ auf derselben Platform wie die Sicherheitsdaten ausgeführt wird. Es gibt kein separates SOAR-System, das nebenher läuft, kein separates Orchestrierungssystem, das gewartet werden muss, und keine Verbindung zwischen der Erkennung und dem Workflow.

Technische Highlights

• ES|QL-Primärabfrage auf einem Fünf-Minuten-Timer mit einem zehnminütigen Rückblick
• Die ES|QL-Sekundärabfrage verwendet Terminal und LPAR aus dem primären Ereignis und ermittelt den nächstgelegenen vorherigen Login.
• Die Erkennung wurde aufgrund der hohen Analystenkosten des zuvor erforderlichen manuellen zweiten Abfrageschritts gewählt.
• Der LLM-gestützte Validierungsschritt erhält einen eingeschränkten, strukturierten Prompt, keine freie Analyse
• Kontextfenster: Nur die letzten 5–15 Minuten relevanter Datensätze werden an das Modell weitergegeben, wodurch die gesendeten Tokens reduziert und der Arbeitskontext des Modells gestrafft wird
• Visa bewegt sich zwischen Anbietern und die Platform ist modellunabhängig
• Der Workflow ist eine einzelne YAML-Datei, die in einem Kibana-Bildschirm, ähnlich einem Code-Editor, erstellt und getestet wird.
• Webhook liefert die strukturierte Zusammenfassung direkt in das IR-Ticketsystem

Verkettete ES|QL-Erkennung und -Anreicherung in einem einzigen Workflow

Die Behandlung von Erkennung und Anreicherung als einen verketteten Ablauf, anstatt als zwei von Analysten vermittelte Schritte, hat den Rest der Pipeline ermöglicht. Das Piped-Modell von ES|QL ermöglicht es dem Team, den Ablauf deklarativ auszudrücken: Die primäre Abfrage identifiziert das markierte Ereignis, und die sekundäre Abfrageebene im Terminal-zu-Nutzer-Mapping ermittelt, wer es wahrscheinlich verursacht hat. Es gibt keine Analysten-Konsolensitzung dazwischen, und es gibt kein zweites Tool, in das man sich einloggen muss. Die Struktur des Workflows entspricht nun der Struktur der tatsächlichen Frage des Analysten (Wer hat das gemacht?), anstatt bei Ist etwas passiert?

Ein eingeschränkter KI-Schritt mit bewusst begrenztem Anwendungsbereich

Der KI-Schritt erfüllt eine spezifische Aufgabe: die Bestätigung, dass die Anreicherungsdaten die Schlussfolgerung unterstützen, und die Erstellung einer strukturierten Zusammenfassung, die das IR-Team in wenigen Sekunden lesen kann. Er generiert keine Erkennung. Er entscheidet nicht über eine Eskalation. Es wird die Annahme mitgeteilt, die der Analyse zugrunde liegt (es kann immer nur eine Person ein Terminal benutzen), und es wird der nächstliegende vorherige Login angegeben, um ihn mit dieser Annahme abzugleichen.

Diese Enge ist der springende Punkt. Die Entscheidung des Teams war nicht „ das Modell untersuchen zu lassen“, sondern „ das Modell überprüfen und zusammenfassen zu lassen, was die Abfragen bereits zurückgegeben haben.“ Jede KI-Entscheidung in der Pipeline wertet Daten aus, die das Team einsehen kann, und vergleicht sie mit Kriterien, die das Team kontrolliert. Das macht die Validierung überprüfbar und nicht undurchsichtig.

Token-effizientes Kontextfenster

Das Modell sieht nie mehr Daten als nötig. Die Pipeline filtert die übergebenen Einträge auf nur jene, die für das Zeitfenster des Ereignisses relevant sind, die letzten 5–15 Minuten, entsprechend der Rahmenbedingungen der Erkennung. Das Ergebnis ist ein kleineres Kontextfenster, weniger Tokens pro Entscheidung und eine engere Argumentation, weil das Modell nicht versucht, Einträge zu interpretieren, die nichts mit der Frage zu tun haben.

Native Automatisierung innerhalb der Sicherheitsplattform

Die gesamte Pipeline befindet sich in Elastic, zusammen mit den Daten. Es gibt keine separate Orchestrierungs-Platform, die gepflegt werden muss, keine fragile Integration, die während eines Vorfalls aufrechterhalten werden muss, und kein zweites Team, mit dem der Workflow koordiniert werden muss. In YAML erstellte Workflows können über HTTP auf andere Systeme zugreifen, sodass die Reichweite der Platform erweitert wird, ohne dass die ursprüngliche Heimat aufgegeben werden muss. Für Visa ist dies insbesondere von Bedeutung. Ein separates Automatisierungsteam ist derzeit für die SOAR-Orchestrierung auf einer anderen Platform als die Sicherheitsdaten zuständig. Dieses Team hat bereits um API-Zugriff auf Elastic gebeten, und das Cybersicherheits-Engineering-Team ist offen dafür, Workflows zu nutzen, um Reaktionsarbeiten zu übernehmen, die derzeit auf dem anderen Tool liegen. Das Ticket für die Konsolidierung auf eine einzige native Automatisierungsoberfläche ist innerhalb von Visa nicht mehr theoretisch.

Das sichtbarste Ergebnis ist Geschwindigkeit, aber das für den Betrieb wichtige Ergebnis ist Konsistenz. Die Interpretation von Mainframe-Log war zuvor einer der variabelsten Aspekte der Triage bei Visa: ein erfahrener Analyst konnte die Arbeit der zweiten Abfrage schnell erledigen; ein neuerer Analyst oder einer, der weniger mit Mainframe-Ereigniscodes vertraut war, benötigte deutlich länger und lieferte variablere Ergebnisse.

Durch die Integration der Zusammenstellung und der Zusammenfassung in die Pipeline, gehört der Teil des Workflows, der von der Kenntnis veralteter Abfragesprachen und Mainframe-Ereigniscodes durch den Analysten abhing, nicht mehr zu dessen Aufgaben. Der IR-Ingenieur liest eine strukturierte Zusammenfassung und entscheidet nach eigenem Ermessen, ob Maßnahmen zu ergreifen sind.

Die Erkennung selbst tritt selten auf, historisch gesehen nur wenige Male pro Jahr. Das ist beabsichtigt. Das Team hat es genau deshalb gewählt, weil es sich um einen Alarm mit geringem Volumen und hohem Einsatz handelt, bei dem die Kosten pro Alarm für den manuellen zweiten Abfrageschritt eindeutig die Eliminierung wert waren. Die wichtigere Neuigkeit ist jedoch, dass es sich hierbei um Visas ersten Produktionsworkflow dieser Art handelt, und das etablierte vierstufige Muster nun auch für andere Erkennungen angewendet werden kann.

Was ein IR-Ingenieur bei Visa nun sieht, wenn diese Warnung ausgelöst wird: ein Ticket mit dem ursprünglichen Ereignis, dem identifizierten Nutzer, dessen Name und ID angegeben sind, der Begründung und dem Link zurück zu den zugrunde liegenden Daten. Die Pipeline führte die zweite Abfrage durch, das LLM überprüfte und fasste die Ergebnisse zusammen, und der Webhook erstellte das Ticket. Die erste Handlung des Ingenieurs ist die Beurteilung, nicht die Abfragekonstruktion.

Der Mensch ist nach wie vor der Entscheidungsträger. Die Pipeline übernimmt die Zusammenstellung. Die KI führt die Überprüfung und Zusammenfassung durch. Der Ingenieur tut, was nur der Ingenieur tun kann: beurteilen, überprüfen und eskalieren. Die Arbeit, die nach vorn verschoben wird, ist die Arbeit, die wiederholbar war. Die Arbeit, die beim Ingenieur verbleibt, ist die Arbeit, die Urteilsvermögen erfordert.

Der Grund, warum dies das erste Workflow-Projekt von Visa ist, aber nicht das letzte, ist, dass die vierstufige Struktur portabel ist. Die konkrete Erkennung ist ungewöhnlich; das operative Vorgehen drumherum nicht. Überall dort, wo eine Erkennung bekannte, wiederholbare Folgesuchen erfordert, bevor ein Analyst handeln kann, gelten die gleichen vier Phasen.

Drei Prinzipien, die aus diesem Build übernommen wurden, gelten für jede Erkennung, bei der die zweite Abfrage den Engpass darstellt. Automatisieren Sie die bekannten Teile des Runbooks in die Pipeline selbst, denn wenn die Folgeschritte immer gleich ablaufen, handelt es sich nicht um Analystenarbeit. Geben Sie dem KI-Schritt eine Aufgabe, die eng genug ist, um überprüfbar zu sein: ein eingeschränkter Prompt, ein strukturierter Eingang, eine Zusammenfassung, die der Ingenieur anhand der Daten verifizieren kann. Der Kontext wird so eingeschränkt, dass das Modell nur die für den Zeitpunkt des Ereignisses relevanten Daten erhält und nicht die vollständigen Daten, die die Abfragen zurückgegeben haben. Das erste Prinzip ist am besten verallgemeinerbar. Die anderen beiden sorgen dafür, dass die KI verteidigbar bleibt.

Das vierstufige Muster (Erkennung, Anreicherung, Validierung, Bereitstellung) ist übertragbar. Das Team hat bereits andere Erkennungen im Migrationsumfang identifiziert, die von demselben verketteten, KI-zusammengefassten, über Webhook bereitgestellten Ansatz profitieren würden. Das Team evaluiert aktiv Attack Discovery, das Martin als die Fähigkeit beschreibt, die sie ursprünglich zu Elastic gezogen hat. Die Reihenfolge war bewusst: Workflows gaben Visa ein Muster, das es vollständig quantifizieren und verifizieren konnte, bevor es auf Fähigkeiten mit mehr interner Korrelationslogik ausgeweitet wurde, was der richtige Weg für einen regulierten Finanzdienstleistungs-SOC ist. Das Team baut parallel einen KI-Agenten für die Bedrohungserkennung auf und untersucht, wie Workflows die Reaktionsarbeit aufnehmen können, die derzeit von einer separaten Automatisierungsgruppe gehandhabt wird. Die Einhaltung des Veröffentlichungsrhythmus von Elastic ist jetzt auch Teil der Arbeit.

Visa ist eines der größten Zahlungsnetzwerke der Welt, und der Umfang seiner Sicherheitsoperationen spiegelt dies wider. Ihr Unternehmen migriert vielleicht heute noch nicht im Umfang von Visa, aber die gleichen Prinzipien gelten unabhängig davon, ob Sie Ihre erste Erkennung umstellen oder ein komplettes SOC neu aufbauen: Wenn die Warnung eine zweite Abfrage erfordert, bevor Maßnahmen ergriffen werden können, ist die Pipeline unvollständig, und das vierstufige Muster funktioniert in jeder Phase des Prozesses.

Sehen Sie, wie Elastic Workflows es Ihnen ermöglicht, die Untersuchung von vornherein in Ihre Erkennungspipeline zu verlagern.