Comment le premier Elastic Workflow de Visa a réduit le temps de triage des alertes de 10 à 20 minutes à quelques secondes grâce à une étape d’IA supervisée par l’humain

Dans le cadre d’une modernisation plus large de ses opérations de sécurité, passant d’un SIEM hérité à Elastic, l’équipe d’ingénierie cybersécurité de Visa a créé son premier workflow d’IA autonome dans le SOC : un pipeline en quatre étapes utilisant une étape d’IA contrainte avec intervention humaine contrôlée, pour produire des dossiers prêts pour la réponse aux incidents. Pour une détection critique sur mainframe qui nécessitait auparavant une deuxième requête manuelle, le temps de triage est passé de 10 à 20 minutes à quelques secondes, et ce même modèle contrôlé et vérifiable est désormais réutilisable pour d’autres détections.

Visa migre d’un système SIEM traditionnel vers Elastic, et au cours de cette migration, l’équipe d’ingénierie en cybersécurité a créé son premier pipeline Elastic workflows à titre de étude de faisabilité. La détection choisie, une détection d’identité sur mainframe à enjeux élevés, nécessitait auparavant que les analystes passent de l’alerte à une recherche complémentaire pour identifier l’utilisateur responsable, avec des résultats qui variaient considérablement selon l’expérience de l’analyste avec les logs des mainframes. L’équipe a enchaîné deux requêtes en langage de requête Elasticsearch (ES|QL), ajouté une étape IA contrainte qui produit un résumé structuré pour l’équipe IR, et utilisé un webhook pour transmettre le cas directement dans leur système de gestion des tickets IR. Lorsque l’alerte se déclenche, le triage est maintenant réalisé en quelques secondes au lieu de 10 à 20 minutes, et le même modèle en quatre étapes est maintenant prêt à être appliqué à d’autres détections.

Visa sécurise l’un des plus grands environnements de paiement au monde. Dans le cadre d’une modernisation plus large, passant d’un SIEM hérité à Elastic, l’équipe d’ingénierie en cybersécurité s’est donné pour mission de mettre en place ce dont Visa ne disposait pas encore à grande échelle : une méthode contrôlée et sécurisée pour utiliser l’IA au sein des opérations de sécurité. La barre est spécifique. Chaque étape de l’IA devait être auditable, avoir une portée limitée et s’appuyer de manière vérifiable sur des données contrôlées par l’équipe. Cette barre a été testée pour la première fois sur une détection d’identité mainframe à enjeux élevés, où chaque incident obligeait l’équipe d’intervention à consacrer entre 10 et 20 minutes à la collecte manuelle d’informations contextuelles avant même de pouvoir démarrer l’enquête.

Lorsque cette détection se déclenchait dans l’ancien SIEM, l’équipe de réponse aux incidents devait se connecter, effectuer une seconde recherche et déterminer quel utilisateur était à l’origine de cette activité. La détection identifiait l’événement. Restait à l’analyste à identifier la personne.

Le raisonnement de l’équipe était simple : si chaque alerte nécessitant une intervention requiert une deuxième recherche avant que l’équipe d’intervention en cas d’incident puisse agir, le pipeline est incomplet. En intégrant cette deuxième requête en amont, directement dans le pipeline, l’équipe d'intervention en cas d’incident reçoit un dossier déjà enrichi, synthétisé et prêt à être transmis à l’équipe chargée du mainframe pour vérification.

Le projet global de Visa consistait à migrer la logique de détection d’un SIEM existant vers Elastic. Ce type de migration a tendance à être une conversion de règles effectuée à l’aveuglette. L’équipe a délibérément laissé la place aux ingénieurs pour essayer les nouvelles fonctionnalités de la plateforme parallèlement aux travaux de conversion.

Un ingénieur en cybersécurité de l’équipe a suivi la formation Elastic Workflows, a choisi une détection qu’il connaissait déjà bien et a travaillé avec son architecte de solutions Elastic pour créer la première version. L’équipe Elastic a généré des données de test représentatives à partir des échantillons fournis par l’ingénieur, a créé un workflow de démarrage à partir de zéro, et l’a livré sous forme de modèle pouvant être développé.

Les approches existantes ne pouvaient pas offrir une automatisation native qui résidait sur la même plateforme de sécurité que les données. Chez Visa, l’orchestration de type SOAR est assurée par une équipe d’automatisation distincte et exécutée sur une plateforme distincte de celle de la détection elle-même. Avec les workflows Elastic, l’exécution du pipeline se fait au même endroit : détection, enrichissement, validation et livraison, le tout de manière native, dans un seul fichier YAML que l’ingénieur peut lire et modifier sur un seul écran.

