Mise à l'échelle du tri des alertes de sécurité avec des agents spécialisés sur Databricks

Et si une faible gravité ne signifiait pas une faible priorité ?

Databricks ingère des pétaoctets de journaux de sécurité provenant de diverses sources, notamment des outils de sécurité des terminaux, des journaux d'activité cloud et des flux de renseignement sur les menaces, dans notre lakehouse de sécurité. Notre architecture de détection surveille en permanence ces données pour repérer toute activité malveillante. Chaque signal identifié arrive dans une table d'alertes centralisée, où il attend d'être examiné par un analyste Incident Response (IR).

Trouver une menace réelle parmi des milliers d'alertes de sécurité quotidiennes relève du classique problème de l'aiguille dans une botte de foin. La plupart des équipes gèrent cette charge en priorisant les alertes par gravité. Les équipes trient les alertes HIGH et MEDIUM, et traitent les LOW à mesure que du temps se libère.

Chez Databricks, notre équipe IR gère les alertes de sécurité sur les trois niveaux de priorité. Historiquement, l'équipe priorisait les alertes HIGH et MEDIUM en raison du volume et de la faible pertinence des alertes LOW. Toute équipe de sécurité à grande échelle est confrontée à ce même dilemme : augmenter les effectifs d'analystes, relever les seuils d'alerte et accepter des zones d'ombre, ou trouver un moyen d'automatiser le processus. Nous avons choisi cette dernière option, en exploitant des agents capables de raisonner et de prendre des décisions à grande échelle.

Le choix d'agents spécialisés

Pour vérifier si des agents pouvaient trier et remonter de manière fiable les alertes de sécurité, nous avons commencé par les alertes de faible gravité. Notre objectif était simple : identifier les alertes qui méritent une enquête plus approfondie.

Nous avons d'abord adopté une approche naïve, en insérant toutes les données d'alerte pertinentes dans un prompt unique et en laissant un modèle de fondation décider de ce qu'il fallait remonter. Cette approche a produit un taux d'escalade de 50 %. Envoyer la moitié de toutes les alertes aux analystes n'était pas du tri, c'était juste un autre type de bruit.

Le problème résidait dans le contexte. Un agent unique raisonnant sur chaque alerte n'a aucun moyen de distinguer ce qui est anormal pour chaque source. Tout ce qui est nécessaire pour trier une alerte avec précision — ses modèles de faux positifs, ses références comportementales et ses enrichissements pertinents — est propre à la source. Sans ce contexte, le modèle ne disposait que de connaissances générales en cybersécurité, ce qui était insuffisant pour un tri précis.

Architecture : une flotte d'agents

Nous avons reconstruit le pipeline autour de 17 agents spécifiques à chaque source, chacun étant adapté à une seule source de détection, car le contexte nécessaire à un tri précis dépend fortement de la source. Une seule source peut émettre des dizaines de détections distinctes, et son agent les gère toutes.

Nous disposons également d'un agent Threat Intelligence (TI) dédié qui collabore avec la flotte d'agents de tri de faible gravité et peut être appelé par n'importe quel agent lorsqu'il rencontre un indicateur ou un comportement qui justifie une investigation plus approfondie. L'agent TI interroge nos sources de renseignement sur les menaces et renvoie une évaluation structurée : cet artefact est-il connu comme malveillant, inconnu ou inoffensif. C'est important car les indicateurs bruts de compromission n'ont aucun sens sans contexte. Une adresse IP n'est qu'un nombre. La même IP enrichie de la mention « associée à une infrastructure C2 au cours des 14 derniers jours, niveau de confiance élevé » est immédiatement exploitable par l'agent.

Grâce à Structured Streaming sur Databricks, les alertes de faible gravité sont ingérées dès qu'elles se déclenchent, enrichies d'un contexte supplémentaire par l'agent TI, puis acheminées vers le sous-agent approprié pour examen.

Chaque agent suit les mêmes principes de conception :

Filtrage déterministe. Des vérifications programmatiques comparent le titre de l'alerte et les champs de contexte pour supprimer les signaux connus comme inoffensifs (nuances spécifiques à l'environnement telles que les listes d'IP de confiance, l'activité des comptes de service, le comportement attendu des outils) et générer des décisions instantanées sans aucun appel LLM. Ces vérifications traitent 30 à 95 % du volume d'alertes selon la source. Il s'agit par exemple d'un « rôle IAM connu comme sûr effectuant des opérations attendues » ou d'un « e-mail d'administrateur effectuant une gouvernance de routine de l'espace de travail ». Le filtrage peut avoir lieu au niveau de la couche de détection ou directement à côté de la logique de tri.

