Comment évaluer si un SOC est prêt pour des agents d’IA

L’adoption de l’IA se généralise parmi les équipes chargées des opérations de sécurité. L’enquête State of AI in Security Operations 2026 de Prophet Security, menée auprès de plus de 250 RSSI, responsables de SOC et professionnels, a révélé que 40 % des équipes utilisent l’IA quotidiennement, tandis que 56 % supplémentaires la testent. Seulement 4 % ont déclaré ne prévoir aucun projet d’adoption de cette technologie.

Pour les équipes qui évaluent encore l’IA, la question essentielle est de savoir si leur SOC est prêt à déployer des agents. La préparation comporte deux dimensions : les problèmes opérationnels qu’un agent d’IA pourrait résoudre, ainsi que les fondations techniques et de gouvernance nécessaires pour enquêter précisément sur les alertes.

Les agents d’IA sont particulièrement utiles dans les SOC confrontés à des escalades tardives de la détection et de la réponse managées, à un manque de contexte, à une couverture limitée des fournisseurs, à des retards dans le traitement des alertes et à une faible visibilité sur les décisions prises au cours des investigations. Les équipes internes peuvent également avoir du mal à déterminer rapidement si elles sont affectées par une nouvelle vulnérabilité ou campagne, à enquêter sur les alertes de faible gravité, à ajuster les détections trop bruyantes, à mener des recherches de menaces et à maintenir une couverture en dehors des heures normales de travail.

L’enquête a révélé que 60 % des répondants avaient vu une alerte ignorée ou manquée se transformer ultérieurement en problème grave, comme une compromission ou une interruption de service. Elle a également indiqué que 28 % des alertes ne font jamais l’objet d’une investigation. Ces pressions mettent la recherche proactive et l’ingénierie de détection en concurrence avec le traitement quotidien des alertes.

Le modèle de maturité des SOC décrit par Prophet Security place la gestion des alertes à la base, suivie par la couverture de détection, la connaissance des menaces, la recherche proactive et les améliorations de la posture de sécurité. Les agents d’IA commencent généralement par l’investigation des alertes, même si les plateformes plus récentes peuvent également prendre en charge la recherche de menaces et l’ingénierie de détection. Le temps libéré par les tâches routinières peut ensuite être consacré aux activités situées plus haut dans le modèle.

La préparation technique commence par l’accès. Un agent ne peut enquêter que sur les données qu’il peut interroger ; les intégrations pertinentes peuvent donc inclure le SIEM, l’EDR, le fournisseur d’identité, les plateformes cloud, la messagerie électronique et les applications SaaS importantes. Il a également besoin d’un contexte lisible, comme la criticité des actifs, les rôles des utilisateurs, les listes de VIP, les unités opérationnelles et les activités connues comme légitimes. La surveillance de l’état et de la fraîcheur des pipelines de journalisation est tout aussi importante, car des données manquantes ou retardées peuvent donner l’impression qu’une investigation est terminée alors que des éléments de preuve essentiels sont absents.

Un test pratique consiste à examiner cinq incidents récents et à répertorier chaque requête utilisée par un analyste senior pour les résoudre. Toute requête que l’agent envisagé ne peut pas exécuter révèle une lacune d’accès ou d’intégration. La gestion des données doit également être examinée : 44 % des répondants à l’enquête ont cité la confidentialité des données et l’entraînement des modèles d’IA comme un obstacle majeur. Les organisations doivent demander aux fournisseurs si les données des clients sont utilisées pour entraîner les modèles et où ces données sont traitées.

Un projet pilote doit également s’appuyer sur une définition écrite d’une investigation achevée. Cette norme doit préciser les éléments de preuve requis pour les cas courants, notamment les alertes d’hameçonnage et de déplacement impossible, ainsi que les éléments suffisants pour classer une alerte comme bénigne. Les organisations doivent enregistrer des indicateurs de référence, tels que le pourcentage d’alertes faisant l’objet d’une investigation, le temps moyen nécessaire à l’investigation, le délai avant le premier examen et le taux de réouverture des alertes clôturées.

