Automated Root Cause Analysis of Security Incidents Using Causal Machine Learning

Lorsqu'un système de sécurité déclenche une alarme, le défi immédiat n'est pas simplement de remarquer que quelque chose ne va pas, mais de comprendre exactement où le problème a commencé. Les réseaux modernes génèrent un flux constant de données : qui s'est connecté, quels programmes ont été exécutés, quels fichiers ont été ouverts et comment les permissions ont changé. Souvent, une seule petite erreur au début d'une réaction en chaîne peut déclencher une cascade d'événements étranges qui semblent tout aussi suspects. Si un enquêteur ne regarde que le signal le plus fort ou le plus inhabituel, il pourrait confondre un symptôme avec une cause, poursuivant un effet en aval alors que le véritable problème reste caché en amont. Pour résoudre cela, les chercheurs se tournent vers une façon de penser appelée le raisonnement causal. Au lieu de simplement demander quels événements se produisent ensemble, cette approche demande quels événements font réellement que d'autres se produisent. Elle traite le système comme un ensemble d'engrenages connectés : si un engrenage tourne, il pousse le suivant, qui pousse le suivant. Le but est de trouver le premier engrenage qui a été poussé, plutôt que celui qui a tourné le plus vite.

Une chercheuse nommée Rehana Devani a testé une méthode spécifique pour trouver ce premier engrenage dans un environnement simulé et contrôlé. L'étude n'analyse pas de tentatives de piratage réelles ou de réseaux d'entreprise en direct. Au lieu de cela, elle construit un modèle numérique d'un système de sécurité composé de six parties distinctes, représentant des éléments tels que l'accès, la politique et l'exécution. Dans ce modèle, les chercheurs savent exactement comment les parties sont connectées et comment elles s'influencent les unes les autres. Ils introduisent ensuite une perturbation spécifique et artificielle — un changement soudain de quatre unités dans le comportement de l'une des parties de départ — et observent comment l'onde de choc se propage à travers le reste du système. L'expérience pose une question simple mais difficile : si vous voyez l'ensemble du système agir étrangement, un programme informatique peut-il identifier correctement quelle partie de départ unique a été modifiée, ou sera-t-il distrait par le bruit des parties qui ont réagi au changement ?

Les chercheurs ont comparé deux façons d'analyser les données. La première méthode, qu'ils appellent le score marginal, consiste à regarder chaque partie de manière isolée et à demander : « À quel point cette partie est-elle inhabituelle par rapport à la normale ? » Cette approche échoue souvent car une partie qui ne fait que réagir à un problème peut paraître tout aussi étrange que la partie qui l'a causé. La seconde méthode, connue sous le nom de score résiduel, est plus sophistiquée. Elle utilise une carte des connexions pour demander : « Étant donné ce que font les parties qui alimentent celle-ci, cette partie se comporte-t-elle étrangement ? » Si une partie agit bizarrement uniquement parce que ses voisines agissent bizarrement, cette méthode reconnaît que la partie elle-même n'est pas la source. Cependant, si une partie agit bizarrement même lorsque ses voisines se comportent normalement, elle est signalée comme le coupable probable.

Dans la version la plus pure de l'expérience, où les données étaient parfaitement claires et exemptes de tout bruit de fond, la méthode sophistiquée a remarquablement bien fonctionné. Elle a correctement identifié le point de départ de la perturbation dans près de 98 pour cent des cas. La méthode plus simple, qui ignorait les connexions entre les parties, n'était correcte qu'environ 87 pour cent du temps. Cet écart montre que la compréhension de la structure du système aide à séparer la cause réelle des symptômes. Cependant, l'étude a également testé la résistance de cette méthode lorsque les données sont désordonnées, ce qui est le cas des systèmes du monde réel. Les chercheurs ont ajouté un bruit statique aléatoire, ou bruit de capteur, aux mesures pour simuler une collecte de données imparfaite. À mesure que le bruit augmentait, la précision de la méthode sophistiquée chutait, tombant à environ 81 pour cent lorsque le niveau de bruit était modéré. La méthode plus simple peinait encore plus, chutant à environ 62 pour cent. Ce résultat confirme que, bien que connaître les connexions aide, la qualité des données est tout aussi critique. Si les mesures sont trop floues, même la meilleure carte ne peut guider l'enquêteur vers la bonne réponse.

L'étude a également exploré ce qui se passe si la carte elle-même est légèrement erronée. Dans un test, les chercheurs ont délibérément supprimé une connexion connue du modèle, faisant comme s'ils ignoraient qu'une partie influençait une autre. La méthode a tout de même bien performé, identifiant correctement la cause environ 94 pour cent du temps dans les données propres, mais la précision a chuté à mesure que le bruit augmentait. Cela suggère que l'approche est assez tolérante vis-à-vis des informations manquantes, mais qu'elle n'est pas parfaite. Les chercheurs ont également vérifié si trouver la bonne cause permettrait réellement de résoudre le problème. Ils ont simulé une réparation en inversant le changement injecté dans le système. Lorsqu'ils ciblaient le bon point de départ, le comportement étrange du système disparaissait presque entièrement. Lorsqu'ils ciblaient le mauvais point, le système restait perturbé. Cela a confirmé que la méthode ne se contente pas de deviner ; elle identifie le levier spécifique qui, si on le tire en arrière, stopperait la réaction en chaîne.

Malgré ces résultats prometteurs, l'article prend soin de préciser ce qu'il n'a pas fait. Toute l'expérience s'est déroulée à l'intérieur d'une simulation informatique avec un modèle réduit de six parties. Les chercheurs n'ont pas testé cela sur de vrais réseaux d'entreprise, de vrais pirates ou de vrais journaux de sécurité. Ils n'ont pas prétendu que leur méthode pouvait découvrir de nouveaux types d'attaques ou qu'elle fonctionne sans une carte prédéfinie du système. L'étude prouve que si vous savez déjà comment un système est connecté, vous pouvez utiliser un type spécifique de calcul pour trouver un problème injecté de manière plus précise qu'en cherchant simplement les chiffres les plus étranges. Elle ne prouve pas que cela fonctionnera dans la réalité chaotique, bruyante et complexe d'une entreprise en activité. La valeur de ce travail réside dans sa clarté : elle sépare l'idée de trouver une cause de l'idée de découvrir la carte, et elle montre précisément à quel point la qualité des données est importante. Avant que cette méthode puisse être utilisée pour protéger de véritables organisations, elle doit être testée dans des environnements où les connexions ne sont pas connues à l'avance et où les données ne sont pas parfaitement propres. Pour l'instant, elle constitue une démonstration précise et reproductible de la manière dont le raisonnement causal peut améliorer la recherche de la source d'un incident de sécurité, à condition que les règles du jeu soient clairement comprises.