Raisonnement et fiabilité : pourquoi l'IA stagne dans les SoC modernes

La véritable question de l'IA dans les SOC est celle de l'autorité.

Tous les responsables de la sécurité connaissent cet argument : l’IA triera vos alertes, enquêtera sur vos incidents et comblera le fossé entre le volume d’alertes et le nombre d’analystes. La plupart ont déjà vu l’IA s’intégrer à leurs outils, souvent sans l’avoir demandée. Mais rares sont ceux qui la laissent prendre des décisions importantes.

Un nouveau rapport des cyberfuturistes, Le raisonnement rencontre la fiabilité, Ce rapport explique pourquoi. Rédigé par Oliver Rochford, fondateur de Cyberfuturists et ancien analyste chez Gartner, il fait évoluer le débat au-delà de la simple question de l'utilisation de l'IA par les équipes. Comme l'indique le rapport : “ L'IA est déjà présente dans les outils utilisés par les équipes de sécurité. Le RSSI doit désormais décider du niveau d'autorité à lui accorder. ”

Cette distinction est au cœur de la recherche. Un résumé lu par un analyste est une chose. Une action automatisée qui modifie votre environnement en est une autre. Comme l'indique le rapport : “ La production d'un résumé comporte un risque limité. Supprimer une alerte, faire remonter un incident, désactiver un compte ou bloquer un appareil modifie l'environnement et exige un niveau de contrôle plus élevé. ”

Un écart d'adoption qui dépend de ce que l'on considère

Cette étude s'appuie sur deux entretiens approfondis avec des praticiens utilisant des solutions SOC IA autonomes en production, plus de 30 présentations de fournisseurs réalisées sur une période de 18 mois, des commentaires de praticiens et des données de télémétrie Swimlane. Les deux personnes interrogées ont été choisies pour mettre en contraste des équipes très différentes : le RSSI d'une entreprise européenne de mobilité présente sur plus de 60 sites et le seul expert en sécurité d'une ONG américaine de protection de l'environnement accompagnant environ 1 000 utilisateurs.

Premier constat : les chiffres d'adoption des SOC IA mesurent rarement la même chose. Gartner estime l'adoption des agents SOC IA à seulement 1–5%. Pourtant, de nombreux chiffres d'adoption publiés comptabilisent les projets pilotes, les fonctionnalités activées ou les analystes ayant simplement accès à un assistant. Le rapport est clair quant au seuil pertinent : “ Un résumé ou une ébauche d'enquête ne constituent pas une adoption opérationnelle. Le seuil significatif est celui où le SOC s'appuie sur l'IA pour prendre ou mettre en œuvre une décision de sécurité définie. ”

Les données télémétriques de Swimlane révèlent une situation différente parmi les organisations ayant déjà mis en place une automatisation de la sécurité : 94% clients exécutent des charges de travail d'agents en production au sein de Plateforme de turbine de couloir de nage. Un MSSP régional effectue en moyenne 1,48 million d'actions par jour, dont 6 000 actions d'IA, l'IA et l'automatisation déterministe fonctionnant côte à côte.

Le rapport prend soin de ne pas exagérer ce point. Il précise que les deux chiffres “ ne reposent pas sur la même population ni le même dénominateur et ne doivent pas être considérés comme une comparaison statistique directe ”. Il soutient toutefois qu’ils soulèvent une question qui mérite d’être étudiée : “ L’IA est-elle plus facilement déployée en production lorsque des intégrations et des contrôles opérationnels existent déjà ? ”

Pourquoi l'IA stagne-t-elle entre le pilote et la production ?

Un projet pilote est mené avec des données préparées, une intégration fiable et un volume de cas gérable. En production, la télémétrie est incomplète, les permissions varient, les connecteurs tombent en panne, les entrées sont manipulées et les pics de charge surviennent. D'après l'étude, le problème ne réside pas dans un manque d'intérêt. Lors des entretiens et des réunions d'information, les contraintes récurrentes étaient “ la confiance, la gouvernance, l'intégration, le coût et la capacité de vérifier les résultats ”.”

Confiance. Les équipes de sécurité ne communiquent des décisions spécifiques qu'après avoir observé Les IA fonctionnent dans leur propre environnement. Le rapport souligne que le système a besoin d'un moyen honnête d'admettre son ignorance. Le fait de contraindre chaque cas à un verdict bénin ou malveillant “ masque l'incertitude et crée deux risques opérationnels : des escalades inutiles que les analystes apprennent à ignorer, et des omissions injustifiées qui peuvent ne pas être découvertes avant l'examen d'un incident ”.”

Gouvernance. Une IA capable d'agir nécessite une identité nommée, un accès aux privilèges minimaux et un ensemble d'outils définis. Ses invites, ses modèles et ses sources de contexte constituent également une configuration de production. Ils requièrent des tests, une validation, un historique des versions et une possibilité de restauration.