Le rapport indique qu’une investigation approfondie dure en moyenne 75 minutes et que les alertes attendent souvent près d’une heure avant d’être ouvertes. Il précise également que jusqu’à 40 % des organisations ont désactivé certaines détections parce qu’elles ne disposaient pas de la capacité nécessaire pour les examiner. Une liste documentée de ces détections peut aider à déterminer où une investigation automatisée supplémentaire pourrait rétablir la couverture.

La gouvernance doit distinguer l’investigation de la réponse. Dans l’enquête, 57 % des équipes exigeaient un examen humain avant chaque décision de l’IA visant à clôturer une alerte. Pour les actions de réponse, 44 % utilisaient l’IA pour recommander des actions à effectuer par des personnes, tandis que 30 % autorisaient une remédiation autonome dans les cas à faible risque. Aucun répondant n’a déclaré accorder une autonomie totale et non supervisée.

Avant un projet pilote, les organisations doivent définir quelles actions nécessitent toujours une approbation, qui peut étendre les autorisations de l’agent, où ses conclusions apparaîtront et qui est responsable de l’examen des erreurs. Commencer par un accès d’investigation en lecture seule et élargir progressivement les autorisations suit la même approche prudente que celle utilisée lors de l’intégration d’un nouvel analyste humain.

La liste de contrôle proposée pour évaluer la préparation distingue le besoin d’IA de la capacité à la déployer. Un argument solide en faveur de l’adoption peut exister lorsque les alertes arrivent tardivement, que les fournisseurs manquent de contexte, que les investigations sont retardées, que des détections ont été désactivées ou que les cas difficiles dépendent de seulement quelques analystes seniors. La préparation au déploiement dépend, quant à elle, de l’accès aux API, de la disponibilité du contexte sur les actifs et les utilisateurs, de normes d’investigation écrites, de règles d’approbation, de la surveillance des sources de journaux, de données de performance de référence, d’un inventaire des détections désactivées et d’un plan d’utilisation du temps rendu à l’équipe.

Si le SOC n’est pas prêt, la préparation recommandée consiste principalement en un travail de configuration et de documentation. Les équipes peuvent commencer par combler les lacunes d’accès identifiées lors de l’examen des cinq incidents, documenter les normes applicables à leurs types d’alertes les plus fréquents et faire fonctionner un agent aux côtés des analystes pendant plusieurs semaines. Les interventions des analystes doivent être enregistrées afin de fournir des informations sur le contexte manquant ou les comportements incorrects. Les autorisations peuvent ensuite être élargies, une catégorie d’action à la fois.

Construire un agent en interne constitue une autre option, mais l’enquête fait apparaître des risques importants. Parmi les utilisateurs de l’IA, 72 % avaient essayé de créer des outils d’IA internes, et 46 % de ces projets avaient été abandonnés, n’avaient pas atteint la production ou avaient été remplacés par un produit commercial. Au-delà du prototype, les équipes doivent maintenir les intégrations, gérer les changements d’API et les limites de débit, prendre en charge les dépréciations de modèles, répéter les évaluations et les tests d’injection de prompts, et conserver des pistes d’audit expliquant les décisions relatives aux alertes.

Prophet Security présente sa propre plateforme Prophet AI comme prenant en charge l’investigation, la recherche de menaces et l’ingénierie de détection. Son agent SOC Analyst interroge les outils de sécurité et enregistre les questions, les requêtes et les éléments de preuve qui sous-tendent les décisions, tandis que les actions de réponse restent soumises aux autorisations définies par le client et à une approbation humaine par défaut. Son composant Threat Hunter est conçu pour exécuter des recherches concernant les menaces nouvellement divulguées et les investigations planifiées, tandis que son composant Detection Engineer utilise les résultats des investigations et les lacunes de couverture pour proposer et tester rétrospectivement des détections avant leur approbation.

Selon l’entreprise, les conclusions issues de ces fonctions s’alimentent mutuellement : les investigations peuvent révéler des détections trop bruyantes ou manquantes, les recherches peuvent examiner ces lacunes et leurs résultats peuvent contribuer à l’élaboration de nouvelles règles de détection. Prophet Security affirme également que les données des clients ne servent pas à entraîner ses modèles et que son plan de données peut fonctionner à l’intérieur du propre cloud privé virtuel d’un client.

Sources: The Hacker News.