Elastic Workflows est généralement disponible dans la version 9.4. Il s'agit de la couche d'automatisation intégrée directement à Elastic, qui s'exécute là où se trouvent vos données dans les domaines de la sécurité, de l'observabilité et de la recherche. Bien que cet article se concentre sur une analyse approfondie de la sécurité, les mêmes capacités de flux de travail s'appliquent à toutes les solutions, sans plateforme distincte à déployer et sans données à déplacer. Lorsqu'une alerte se déclenche ou qu'une planification se met en place, un flux de travail s'exécute : interrogation d'Elasticsearch, enrichissement avec des informations sur les menaces, création de cas, appel d'API externes et notification à votre équipe. Définissez-le en YAML ou décrivez-le en langage naturel et laissez l'IA générer le flux de travail.
L'aperçu technique 9.3 a jeté les bases de l'automatisation native dans Elastic. La version 9.4 permet une disponibilité générale avec une stabilité de la production et des capacités considérablement accrues. La gestion des dossiers se fait à l'adresse 25 par des étapes d'automatisation dédiées couvrant l'ensemble du cycle de vie. L'homme dans la boucle devient une primitive de flux de travail de première classe. La rédaction en langage naturel passe à l'étape de l'aperçu technique. La plateforme bénéficie d'un plus grand nombre de primitives de contrôle de flux (while, switch, contrôle d'itération), d'étapes de transformation des données pour travailler avec des collections, d'une intégration plus poussée de l'IA avec Agent Builder et d'un plus grand nombre de déclencheurs événementiels. Automatisation prête à la production dans Elastic.
L'automatisation des cas à grande échelle
La gestion des dossiers est le plus grand ajout pour les équipes de sécurité. Dans l'aperçu technique, le travail sur les dossiers comportait quatre étapes génériques : la création, l'extraction, la mise à jour et le commentaire. Tout ce qui va au-delà nécessite des appels à l'API brute.
Il existe désormais 25 étapes cases.* dédiées couvrant l'ensemble du cycle de vie : créer, trouver, trouver similaire, mettre à jour, fermer, assigner, désassigner, ajouter des alertes, ajouter des observables, ajouter des commentaires, ajouter des balises, définir la gravité, définir le statut, et plus encore. Chaque étape est saisie, validée et apparaît dans l'autocomplétion de l'éditeur YAML, ce qui signifie que la rédaction en langage naturel peut également les générer avec précision.
Voici à quoi ressemble un flux de travail de triage réaliste. Une alerte se déclenche. Le workflow vérifie si un cas existe déjà pour cette alerte. Si ce n'est pas le cas, il en crée une, joint l'alerte et les éléments observables, affecte l'analyste de garde et achemine la gravité en fonction du score de risque :
Le code ci-dessous montre un exemple de flux de travail décrit à l'aide de YAML :
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: trueLe flux de travail gère automatiquement la déduplication, l'attachement des preuves, l'enrichissement des observables, le traitement gracieux des champs manquants et l'affectation des analystes. L'analyste ouvre Kibana et voit un cas avec tout le contexte déjà présent.
cases.* Les nouvelles étapes du site 25 comprennent la création, la recherche, la recherche similaire, la mise à jour, la fermeture, la suppression, l'affectation, la désaffectation, l'ajout/la suppression d'alertes, l'ajout/la suppression d'observables, l'ajout/mise à jour/la suppression de commentaires, l'ajout/la suppression de balises, la définition de la gravité, la définition de l'état, l'obtention par ID, l'obtention par ID d'alerte, et plus encore pour les champs personnalisés, les actions d'utilisateur et les métriques. Chaque étape est saisie et validée. Si vous utilisez la rédaction en langage naturel, l'IA peut les générer avec précision parce qu'ils font partie du schéma.
Au fur et à mesure que les flux de travail évolueront, vous verrez apparaître des étapes spécifiques à certains domaines pour la gestion des règles de détection, les actions de réponse aux points d'extrémité et les opérations de renseignement sur les menaces.
Points de contrôle humains dans les flux de travail automatisés
L'automatisation des cas prend en charge le travail mécanique, mais toutes les décisions ne doivent pas être entièrement automatisées. L'IA peut classer une alerte et rassembler le contexte, mais c'est à l'analyste de décider s'il y a lieu d'escalader. La question est de savoir combien de travaux mécaniques sont effectués avant qu'ils ne prennent cette décision.
waitForInput met en pause un flux de travail pour qu'il soit jugé par une personne. Le flux de travail mène l'enquête, rassemble les preuves, classifie l'alerte avec l'IA et s'arrête. Il présente des résultats structurés et attend. L'analyste révise, approuve ou redirige, et ajoute des notes, puis le flux de travail reprend en fonction de ses données.
Comme le montre l'image suivante, l'automate gère l'enquête, mais l'analyste prend la décision avant que l'automate ne l'exécute.
Classifie les alertes entrantes à l'aide de l'IA, fait une pause pour l'examen et l'approbation de l'analyste, et ne fait remonter que les cas approuvés en créant un incident de haute gravité avec un contexte provenant à la fois du modèle et de l'analyste.
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-reviewedAujourd'hui, waitForInput fonctionne via la vue d'exécution Kibana et l'API REST. Les canaux de livraison Slack, Teams et les courriels font leur apparition pour que les analystes puissent examiner et approuver sans changer de contexte. Ceci est particulièrement important pour les flux de travail définis comme des outils dans Agent Builder, où les enquêtes menées par des agents bénéficient de points de contrôle humains avant de prendre des mesures.
Construire des flux de travail à partir du langage naturel
Une fois les modèles d'automatisation mis en place, le prochain défi consiste à les rendre accessibles. Nous avons choisi YAML comme langage de flux de travail parce qu'il est déclaratif, révisable et portable. Mais il s'agissait également d'un choix stratégique : YAML est un texte structuré, et les grands modèles de langage sont très efficaces pour générer du texte structuré. Un schéma de flux de travail bien typé est une cible idéale pour la création assistée par ordinateur. En 9.4, ce pari s'avère payant. La rédaction en langage naturel est disponible dans Tech Preview.
Dans l'éditeur de flux de travail, décrivez ce qui doit se passer : "Lorsqu'une alerte de logiciel malveillant se déclenche, vérifiez le hachage du fichier dans VirusTotal, créez un cas de haute gravité, joignez l'alerte et les observables, et informez le canal SOC." L'assistant AI génère le YAML. Vous révisez, affinez et déployez.
Le YAML est entièrement inspectable et modifiable. Si vous savez ce qui doit se passer, mais que vous n'êtes pas un expert en YAML, cela vous permet de passer de l'intention à un flux de travail fonctionnel. Si vous êtes un expert en YAML, vous pouvez commencer en langage naturel et affiner dans l'éditeur.
L'expérience de la rédaction continuera d'évoluer. L'édition visuelle est un mode complémentaire. Une rédaction qui s'étend à Slack et aux autres outils utilisés par votre équipe. L'objectif est de rencontrer les équipes de sécurité là où elles travaillent.
Flux de travail composables
Au fur et à mesure que votre bibliothèque automatisée s'agrandit, l'organisation devient cruciale. L'automatisation de la sécurité devient rapidement complexe. Vous commencez par un flux de travail de triage unique, puis vous vous rendez compte que les différents types d'alertes nécessitent des étapes d'investigation différentes. Vous ajoutez des conditionnelles, puis d'autres conditionnelles, et soudain votre flux de travail se compose de centaines de lignes avec une logique imbriquée qui est difficile à suivre et à modifier.
workflow.execute vous permet de construire des flux de travail réutilisables avec des entrées et des sorties typées. Au lieu d'intégrer toute votre logique d'investigation en un seul endroit, vous créez des flux de travail ciblés pour des scénarios spécifiques et vous les composez ensemble. Mettez à jour votre flux de travail de recherche de logiciels malveillants une fois, et tous les flux de travail qui y font appel en bénéficieront. La logique reste organisée, les changements restent limités et votre automatisation évolue sans se fragiliser.
Voici ce que cela donne en pratique. Classez l'alerte, puis acheminez-la vers le flux de travail spécialisé en fonction du type de menace :
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] }}Chaque flux de travail peut être testé indépendamment. La plupart des équipes commencent par un flux de travail unique et extraient des sous-flux de travail au fur et à mesure de l'émergence de modèles. La composition est quelque chose que l'on acquiert en grandissant.
La bibliothèque de modèles sera finalement intégrée au produit afin que vous puissiez découvrir et installer des flux de travail préconstruits directement dans Kibana.
Là où les analystes travaillent déjà
Les flux de travail sont d'autant plus utiles qu'ils sont disponibles là où les décisions sont prises. Les primitives et les modèles sont en place, mais l'automatisation n'apporte de la valeur que si les analystes peuvent l'atteindre sans changer d'outil. Nous investissons pour rendre les flux de travail accessibles à tous les analystes de la sécurité, en commençant par le tableau des alertes et la découverte des attaques. Les analystes peuvent envoyer des alertes ou des attaques entières directement à un flux de travail, déclenchant la logique d'investigation qu'ils ont élaborée sans quitter leur contexte actuel. Cette intégration continuera à s'étendre afin que l'automatisation des flux de travail devienne une partie intégrante du travail quotidien de l'analyste, et non une destination distincte.
"Exécuter un flux de travail" dans le tableau des alertes vous permet de cliquer avec le bouton droit de la souris sur une alerte (ou d'en sélectionner plusieurs) et de déclencher directement un flux de travail. Le contexte d'alerte passe automatiquement.
C'est le début. Les flux de travail continueront à s'étendre à d'autres parties de l'expérience de la sécurité, rendant l'automatisation accessible là où les analystes en ont besoin.
Plus de contrôle, plus de flexibilité
Au-delà des fonctionnalités majeures, le langage Workflow lui-même est devenu plus performant. De nouvelles primitives de contrôle de flux vous permettent de gérer plus proprement une logique complexe. while Les boucles vous permettent d'interroger des conditions ou d'attendre des changements d'état externes. switch offre une ramification multidirectionnelle qui vous permet d'acheminer les alertes par catégorie sans conditionnalité imbriquée. loop.break et loop.continue vous offrent un contrôle standard de l'itération.
Les étapes de transformation des données gèrent le filtrage, la recherche, l'agrégation et les opérations JSON sur les collections, ce qui vous permet de traiter les listes d'alertes, les consultations IOC et les réponses d'enrichissement sans avoir recours à des scripts personnalisés.
Les étapes de l'IA (ai.prompt, ai.classify, ai.summarize, ai.agent) sont plus stables et prennent désormais en charge les sorties structurées, ce qui facilite l'utilisation des classifications et des résumés générés par l'IA dans la logique du flux de travail en aval.
Le modèle LiquidJS a également été développé. Vous pouvez désormais définir des variables et y accéder tout au long du flux de travail, ce qui facilite la référence à des valeurs calculées au cours de plusieurs étapes.
Fiabilité et contrôles de production
Tout cela n'est utile que si c'est fiable. Chaque étape peut être configurée à l'adresse on-failure: réessayer en cas d'échec transitoire, continuer lorsqu'une étape n'est pas critique et abandonner lorsque les étapes en aval dépendent du résultat. Les détails des erreurs sont disponibles à l'adresse steps.<step-id>.error pour aider à contourner les défaillances.
Les contrôles de simultanéité empêchent les tempêtes d'alerte d'engendrer des centaines d'exécutions parallèles. Les garde-corps en boucle empêchent l'exécution en cas d'emballement. Les limites de profondeur de composition empêchent la récursion infinie.
Elastic 9.4 introduit des déclencheurs événementiels, à partir de workflows.failed. Lorsqu'un flux de travail échoue, il peut déclencher un flux de traitement distinct. Créez un flux de notification qui alerte votre équipe lorsque l'automatisation tombe en panne. D'autres types de déclencheurs sont à venir : changements d'état des cas, transitions d'état des alertes et mises à jour des règles de détection, rendant les flux de travail réactifs à ce qui se passe dans votre environnement de sécurité.
Chaque exécution est enregistrée dans l'historique d'exécution avec les résultats étape par étape, y compris les décisions des analystes à partir des étapes waitForInput. Il s'agit de votre outil de débogage et de votre piste d'audit.
Les flux de travail sont activés par défaut dans la version 9.4 avec une licence Entreprise. Le RBAC granulaire permet de contrôler qui crée, édite, exécute et visualise les flux de travail. Chaque opération de gestion écrit dans le journal d'audit de sécurité. L'importation/exportation déplace les flux de travail entre les environnements en conservant les références des connecteurs.
Licences et tarification
Workflows est disponible avec une licence Enterprise sur Elastic Cloud Hosted et les déploiements autogérés, et avec le niveau Complete sur Elastic Cloud Serverless pour les projets de sécurité.
La version 9.4 introduit un modèle de tarification unifié basé sur l'exécution pour tous les types de déploiement.
Qu'il s'agisse de Serverless, d'Elastic Cloud Hosted ou d'autogestion, la tarification est basée sur les exécutions de flux de travail, avec des remises basées sur le volume à l'échelle. Chaque mois comprend une allocation de base d'exécutions de flux de travail qui ne sont pas facturées. L'utilisation au-delà de cette allocation est facturée par exécution, avec des réductions basées sur le volume au fur et à mesure de l'augmentation de l'utilisation.
Elastic Cloud Serverless commence à appliquer ce modèle à partir de mai 1, 2026. L'utilisation au-delà des exécutions mensuelles non facturées est facturée par exécution, avec des réductions pour les volumes plus importants. Voir les détails de la tarification.
Les déploiements d'Elastic Cloud Hosted et autogérés suivent le même modèle de tarification, mais sont actuellement en période de promotion et les frais d'exécution ne sont pas encore appliqués. Cela permet aux équipes de créer et d'exécuter des flux de travail, d'établir des modèles d'utilisation et de se préparer à la transition vers une facturation basée sur l'exécution dans une version future.
Commencez à construire dès maintenant. Les flux de travail que vous créez aujourd'hui continueront à fonctionner lorsque la tarification passera au modèle unifié.
Premiers pas
Les flux de travail sont activés par défaut dans la version 9.4. Ouvrez Kibana, naviguez jusqu'à Workflows et commencez à construire.
Si vous êtes novice en matière de flux de travail, l'article Tech Preview vous explique comment créer votre premier flux de travail de triage. Le flux de travail de Chrysalis APT montre l'intégration d'Agent Builder en action. La documentation contient la référence complète du type d'étape. La bibliothèque Elastic Workflow contient des modèles prêts à l'emploi.
Commencez par le flux de travail qui permettrait à votre équipe de gagner le plus de temps cette semaine. Si vous pouvez le décrire, vous pouvez le construire.
La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.