Le workflow constituait également le point de départ idéal pour une raison bien précise. Visa avait besoin d’un contrôle complet sur ce que l’IA recevait à chaque étape, sur ce qu’elle produisait et sur la façon dont chaque décision pouvait être vérifiée. Pour un environnement de services financiers réglementé, cette auditabilité est la condition préalable pour faire confiance à l’IA dans les opérations de sécurité. Les workflows ont fourni à l’équipe un modèle entièrement quantifiable et justifiable, chaque étape étant visible dans un seul fichier YAML, avant de s'étendre à d'autres fonctionnalités agentiques prévues dans la feuille de route d’Elastic.

Dans le workflow précédent, la séquence était de type « alerte, puis enquête ». La détection est déclenchée. L’équipe IR se connecte au SIEM hérité. La recherche de suivi est exécutée pour associer l’événement à un terminal et à un utilisateur. Les logs des grands systèmes ne sont pas un environnement tolérant pour ce type de travail.

Trois éléments ont rendu l’état antérieur coûteux :

• La seconde recherche ne pouvait pas être évitée. Seule une personne pouvait être affectée à un terminal à la fois, mais les valeurs des terminaux étaient réutilisées. Pour identifier l’utilisateur à l’origine d’un événement signalé, un analyste devait interroger la connexion antérieure la plus récente de ce terminal, sur cette partition du mainframe, à l’heure de l’événement.
• Les compétences des analystes étaient cruciales. Les analystes expérimentés qui connaissaient le langage de requête et les codes d’événements du mainframe pouvaient le faire rapidement. Les nouveaux analystes, ou les analystes moins familiers avec les logs des mainframes, avaient besoin de nettement plus de temps. Résultat, des disparités en termes de temps et de qualité.
• Les codes d’événements des grands systèmes sont complexes. Il n’existe pas de méthode unique pour associer un événement à un résultat. Les analystes devaient souvent interpréter des codes système dont la signification dépendait du contexte, ce qui ralentissait le travail et rendait le résultat plus difficile à standardiser.

Le temps et la qualité étaient tous deux consacrés à la deuxième recherche. La détection avait identifié l’événement ; l’analyste menait toujours l’enquête qui aurait dû faire partie de la sortie de la détection.

Le nouveau pipeline s’exécute en quatre étapes enchaînées à l’intérieur des workflows Elastic :

1. Détection (requête ES|QL principale) : Sur un temporisateur de cinq minutes avec une fenêtre de recherche de dix minutes, le workflow procède à l’exécution d’une requête ES|QL rapide et ciblée sur les logs du mainframe, à la recherche de l’activité d’identité ciblée. La détection est volontairement précise. L’équipe n’attend pas plus d’un ou deux résultats positifs par cycle, et, d’après les données historiques, l’alerte ne se déclenche que quelques fois par an.
2. Enrichissement (requête ES|QL secondaire) : Pour chaque événement renvoyé, le workflow lance une requête ES|QL de suivi qui récupère la valeur du terminal et la LPAR (partition mainframe) de l’événement principal, puis recherche la connexion antérieure la plus récente de ce terminal. Les terminaux étant réutilisés, mais un seul utilisateur étant assigné à la fois, la connexion antérieure la plus récente identifie l’auteur de la derrière l’activité. La vérification est rapide, car les requêtes qui ont permis d’obtenir ce résultat sont immédiatement à la disposition de l’ingénieur, qui peut ainsi les examiner.
3. Validation par IA : l’événement enrichi est transmis à une étape s’appuyant sur un grand modèle de langage (LLM). Le modèle reçoit une invite contrainte : l’hypothèse selon laquelle une seule personne peut utiliser un terminal à la fois, les détails de l’alerte principale et le résultat de la requête secondaire. Sa mission est de vérifier que les données corroborent la conclusion et de produire un résumé structuré incluant le nom et l’identifiant de l’utilisateur, ce que l’alerte initiale a détecté, et pourquoi cette personne est l’acteur identifié. Le modèle ne décide pas s’il faut transmettre l’alerte ; c’est l’équipe IR qui le fait.
4. Livraison (webhook) : Le résumé est transmis via webhook au système de billetterie IR. Au moment où le ticket est créé, l’ingénieur IR est déjà en train d’examiner un dossier, et non de le constituer.

Le choix architectural qui importe le plus ici est que l’ensemble du pipeline est en exécution nativement sur la même plateforme que les données de sécurité. Il n’y a pas de SOAR en arrière-plan, aucun système d’orchestration distinct à gérer et aucun lien entre la détection et le workflow.

