Elastic Workflows ist allgemein in Version 9.4 verfügbar. Es handelt sich um die direkt in Elastic integrierte Automatisierungsschicht, die dort läuft, wo Ihre Daten gespeichert sind – in den Bereichen Sicherheit, Beobachtbarkeit und Suche. Dieser Beitrag konzentriert sich zwar auf die Sicherheit, die gleichen Workflow-Funktionen gelten jedoch für alle Lösungen, ohne dass eine separate Plattform bereitgestellt und keine Daten verschoben werden müssen. Wenn eine Warnung ausgelöst wird oder ein Zeitplan eintritt, wird ein Workflow ausgeführt: Abfrage von Elasticsearch, Anreicherung mit Bedrohungsdaten, Erstellung von Fällen, Aufruf externer APIs und Benachrichtigung Ihres Teams. Definieren Sie es in YAML oder beschreiben Sie es in natürlicher Sprache und lassen Sie die KI den Workflow generieren.
Mit der technischen Vorschau 9.3 wurde die Grundlage für die native Automatisierung in Elastic geschaffen. Version 9.4 bringt es in die allgemeine Verfügbarkeit mit Produktionsstabilität und deutlich erweiterten Funktionen. Das Fallmanagement erhält 25 dedizierte Automatisierungsschritte, die den gesamten Lebenszyklus abdecken. Die Einbindung des Menschen in den Workflow wird zu einem erstklassigen Workflow-Element. Die Erstellung von Inhalten in natürlicher Sprache wird in die Tech Preview-Phase überführt. Die Plattform erhält mehr Ablaufsteuerungsprimitive (while, switch, Iterationssteuerung), Datentransformationsschritte für die Arbeit mit Sammlungen, eine tiefere KI-Integration mit Agent Builder und breitere ereignisgesteuerte Auslöser. Produktionsreife Automatisierung für Elastic.
Fallautomatisierung im großen Maßstab
Die größte Neuerung für Sicherheitsteams ist das Fallmanagement. In der Tech Preview umfasste die Arbeit mit Fällen vier allgemeine Schritte: Erstellen, Abrufen, Aktualisieren und Kommentieren. Alles, was darüber hinausging, erforderte direkte API-Aufrufe.
Nun gibt es 25 dedizierte cases.* Schritte, die den gesamten Lebenszyklus abdecken: erstellen, suchen, ähnliche finden, aktualisieren, schließen, zuweisen, Zuweisung aufheben, Warnungen hinzufügen, Observables hinzufügen, Kommentare hinzufügen, Tags hinzufügen, Schweregrad festlegen, Status festlegen und mehr. Jeder Schritt wird eingegeben, validiert und erscheint in der Autovervollständigung des YAML-Editors, was bedeutet, dass die Erstellung in natürlicher Sprache diese Schritte ebenfalls präzise generieren kann.
So sieht ein realistischer Triage-Workflow aus. Ein Alarm wird ausgelöst. Der Workflow prüft, ob für diese Warnung bereits ein Fall existiert. Andernfalls wird ein solcher Fall erstellt, die Warnung und die Observables werden angehängt, der diensthabende Analyst wird zugewiesen und die Schwere der Ereignisse wird anhand der Risikobewertung weitergeleitet:
Der folgende Code zeigt ein Beispiel für einen mit YAML beschriebenen Workflow:
name: Triage Workflow
enabled: true
triggers:
- type: alert
steps:
- name: check_existing
type: cases.getCasesByAlertId
with:
alert_id: "{{ event.alerts[0]._id }}"
- name: route
type: if
condition: "steps.check_existing.output : ''"
steps:
- name: update_existing
type: cases.addComment
with:
case_id: "{{ steps.check_existing.output[0].id }}"
comment: |
Correlated alert: {{ event.rule.name }}
Source: {{ event.alerts[0].source.ip | default: "unknown" }}
Risk score: {{ event.alerts[0].kibana.alert.risk_score }}
else:
- name: create_case
type: cases.createCase
with:
owner: securitySolution
title: "{{ event.rule.name }} - {{ event.alerts[0].host.name }}"
description: |
Auto-created from detection rule: {{ event.rule.name }}
Host: {{ event.alerts[0].host.name }}
Source IP: {{ event.alerts[0].source.ip | default: "N/A" }}
severity: high
tags:
- auto-triage
- "{{ event.rule.name }}"
- name: attach_evidence
type: cases.addAlerts
with:
case_id: "{{steps.create_case.output.case.id}}"
alerts:
- alertId: "{{ event.alerts[0]._id }}"
index: "{{ event.alerts[0]._index }}"
- name: add_observables
type: cases.addObservables
with:
case_id: "{{steps.create_case.output.case.id}}"
observables:
- typeKey: observable-type-ipv4
value: "{{ event.alerts[0].source.ip }}"
- typeKey: observable-type-file-hash
value: "{{ event.alerts[0].file.hash.sha256 }}"
on-failure:
continue: trueDer Workflow übernimmt automatisch die Deduplizierung, das Anhängen von Nachweisen, die beobachtbare Anreicherung, den reibungslosen Umgang mit fehlenden Feldern und die Analystenzuweisung. Der Analyst öffnet Kibana und sieht einen Fall, in dem bereits der gesamte Kontext vorhanden ist.
Die 25 neuen cases.* Schritte umfassen Erstellen, Suchen, Ähnliche suchen, Aktualisieren, Schließen, Löschen, Zuweisen, Aufheben der Zuweisung, Hinzufügen/Entfernen von Warnungen, Hinzufügen/Entfernen von Observables, Hinzufügen/Aktualisieren/Löschen von Kommentaren, Hinzufügen/Entfernen von Tags, Festlegen des Schweregrades, Festlegen des Status, Abrufen nach ID, Abrufen nach Warnungs-ID und mehr für benutzerdefinierte Felder, Benutzeraktionen und Metriken. Jeder Schritt wird protokolliert und validiert. Bei der Erstellung von Dokumenten in natürlicher Sprache kann die KI diese präzise generieren, da sie Teil des Schemas sind.
Mit zunehmender Reife der Workflows werden Sie mehr domänenspezifische Schritte für die Verwaltung von Erkennungsregeln, Reaktionen auf Endpunkte und Bedrohungsanalyseoperationen sehen.
Menschliche Kontrollpunkte in automatisierten Arbeitsabläufen
Die Fallautomatisierung übernimmt die mechanische Arbeit, aber nicht jede Entscheidung sollte vollständig automatisiert werden. Die KI kann eine Warnung klassifizieren und Kontextinformationen sammeln, aber der Analyst sollte entscheiden, ob eine Eskalation erforderlich ist. Die Frage ist, wie viel mechanische Arbeit geleistet wird, bevor diese Entscheidung getroffen wird.
waitForInput unterbricht einen Arbeitsablauf zur menschlichen Beurteilung. Der Workflow führt die Untersuchung durch, sammelt Beweise, klassifiziert die Warnung mithilfe von KI und beendet den Vorgang. Es präsentiert strukturierte Ergebnisse und wartet ab. Der Analyst prüft, genehmigt oder leitet den Vorgang weiter, fügt Anmerkungen hinzu, und anschließend wird der Workflow basierend auf seinen Eingaben fortgesetzt.
Wie die folgende Abbildung zeigt, übernimmt die Automatisierung die Untersuchung, die Entscheidung trifft jedoch der Analyst, bevor die Automatisierung sie ausführt.
Klassifiziert eingehende Warnmeldungen mithilfe von KI, pausiert zur Überprüfung und Genehmigung durch Analysten und eskaliert nur genehmigte Fälle, indem ein Vorfall mit hoher Priorität unter Einbeziehung des Kontextes sowohl aus dem Modell als auch aus dem Analysten erstellt wird.
name: HITL Example
enabled: true
triggers:
- type: alert
steps:
- name: classify
type: ai.classify
connector-id: Anthropic-Claude-Sonnet-4-6
with:
includeRationale: true
input: ${{ event.alerts[0] }}
categories:
- true_positive
- false_positive
- needs_investigation
- name: approval_gate
type: waitForInput
with:
message: |
Alert: {{ event.rule.name }}
Classification: {{ steps.classify.output.category }}
Rationale: {{ steps.classify.output.rationale }}
Review the classification and approve to escalate.
schema:
type: object
properties:
approved:
type: boolean
title: Approve escalation
notes:
type: string
title: Analyst notes
required:
- approved
- name: escalate
type: if
condition: "steps.approval_gate.output.approved : true"
steps:
- name: create_escalated_case
type: cases.createCase
with:
owner: securitySolution
title: "[Escalated] {{ event.rule.name }}"
description: |
Escalated by analyst after AI classification.
Classification: {{ steps.classify.output.category }}
Notes: {{ steps.approval_gate.output.notes }}
severity: high
tags:
- escalated
- analyst-reviewedHeute funktioniert waitForInput über die Kibana-Ausführungsansicht und die REST-API. Slack, Teams und E-Mail-Zustellungskanäle werden eingeführt, damit Analysten Dokumente prüfen und genehmigen können, ohne den Kontext wechseln zu müssen. Dies ist besonders wichtig für Workflows, die in Agent Builder als Werkzeuge definiert sind, da agentengesteuerte Untersuchungen von menschlichen Kontrollpunkten profitieren, bevor Maßnahmen ergriffen werden.
Workflows aus natürlicher Sprache erstellen
Nachdem die Automatisierungsmuster eingerichtet sind, besteht die nächste Herausforderung darin, sie zugänglich zu machen. Wir haben uns für YAML als Workflow-Sprache entschieden, weil sie deklarativ, überprüfbar und portabel ist. Es handelte sich aber auch um eine strategische Entscheidung: YAML ist strukturierter Text, und große Sprachmodelle sind sehr gut darin, strukturierten Text zu generieren. Ein gut strukturiertes Workflow-Schema eignet sich ideal für die KI-gestützte Dokumentenerstellung. In 9.4 geht diese Wette auf. Die Erstellung von Texten in natürlicher Sprache ist in der Tech Preview verfügbar.
Beschreiben Sie im Workflow-Editor, was passieren soll: „Wenn eine Malware-Warnung ausgelöst wird, überprüfen Sie den Dateihash mit VirusTotal, erstellen Sie einen Fall mit hoher Priorität, fügen Sie die Warnung und die Observables hinzu und benachrichtigen Sie den SOC-Kanal.“ Der KI-Assistent generiert das YAML. Sie prüfen, verfeinern und veröffentlichen.
Das YAML ist vollständig einsehbar und editierbar. Wenn Sie wissen, was passieren soll, aber kein YAML-Experte sind, hilft Ihnen dies dabei, von der Absicht zu einem funktionierenden Workflow zu gelangen. Wenn Sie ein YAML-Experte sind, können Sie in natürlicher Sprache beginnen und diese dann im Editor verfeinern.
Das Autorenerlebnis wird sich ständig weiterentwickeln. Die visuelle Bearbeitung ist ein ergänzender Modus. Erstellung von Inhalten, die sich auf Slack und andere Tools erstrecken, die Ihr Team verwendet. Ziel ist es, die Sicherheitsteams an ihren jeweiligen Einsatzorten zu erreichen.
Zusammensetzbare Workflows
Mit dem Wachstum Ihrer Automatisierungsbibliothek wird Organisation unerlässlich. Die Automatisierung von Sicherheitsprozessen wird schnell komplex. Man beginnt mit einem einzigen Triage-Workflow und stellt dann fest, dass unterschiedliche Alarmtypen unterschiedliche Untersuchungsschritte erfordern. Man fügt Bedingungen hinzu, dann noch mehr Bedingungen, und plötzlich besteht der Workflow aus Hunderten von Zeilen mit verschachtelter Logik, die schwer nachzuvollziehen und noch schwerer zu ändern ist.
workflow.execute Ermöglicht das Erstellen wiederverwendbarer Arbeitsabläufe mit typisierten Ein- und Ausgaben. Anstatt Ihre gesamte Ermittlungslogik an einem Ort zu bündeln, erstellen Sie fokussierte Arbeitsabläufe für spezifische Szenarien und setzen diese miteinander zusammen. Aktualisieren Sie Ihren Workflow zur Malware-Untersuchung einmal, und jeder Workflow, der ihn aufruft, profitiert davon. Die Logik bleibt übersichtlich, Änderungen bleiben begrenzt und Ihre Automatisierung skaliert, ohne dabei instabil zu werden.
So sieht das in der Praxis aus. Klassifizieren Sie die Warnung und leiten Sie sie dann je nach Bedrohungsart an den entsprechenden Workflow weiter:
steps:
- name: dispatch
type: switch
expression: "{{ steps.classify.output.category }}"
cases:
- match: malware
steps:
- name: run_malware
type: workflow.execute
with:
workflow-id: ${{ consts.malware_workflow_id }}
inputs:
alert: ${{ event.alerts[0] }}
- match: phishing
steps:
- name: run_phishing
type: workflow.execute
with:
workflow-id: ${{ consts.phishing_workflow_id }}
inputs:
alert: ${{ event.alerts[0] }}
default:
- name: run_generic
type: workflow.execute
with:
workflow-id: ${{ consts.generic_triage_id }}
inputs:
alert: ${{ event.alerts[0] }}Jeder Workflow ist unabhängig testbar. Die meisten Teams beginnen mit einem einzigen Arbeitsablauf und extrahieren dann Unterarbeitsabläufe, sobald sich Muster abzeichnen. Komposition ist etwas, in das man hineinwächst.
Die Vorlagenbibliothek wird schließlich in das Produkt integriert, sodass Sie vorgefertigte Workflows direkt in Kibana entdecken und installieren können.
Wo Analysten bereits arbeiten
Arbeitsabläufe sind am nützlichsten, wenn sie dort verfügbar sind, wo Entscheidungen getroffen werden. Die Grundbausteine und Muster sind vorhanden, aber Automatisierung bringt nur dann einen Mehrwert, wenn Analysten ihn erreichen können, ohne die Tools wechseln zu müssen. Wir investieren in die Zugänglichkeit von Workflows im gesamten Arbeitsablauf von Sicherheitsanalysten, angefangen bei der Warnmeldungstabelle und der Angriffserkennung. Analysten können Warnmeldungen oder ganze Angriffe direkt an einen Workflow senden und so die von ihnen erstellte Untersuchungslogik auslösen, ohne ihren aktuellen Kontext verlassen zu müssen. Diese Integration wird kontinuierlich ausgebaut, sodass die Workflow-Automatisierung zu einem nahtlosen Bestandteil der täglichen Arbeit des Analysten wird und nicht zu einem separaten Ziel.
Mit der Option „Workflow ausführen“ in der Benachrichtigungstabelle können Sie mit der rechten Maustaste auf eine Benachrichtigung (oder mehrere Benachrichtigungen) klicken und direkt einen Workflow auslösen. Der Alarmkontext wird automatisch übergeben.
Dies ist der Anfang. Workflows werden sich weiterhin auf immer mehr Bereiche der Sicherheitsprozesse ausdehnen und die Automatisierung dort zugänglich machen, wo Analysten sie benötigen.
Mehr Kontrolle, mehr Flexibilität
Über die wichtigsten Funktionen hinaus ist die Workflow-Sprache selbst leistungsfähiger geworden. Neue Ablaufsteuerungsprimitive bieten Ihnen sauberere Möglichkeiten zur Handhabung komplexer Logik. while -Schleifen ermöglichen es Ihnen, Bedingungen abzufragen oder auf externe Zustandsänderungen zu warten. switch ermöglicht die Verzweigung in mehrere Richtungen, sodass Sie Benachrichtigungen nach Kategorie weiterleiten können, ohne verschachtelte Bedingungen zu verwenden. loop.break und loop.continue bieten Ihnen eine Standard-Iterationskontrolle.
Schrittweise Datentransformationsschritte übernehmen Filter-, Such-, Aggregations- und JSON-Operationen an Sammlungen, sodass Sie Warnlisten, IOC-Lookups und Anreicherungsantworten ohne benutzerdefinierte Skripte verarbeiten können.
Die KI-Schritte (ai.prompt, ai.classify, ai.summarize, ai.agent) sind stabiler und unterstützen nun strukturierte Ausgaben, wodurch die Verwendung von KI-generierten Klassifizierungen und Zusammenfassungen in der nachgelagerten Workflow-Logik erleichtert wird.
Auch die LiquidJS-Templating-Funktionen wurden erweitert. Sie können nun Variablen festlegen und während des gesamten Arbeitsablaufs darauf zugreifen, wodurch es einfacher wird, berechnete Werte über mehrere Schritte hinweg zu referenzieren.
Zuverlässigkeits- und Produktionskontrollen
Das alles ist nur dann nützlich, wenn es zuverlässig ist. Jeder Schritt unterstützt die on-failure -Konfiguration: Wiederholungsversuche bei vorübergehenden Fehlern, Fortfahren, wenn ein Schritt nicht kritisch ist, und Abbruch, wenn nachfolgende Schritte vom Ergebnis abhängen. Detaillierte Fehlermeldungen sind unter steps.<step-id>.error verfügbar, um bei der Umgehung von Fehlern zu helfen.
Parallelitätskontrollen verhindern, dass Alarmwellen Hunderte von parallelen Ausführungen auslösen. Schleifenschutzmechanismen verhindern eine unkontrollierte Ausführung. Die Begrenzung der Kompositionstiefe verhindert eine unendliche Rekursion.
Elastic 9.4 führt ereignisgesteuerte Trigger ein, beginnend mit workflows.failed. Wenn die Ausführung eines Workflows fehlschlägt, kann dies einen separaten Handler-Workflow auslösen. Erstellen Sie einen Benachrichtigungs-Workflow, der Ihr Team alarmiert, wenn die Automatisierung ausfällt. Weitere Auslösertypen werden folgen: Fallstatusänderungen, Alarmstatusübergänge und Aktualisierungen von Erkennungsregeln, wodurch Workflows reaktiv auf die Geschehnisse in Ihrer Sicherheitsumgebung reagieren.
Jede Ausführung wird im Ausführungsverlauf mit schrittweisen Ergebnissen protokolliert, einschließlich der Analystenentscheidungen ab Schritt waitForInput . Dies ist Ihr Debugging-Tool und Ihr Prüfprotokoll.
Workflows sind in Version 9.4 mit einer Enterprise-Lizenz standardmäßig aktiviert. Die detaillierte RBAC-Steuerung legt fest, wer Workflows erstellt, bearbeitet, ausführt und anzeigt. Jeder Managementvorgang wird in das Sicherheitsauditprotokoll geschrieben. Der Import-/Export-Prozess verschiebt Workflows zwischen Umgebungen, wobei die Konnektorreferenzen erhalten bleiben.
Lizenzierung und Preisgestaltung
Workflows ist mit einer Enterprise-Lizenz für Elastic Cloud Hosted und selbstverwaltete Bereitstellungen sowie mit der Complete-Stufe für Elastic Cloud Serverless für Sicherheitsprojekte verfügbar.
Version 9.4 führt ein einheitliches, auf der Ausführung basierendes Preismodell für alle Bereitstellungstypen ein.
Bei Serverless, Elastic Cloud Hosted und Self-Managed basiert die Preisgestaltung auf der Ausführung von Workflows, wobei bei größeren Datenmengen Mengenrabatte gewährt werden. Jeder Monat beinhaltet eine Basiszuweisung von Workflow-Ausführungen, die nicht in Rechnung gestellt werden. Die Nutzung über dieses Kontingent hinaus wird pro Ausführung abgerechnet, wobei volumenabhängige Rabatte bei steigender Nutzung gewährt werden.
Elastic Cloud Serverless beginnt am 1 2026 mit der Anwendung dieses Modells. Für die Nutzung über die monatlich nicht abgerechneten Ausführungen hinaus wird pro Ausführung eine Gebühr erhoben, wobei bei höheren Volumina Rabatte gewährt werden. Die vollständigen Preisdetails finden Sie hier.
Für Elastic Cloud Hosted und Self-Managed Deployments gilt das gleiche Preismodell, allerdings befindet sich das Unternehmen derzeit in einer Aktionsphase, in der noch keine Ausführungsgebühren anfallen. Dies ermöglicht es Teams, Workflows zu erstellen und auszuführen, Nutzungsmuster zu etablieren und sich auf den Übergang zur ausführungsbasierten Abrechnung in einer zukünftigen Version vorzubereiten.
Beginnen Sie jetzt mit dem Bau. Die heute von Ihnen erstellten Workflows werden auch nach der Umstellung auf das einheitliche Preismodell weiterhin funktionieren.
Einrichten der DGA-Erkennung
Workflows sind in Version 9.4 standardmäßig aktiviert. Öffnen Sie Kibana, navigieren Sie zu Workflows und beginnen Sie mit der Erstellung.
Falls Sie Workflows noch nicht kennen, erklärt Ihnen der Tech Preview-Beitrag Schritt für Schritt, wie Sie Ihren ersten Triage-Workflow erstellen. Der Chrysalis APT-Workflow zeigt die Agent Builder-Integration in der Praxis. Die Dokumentation enthält die vollständige Schritttypreferenz. Die Elastic Workflow Library enthält sofort einsatzbereite Vorlagen.
Beginnen Sie mit dem Workflow, der Ihrem Team diese Woche die meiste Zeit sparen würde. Wenn man es beschreiben kann, kann man es auch bauen.
Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.