Intégration. L'IA doit opérer avec les outils déjà utilisés par le SOC, et ces données constituent une surface d'attaque. Un ancien ingénieur en détection, interviewé par un participant, a souligné que l'injection de prompts via les journaux et les artefacts d'attaque justifiait de dissocier la lecture de l'action.

Coût. L'automatisation des processus d'enrichissement et de billetterie par un modèle engendre des coûts et une variabilité supplémentaires sans pour autant améliorer la prise de décision. Le rapport recommande de mesurer le “ coût par résultat validé en conditions normales et de pointe, plutôt que de se baser sur le prix de la licence ou le coût d'exécution du modèle ”.”

Vérification. Il s'agit peut-être de l'obstacle le plus souvent négligé. Comme l'indique le rapport, “ une commande exécutée avec succès ne prouve pas que l'objectif de sécurité visé a été atteint ”. Le processus doit confirmer que le compte a bien été désactivé ou que l'indicateur a bien été bloqué, puis, en cas d'échec, réessayer, annuler l'opération ou escalader le processus.

Surtout, ces barrières ne s'annulent pas mutuellement. “ L'intégration sans vérification peut automatiser une erreur ”, écrivent les auteurs. Un flux de travail ne gagne en autorité en matière d'IA que lorsque les cinq éléments sont validés conjointement en conditions de production.

Ce que les praticiens ont fait

Les deux personnes interrogées utilisaient l'IA pour la détection et l'investigation, et laissaient les décisions de réponse à l'humain. Leur préoccupation était d'ordre pratique : elles avaient besoin de comprendre comment le système parvenait à une conclusion, comment il gérait l'incertitude et comment il pouvait échouer.

Les résultats étaient néanmoins significatifs. Au sein de l'entreprise de mobilité, l'IA a corrélé les données RH, les profils publics et les données d'authentification pour déceler le partage d'identifiants entre les franchises, une pratique mineure que l'équipe a indiqué ne pas avoir étudiée à grande échelle. Au sein de l'ONG, le service d'IA a coûté la moitié des 1 400 000 £ de dépenses annuelles liées aux incidents qu'il a permis de réaliser, et la mention “ non concluant ” a été considérée comme une réponse valable lorsque le contexte était insuffisant.

Redéfinir le concept d“” IA native » pour les opérations de sécurité

On part souvent du principe que les opérations de sécurité basées sur l'IA nécessitent une architecture entièrement nouvelle, articulée autour de modèles et d'agents. La recherche nuance cette idée : “ Pour les opérations de sécurité, l'IA native n'est pas une affirmation architecturale. Cela signifie que les décisions, les actions et les résultats du système peuvent être testés. ”

Ce recadrage conduit à une division claire du travail. L'IA est précieuse lorsque les preuves sont incomplètes, contradictoires ou inconnues. Elle peut rassembler le contexte, comparer les explications et recommander une réponse. L'automatisation déterministe est plus performante dans l'exécution : application des autorisations, acheminement des approbations, lancement des outils, enregistrement des modifications et vérification des résultats. Conclusion du rapport : “ Une production IA SOC ” Il faut les deux. »

Ingénierie des boucles : conception, exécution, validation

Cet article emprunte un concept au développement logiciel et à la recherche sur les vulnérabilités pour décrire leur collaboration. L'IA interprète les données, l'automatisation de la sécurité exécute l'action approuvée et une vérification indépendante confirme le résultat. Les auteurs nomment ce processus “ ingénierie en boucle ” et affirment sans détour : « Un flux de travail dont le résultat ne peut être vérifié est inachevé. »

Œuvres connues et œuvres inconnues

Le modèle opérationnel classe les tâches en fonction de leur incertitude. Les tâches connues et répétables ont leur place dans des manuels de procédures déterministes. Les cas inhabituels ou ambigus sont confiés à l'IA sous supervision. Lorsqu'un schéma se répète et que la réponse s'avère fiable, ses étapes sont intégrées à un playbook testé et versionné, tandis que l'IA reste disponible pour les exceptions. Le processus fonctionne également en sens inverse, car “ les contrôles échoués et les dérives matérielles ramènent le flux de travail à la supervision ”.”

Implications pratiques pour les RSSI

Le La recherche offre des conseils concrets pour l'élaboration d'une feuille de route en matière d'IA :