Enrichissement du contexte. Avant que le LLM ne voie l'alerte, l'agent récupère l'historique récent des alertes pour l'entité concernée, l'activité associée et d'autres signaux pertinents. Les agents peuvent également invoquer d'autres capacités d'agent lors de l'enrichissement — par exemple, appeler l'agent Threat Intelligence dédié lorsqu'une alerte contient une IP ou un domaine qui mérite d'être examiné.

Fonctions de prompt spécialisées. Chaque titre d'alerte est associé à une fonction de prompt. Par exemple, les alertes d'accès anormal à S3 sont dirigées vers une fonction contenant des instructions pour évaluer la reconnaissance IAM, et les alertes d'escalade de privilèges vont vers une fonction qui connaît les schémas d'attribution de rôle attendus et inattendus. Si aucune fonction dédiée ne correspond, un prompt générique de secours gère l'alerte. Les fonctions de prompt s'exécutent en mode à un seul tour (un seul appel LLM) ou en mode agent (boucle d'appel d'outils à plusieurs tours) selon que l'alerte nécessite ou non un contexte supplémentaire pour être triée en toute confiance.

Outils partagés. Les outils sont facultatifs et spécifiques à chaque agent. Lorsque le tri nécessite plus de contexte — journaux d'audit cloud bruts, alertes corrélées multi-sources ou historique d'activité IdP —, nous équipons l'agent d'outils pour les récupérer, et le LLM décide s'il doit les invoquer et à quel moment, en fonction de l'ambiguïté des preuves.

Utilitaires partagés. Pour gérer la charge de maintenance de plusieurs agents, nous avons restructuré le code utilitaire partagé dans un framework commun qui gère l'appel des agents, les tentatives et l'évaluation des performances. Toute la logique commune aux différentes sources de données réside ici, y compris la boucle d'appel du LLM, l'analyse des décisions, la répartition des outils, la persistance des résultats dans les tables Delta, le suivi des jetons, le traçage MLflow et la détection d'injections de prompts.

Raisonnement et décision du LLM. Le modèle analyse l'ensemble des preuves et renvoie un résultat structuré comprenant une décision (escalader, surveiller ou fermer) accompagnée d'une analyse justificative.

Gestion des coûts. Il existe trois contrôles sur les dépenses. Premièrement, le filtrage déterministe garantit que les alertes correspondant à des modèles connus comme inoffensifs n'atteignent jamais un LLM. L'appel le moins cher est celui que vous ne passez jamais. Deuxièmement, un outil de suivi des coûts cumule les dépenses estimées pour chaque lot et arrête le traitement si un plafond configurable est atteint, enregistrant les alertes restantes comme ignorées. Troisièmement, un plafond quotidien d'alertes limite le coût quotidien total, quel que soit le volume entrant. Au sein de chaque alerte, des budgets d'appels d'outils par catégorie évitent les boucles de recherche infinies où un LLM pourrait continuer à demander du contexte supplémentaire indéfiniment.

Si l'agent décide d'escalader, l'alerte devient un ticket dans la file d'attente IR, où les analystes examinent à la fois l'alerte brute et l'analyse de l'agent avant de prendre une décision finale de tri. Lorsqu'un analyste n'est pas d'accord avec l'escalade d'un agent, le ticket est marqué comme faux positif, et ce retour d'expérience est utilisé pour affiner les performances de l'agent. Nous avons constaté que les alertes de faible gravité escaladées par un agent étaient environ 10 fois plus susceptibles d'être de vrais positifs que les alertes existantes priorisées comme de gravité HIGH et MEDIUM.

La référence humaine derrière chaque décision d'agent

Lorsqu'un analyste humain examine un ticket escaladé, sa décision de confirmer ou d'annuler le choix de l'agent devient la vérité terrain (ground truth) pour l'évaluation. Contrairement aux programmes déterministes, où vous pouvez effectuer des tests par rapport à des spécifications fixes, les agents font preuve de jugement. Une même alerte peut produire des résultats différents d'une exécution à l'autre. Ainsi, au lieu de tester par rapport à une spécification, nous testons par rapport à un ensemble de données de référence développé par des analystes IR qui savent déjà à quoi ressemble une décision de tri de haute qualité.