Caractéristiques techniques principales

• Requête principale ES|QL avec un intervalle de cinq minutes et une période de rétrospective de dix minutes
• La requête secondaire ES|QL récupère le terminal et la LPAR de l’événement principal et identifie la connexion précédente la plus récente
• Cette méthode de détection a été choisie en raison du coût élevé en personnel d’analyse lié à l'étape manuelle de deuxième requête qu’elle nécessitait auparavant
• L’étape de validation assistée par LLM reçoit une invite contrainte et structurée, et non une analyse libre
• Fenêtre de contexte : seules les 5 à 15 minutes d’enregistrements pertinents sont transmises au modèle, réduisant ainsi le nombre de jetons envoyés et resserrant le contexte de travail du modèle
• Visa change de fournisseur et la plateforme est indépendante du modèle utilisé
• Le workflow est un fichier YAML unique rédigé et testé dans un seul écran Kibana, comme un éditeur de code
• Un webhook fournit le résumé structuré directement dans le système de gestion des tickets IR

Détection et enrichissement en chaîne d’ES|QL dans un seul workflow

C’est en considérant la détection et l’enrichissement comme un flux continu unique, plutôt que comme deux étapes distinctes impliquant l’intervention d’un analyste, que le reste du pipeline a pu prendre forme. Le modèle canalisé d’ES|QL permet à l’équipe d’exprimer le flux de manière déclarative : la requête principale identifie l’événement signalé, et la requête secondaire intègre le mapping terminal-utilisateur qui détermine qui est probablement l’auteur. Il n’y a pas de session sur la console des analystes entre les deux, et il n’y a pas de deuxième outil pour accéder au log. La structure du workflow correspond désormais à la structure de la question posée par l’analyste (qui est l’auteur ?) plutôt que de s’arrêter à est-ce qu’il s’est passé quelque chose ?.

Une étape d’IA contrainte avec une portée délibérément étroite

L’étape de l’IA effectue une tâche spécifique : confirmer que les données d’enrichissement corroborent la conclusion et produire un résumé structuré que l’équipe IR peut lire en quelques secondes. Elle ne génère pas de logique de détection. Elle ne décide pas s’il faut faire remonter l’information. L’hypothèse qui sous-tend l’analyse (une seule personne peut utiliser un terminal à la fois) est prise en compte, et la connexion précédente la plus récente est utilisée pour évaluer cette hypothèse.

C’est le but. Le choix de l’équipe n’a pas été de « laisser le modèle enquêter » mais de « laisser le modèle vérifier et résumer ce que les requêtes ont déjà renvoyé. » Chaque décision de l’IA dans le pipeline évalue des données que l’équipe peut consulter, selon des critères que l’équipe contrôle. C’est ce qui rend la validation vérifiable, et non pas opaque.

Fenêtrage contextuel à faible consommation de jetons

Le modèle ne reçoit jamais plus de données que nécessaire. Le pipeline filtre les enregistrements transmis pour ne conserver que ceux qui correspondent à la fenêtre temporelle de l’événement, les 5 à 15 dernières minutes, conformément aux paramètres de détection définis. Le résultat est une fenêtre de contexte plus petite, moins de jetons par décision, et un raisonnement plus fin, parce que le modèle n’essaie pas d’interpréter des enregistrements qui n’ont rien à voir avec la question.

Automatisation native au sein de la plateforme de sécurité

L’ensemble du pipeline se trouve dans Elastic, au plus proche des données. Il n’y a pas de plateforme d’orchestration séparée à gérer, pas d’intégration fragile à gérer pendant un incident, ni de deuxième équipe pour coordonner le workflow. Les workflows créés en YAML peuvent appeler d’autres systèmes via HTTP, de sorte que la portée de la plateforme s’étend sans quitter l’environnement natif. Pour Visa en particulier, cet aspect est important. Une équipe d’automatisation distincte gère actuellement une orchestration de type SOAR sur une plateforme différente de celle des données de sécurité. Cette équipe a déjà demandé un accès API à Elastic, et l’équipe d’ingénierie en cybersécurité est ouverte à l’utilisation des workflows pour absorber le travail de réponse qui se trouve actuellement sur l’autre outil. L’argument en faveur de la consolidation sur un seul espace d’automatisation natif n’est plus une théorie chez Visa.