• Mesurez les résultats, pas l'activité. Le nombre d'alertes traitées et le temps gagné témoignent de l'utilisation, et non de l'exactitude des décisions. Suivez la qualité des verdicts par rapport à une base de référence vérifiée par un humain, les taux de validation, le délai de résolution validée et le coût par résultat validé.
• Développez votre autorité un flux de travail à la fois. Il est raisonnable d'automatiser l'enrichissement, d'exiger une approbation pour le confinement des points de terminaison et de maintenir la compromission d'identité en mode recommandation uniquement.
• Investissez dans des systèmes de contrôle qui durent plus longtemps que le modèle. L'identité, l'accès, l'intégration, la validation et l'audit devraient vous permettre de changer de modèle sans avoir à reconstruire la structure d'autorité.
• Anticipez les changements de main-d'œuvre. Un RSSI interrogé a déclaré que l'automatisation du tri des tentatives d'hameçonnage avait remplacé le travail existant en quelques semaines, et que l'équipe avait formé un analyste à l'investigation des menaces dans le cloud.
• Ne déléguez pas la responsabilité. Un MDR ou un MSSP peut fournir des capacités, mais les contrats doivent couvrir les modifications de modèles, l'accès à l'audit, les limites d'approbation et la restauration.

L'automatisation comme outil au service de l'IA

Pour les organisations qui utilisent déjà l'automatisation de la sécurité, l'étude révèle un avantage considérable. Des plateformes comme Turbine de couloir de nage Ces fonctionnalités permettent déjà de se connecter aux outils de sécurité, de conserver l'état des dossiers, d'appliquer les identités et les autorisations, d'acheminer les approbations et d'enregistrer les actions. Selon le rapport, “ ces fonctionnalités constituent le cadre nécessaire pour passer de la recommandation d'un modèle à un flux de travail de production contrôlé ”.”

La recherche est prudente quant à ce que cela prouve et ne prouve pas. L'automatisation existante n'améliore pas les performances d'un modèle d'IA. Elle permet en revanche de réduire l'infrastructure d'intégration et de contrôle qu'une équipe doit mettre en place avant de tester l'IA en conditions réelles. Un produit SOC d'IA autonome doit démontrer simultanément son raisonnement et ses contrôles associés. Sur une plateforme d'automatisation établie, l'évaluation se concentre sur une seule question : “ L'IA améliore-t-elle une décision de sécurité définie sans affaiblir les contrôles existants qui la régissent ? ”

C'est l'approche derrière Swimlane AI SOC, L'IA d'Hero s'intègre aux flux de travail, connecteurs et processus d'approbation déterministes auxquels les équipes de sécurité font déjà confiance. Comme le conclut le rapport, la solution proposée par Swimlane est un SOC d'IA “ intégré à une plateforme d'automatisation existante plutôt que comme un environnement de décision et de contrôle distinct ”.”

Le test du harnais

Cette étude ne demande pas aux lecteurs de croire sur parole les affirmations des fournisseurs, y compris Swimlane. “ Une allégation concernant un produit ne constitue pas un contrôle ”, écrivent les auteurs. Ils proposent plutôt un test rigoureux basé sur sept questions que tout RSSI devrait se poser avant d'autoriser l'IA à agir, chacune étant illustrée par un flux de travail représentatif :

1. Une recommandation d'IA peut-elle se transformer en action contrôlée ?
2. L'IA est-elle gouvernée comme une identité opérationnelle ?
3. Que se passe-t-il lorsque l'IA se trompe ou est incertaine ?
4. Les tâches répétitives en IA peuvent-elles évoluer vers l'automatisation ?
5. Les performances sont-elles mesurées par rapport à des résultats évalués par des humains ?
6. Le flux de travail vérifie-t-il le résultat de sécurité ?
7. Les résultats économiques sont-ils prévisibles à l'échelle de la production ?

Le rapport complet associe chaque question aux preuves à demander, aux points d'alerte à surveiller et à la manière dont Swimlane y remédie. Son critère est simple : “ Une solution passe le test de validation un flux de travail à la fois. ”

L'objectif n'est pas l'autonomie maximale

Pour les équipes de sécurité, la question stratégique n'est plus de savoir si elles vont utiliser l'IA, mais comment l'implémenter sans compromettre les contrôles dont dépendent leurs opérations. Le raisonnement rencontre la fiabilité offre aux RSSI une solution pratique pour répondre à cette question : associer le raisonnement de l’IA à la fiabilité de l’automatisation déterministe, vérifier chaque résultat et étendre l’autorité uniquement là où les preuves sont solides.

La phrase de conclusion du rapport résume bien le point essentiel :

“ L’objectif n’est pas une autonomie maximale. Il s’agit d’une amélioration mesurable des résultats en matière de sécurité, avec des preuves suffisantes pour déterminer quand l’IA doit agir, quand une personne doit décider et quand le flux de travail doit s’arrêter. ”

Télécharger le rapport complet Pour consulter l'étude complète, incluant le questionnaire de sept questions et les huit décisions pour votre feuille de route SOC, vous êtes prêt à découvrir comment Swimlane Turbine combine des scénarios déterministes avec le raisonnement de Hero AI. Obtenez une démonstration de SoC IA.