Chaque requête d'agent est enregistrée à l'aide de MLflow, capturant les entrées, les étapes intermédiaires et les sorties finales. À mesure que les analystes IR étiquettent les tickets dans le cadre de leur flux de travail habituel, chaque étiquette est enregistrée directement sur la trace MLflow correspondante en tant que réponse attendue. Ces traces étiquetées établissent un ensemble de données de vérité terrain qui capture le jugement des analystes à grande échelle. Cet ensemble de données devient la référence pour évaluer toute modification future des prompts avant leur déploiement.

Pour mesurer au-delà des faux positifs, nous prévoyons d'utiliser la Databricks Review App, une interface permettant d'examiner les alertes et d'étiqueter les traces MLflow. Les analystes peuvent voir les entrées, le raisonnement et la décision de l'agent pour chaque alerte, et enregistrer le résultat attendu directement sur la trace. Cela permet aux analystes d'examiner également les alertes non escaladées, étendant ainsi la couverture de la vérité terrain aux alertes que l'agent a choisi de surveiller ou de fermer, et nous offrant une référence complète pour les trois types de décisions.

Résultats

Les agents de sécurité examinent désormais 100 % des alertes de faible gravité. Les indicateurs clés comprennent :

• Les agents ont trié plus de 18 000 alertes avec un taux d'escalade de 3,2 %
• Les alertes de faible gravité escaladées par les agents étaient environ 10 fois plus susceptibles d'être de vrais positifs que les alertes de gravité HIGH ou MEDIUM
• Temps de tri médian : 10,5 secondes
• Plus de 6 500 heures d'analystes économisées au cours des 30 premiers jours

Découvertes notables qui ont été escaladées par les agents :

• Réduction du taux de faux positifs d'une source d'alerte de 72 % à 3,4 %
• Identification de 22 domaines suspects, parqués ou malveillants
• Détection d'un cas où un utilisateur a téléchargé et exécuté un logiciel piraté ; l'agent a signalé des indicateurs comportementaux correspondant à une violation de politique et à une intention malveillante.

Ce que nous avons appris

Les LLM hallucinent sur les données de sécurité à haute entropie. Les hachages, les sous-domaines aléatoires et les noms de fichiers générés sont difficiles à traiter pour les modèles de langage. Les modèles excellent dans le raisonnement sur le langage car celui-ci présente des structures récurrentes. Les artefacts de sécurité comme les hachages sont délibérément dépourvus de structure, ce qui est précisément ce qui les rend difficiles pour les LLM. Pour garantir la précision, nous utilisons le modèle pour le raisonnement et non pour la mémorisation. Les valeurs d'artefacts spécifiques sont récupérées via des appels d'outils à des sources faisant autorité, et non depuis la mémoire du modèle.

Le contexte est roi. Les gains de performance les plus importants proviennent de l'ajout de données d'historique des alertes, de taux de faux positifs par type d'alerte et de schémas comportementaux explicites à chaque prompt. Lors du traitement d'une alerte, l'agent de tri récupère l'historique des alertes des six derniers mois pour l'utilisateur concerné. Dans plusieurs cas, les agents ont fait remonter des alertes non pas parce que l'événement déclencheur présentait individuellement un niveau de confiance élevé, mais parce qu'il s'agissait du troisième ou quatrième signal suspect provenant du même utilisateur. Ce type de corrélation comportementale est une chose que les règles de détection déterministes traditionnelles peinent à capturer.

Automatisez ce qui est prévisible et laissez les agents raisonner uniquement sur ce qui ne l'est pas. Dans la mesure du possible, optez pour des workflows déterministes afin de restreindre le champ de ce que le LLM doit analyser. Plus les instructions sont ouvertes, plus le taux de faux positifs est élevé. Des instructions d'agent précises et étape par étape ont systématiquement surpassé les prompts trop larges. L'application d'un filtrage basé sur des règles avant que le LLM ne voie une alerte en est l'un des exemples les plus efficaces.

Conçu sur Databricks

Ce système a été conçu sur Databricks en utilisant Spark Structured Streaming pour l'ingestion d'alertes en temps réel, des tables Delta pour la persistance et le reporting des alertes, MLflow Tracing pour capturer chaque décision de l'agent de bout en bout, et l'application Databricks Review App pour que les analystes puissent étiqueter les traces et établir une vérité de terrain directement à partir des données de production.

Chez Databricks, nous développons les outils que nous utilisons. C'est un exemple de la façon dont notre propre plateforme propulse les opérations de sécurité natives de l'IA. À venir : comment Databricks Genie peut apporter l'investigation en langage naturel au SOC, offrant aux analystes IR la capacité d'interroger les données d'alerte, d'explorer le contexte et d'enquêter sur les menaces de manière conversationnelle.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original