Le résultat le plus visible est la vitesse, mais le résultat opérationnellement important est la cohérence. L’interprétation des logs du mainframe était auparavant l’une des étapes les plus aléatoires du triage chez Visa : un analyste expérimenté pouvait réaliser rapidement la deuxième requête ; un analyste plus novice, ou moins familier avec les codes d’événements du mainframe, avait besoin de beaucoup plus de temps et produisait des résultats plus variables.

En intégrant l’assemblage et la synthèse dans le pipeline, la partie du flux de travail qui dépendait de la maîtrise par les analystes des langages de requête existants et des codes d’événements mainframe ne relève plus de leur responsabilité. L’ingénieur IR lit un résumé structuré et décide, suivant son appréciation, s’il faut agir.

La détection elle-même se déclenche rarement, historiquement seulement quelques fois par an. C’est volontaire. L’équipe l’a voulu précisément parce qu’il s’agit d’une alerte à faible volume, mais à forts enjeux, où le coût par incident de l’étape manuelle de seconde requête valait clairement la peine d’être éliminée. Mais ce qu’il faut surtout retenir, c’est qu’il s’agit du premier workflow de production de ce type pour Visa, et le modèle en quatre étapes établi est maintenant prêt à être appliqué à d’autres détection.

Voici ce que voit désormais un ingénieur IR chez Visa lorsque cette alerte se déclenche : un ticket contenant l’événement d’origine, l’utilisateur identifié, nommé et identifié par son ID, la justification et le lien vers les données sous-jacentes. Le pipeline a effectué la deuxième requête, le LLM a vérifié et résumé, et le webhook a créé le ticket. La première action de l’ingénieur est le jugement, pas la construction de requête.

L’humain est toujours le décideur. Le pipeline effectue l’assemblage. L’IA effectue la vérification et la synthèse. L’ingénieur fait ce que seul l’ingénieur peut faire : juger, vérifier et faire remonter. Le travail qui est transféré en amont est celui qui était reproductible. Le travail qui incombe à l’ingénieur est celui qui nécessite du jugement.

Si ce projet « Workflows » est le premier de Visa, mais pas le dernier, c'est parce que ce modèle en quatre étapes est transposable. La détection spécifique est inhabituelle ; le schéma opérationnel qui l’entoure ne l’est pas. Partout où une détection nécessite une recherche de suivi connue et reproductible avant qu’un analyste puisse agir, les mêmes quatre étapes s’appliquent.

Les trois principes tirés de cette implémentation s’appliquent à toute détection dans laquelle la deuxième requête constitue le point de blocage. Automatisez les parties connues du guide d’exécution dans le pipeline lui-même, car si l’exécution se fait toujours de la même manière, il ne s’agit pas d’un travail d’analyste. Donnez à l’étape de l’IA une tâche suffisamment précise pour être vérifiable : une invite contrainte, une entrée structurée, un résumé que l’ingénieur peut vérifier par rapport aux données. Limitez le contexte, afin que le modèle ne reçoive que ce qui est pertinent au moment de l’événement plutôt que l’intégralité des données renvoyées par les requêtes. Le premier principe est le plus généralisable. Ce sont les deux autres qui permettent de justifier l’IA.

Le modèle en quatre étapes (détection, enrichissement, validation, livraison) est transposable. L’équipe a déjà identifié d’autres détections dans le cadre de la migration qui pourraient bénéficier de la même approche en chaîne, avec synthèse par IA et livrée via webhook. L’équipe évalue activement Attack Discovery, que Martin décrit comme la fonctionnalité d’Elastic qui a suscité leur intérêt. La séquence a été délibérée : le workflow a donné à Visa un modèle qui pouvait être totalement quantifié et vérifié avant de l’étendre à des capacités avec plus de logique de corrélation fonctionnant en interne, ce qui est la bonne voie pour un SOC de services financiers réglementé. L’équipe a créé en parallèle un agent d’IA pour la chasse aux menaces et étudie comment les workflows peuvent absorber le travail de réponse actuellement géré par un groupe d’automatisation séparé. Suivre le rythme de publication des nouvelles versions d’Elastic fait désormais aussi partie du travail.

Visa est l’un des plus grands réseaux de paiement au monde, et scaler de ses opérations de sécurité en témoigne. Votre organisation n’effectue peut-être pas aujourd’hui une migration à la scaler de Visa, mais les mêmes principes s’appliquent, que vous convertissiez votre première détection ou que vous reconstruisiez un SOC complet : si l’alerte nécessite une deuxième requête avant qu’une action puisse être entreprise, le pipeline est incomplet, et le modèle en quatre étapes fonctionne à chaque étape de son déploiement.

Découvrez comment Elastic Workflows permet de faire passer les enquêtes en amont de votre pipeline de détection.