Comment les alertes basées sur l’analyse des risques peuvent réduire le bruit au sein du SOC

Des promesses enfin mises à l’épreuve

Si les éditeurs ont présenté avec insistance l’alerte fondée sur le risque comme un remède miracle, sa mise en œuvre reposait jusqu’ici essentiellement sur des retours d’expérience anecdotiques.

Une étude de référence menée par des chercheurs de l’Institut Fraunhofer pour la communication, le traitement de l’information et l’ergonomie (Fraunhofer FKIE) livre aujourd’hui la première évaluation empirique et systématique de cette approche. Elle en démontre l’efficacité tout en identifiant les stratégies de scoring du risque qui fonctionnent réellement.

Pour sortir l’analyse fondée sur le risque du registre des promesses commerciales et des approximations, les chercheurs ont reformulé la notion d’alerte d’abord comme un problème de hiérarchisation continue, à l’aide de CATS (Cybersecurity Alert Triage Exploration and Evaluation System), une nouvelle suite d’expérimentation open source qu’ils ont développée.

L’équipe a ainsi ramené le système d’alerte à cinq hypothèses de risque fondamentales, qu’elle a évaluées sur huit jeux de données d’alertes de natures différentes :

• Niveau de règle. Hiérarchisation selon la sévérité intrinsèque de la règle de détection déclenchée.
• Accumulation. Scoring selon le volume spatio-temporel des alertes liées à une entité.
• Variété. Scoring selon la diversité des types d’alertes ou des règles de détection distinctes déclenchés par une entité.
• Rareté. Scoring selon la faible fréquence d’un type d’alerte donné dans l’environnement.
• Apériodicité. Scoring selon des schémas temporels non répétitifs ou irréguliers, afin d’écarter les traitements par lots planifiés et les processus périodiques en arrière-plan.

Les résultats tracent une ligne de partage nette entre ce qui fonctionne et ce qui échoue. La combinaison de ces mécanismes de scoring a porté la performance de hiérarchisation de l’alerte fondée sur le risque à un score moyen de 0,92 (sur 1), contre 0,72 pour les règles de sévérité classiques et 0,50 pour des alertes non hiérarchisées.

L’étude montre aussi que trois facteurs font l’essentiel du travail pour distinguer les attaques réelles du bruit : une sévérité élevée de la règle, le volume d’alertes rattachées à un même actif sur une courte période, et la variété des types d’alertes déclenchées sur cet actif en l’espace d’une heure.

À l’inverse, des postulats longtemps privilégiés par les éditeurs – comme le scoring des alertes selon leur caractère « rare » ou « irrégulier » – ne font pas mieux que le hasard. Selon les auteurs du rapport, dès qu’un événement rare se répète au cours d’une attaque, il perd son score de « rareté », si bien que ces modèles échouent précisément au moment où l’on en a le plus besoin.

« Ce qui nous a le plus surpris, c’est que la même combinaison d’heuristiques simples – en particulier la variété et l’accumulation spatio-temporelles des alertes – a très bien hiérarchisé les alertes sur des jeux de données hétérogènes », a déclaré à TechTarget Rafael Uetz, auteur principal de l’étude et chercheur au Fraunhofer FKIE.

Rafael Uetz souligne que le passage de seuils d’alerte fixes à des scores de risque continus change en profondeur le travail des analystes : « Cela leur permet de trier les alertes par ordre de risque décroissant jusqu’à épuisement du temps dont ils disposent, explique-t-il. Avec des seuils fixes, ils reçoivent généralement trop peu ou trop d’alertes au regard de leur temps disponible. »

Dépasser la sévérité statique

L’étude montre pourquoi le recours traditionnel à des indicateurs de sécurité statiques, comme les niveaux de sévérité du Common Vulnerability Scoring System (CVSS), trouve ses limites dans les environnements opérationnels réels.

Le CVSS est un indicateur statique de sévérité des vulnérabilités : il évalue ce qui pourrait se produire, en théorie, si une faille était exploitée. Fondé sur le risque, un système d’alerte fonctionne, lui, comme un moteur dynamique de risques comportementaux, qui évalue le contexte opérationnel en temps réel.

Le rapport l’illustre par une séquence courante en entreprise : sur un même système, en moins de 24 heures, un lecteur PDF plante, un nouveau compte utilisateur est créé et le trafic réseau sortant s’envole. Pris isolément, aucun de ces événements de faible niveau ne justifie un examen manuel, et un analyste épuisé les écarterait probablement comme du bruit ordinaire.

Avec notre type d’alerte en revanche, ces trois événements ajoutent discrètement des points de risque à l’hôte concerné. Cumulés, ils font franchir le seuil de risque et déclenchent une alerte unique et consolidée, intitulée « High Risk Entity » (entité à haut risque), assortie d’une chronologie de l’attaque.

Couper court au bruit

Les éditeurs pionniers de l’alerte fondée sur le risque font état de gains considérables sur le terrain.

« Tout dépend du modèle de détection et d’alerte en place chez le client, mais la réduction du nombre d’alertes se situe généralement entre 50 et 80 %, indique Haylee Mills, spécialiste produit sécurité et experte de l’alerte chez Splunk, qui commercialise des produits fondés sur cette approche. Dans mon cas, lorsque j’étais moi-même cliente, on était plus proche de 95 %. »

Et d’ajouter : « La réduction de la lassitude face aux alertes, qui relève d’une appréciation qualitative, est difficile à chiffrer. Mais comme une alerte de risque constitue un ensemble dynamique et contextualisé d’événements à investiguer, l’analyste a beaucoup moins de travail d’investigation fastidieux à produire lui-même en répétant les mêmes procédures pour chaque alerte isolée. »

Haylee Mills insiste : bien configurer ces seuils dynamiques suppose de regarder au-delà des simples scores de risque.

« Une option consiste à s’appuyer sur le nombre de techniques MITRE observées pour une entité sur une période plus longue, explique-t-elle. L’une de mes méthodes préférées consiste à regrouper les détections par grande finalité (EDR, cloud, authentification, web, pare-feu, IDS, etc.), puis à alerter verticalement lorsqu’une entité a déclenché trois détections cloud, ou horizontalement lorsqu’elle a déclenché une détection d’authentification, une détection cloud et une détection EDR. »

Obstacles opérationnels et perspectives

Malgré ce net gain de performance, faire basculer un SOC d’entreprise vers la notion de risque pour le système d’alerte se heurte à des obstacles opérationnels bien identifiés. La principale difficulté ne tient pas aux calculs sous-jacents, mais à la qualité des données, au réglage et à la confiance des analystes.

« Le plus grand défi, pour la mise en production, consiste à bien calibrer le scoring du risque et à faire en sorte que les analystes lui fassent confiance, relève Anand Sagar, de CGI. L’alerte fondée sur le risque a besoin de données issues de multiples sources (identités, terminaux, réseau, renseignement sur les menaces, comportement des utilisateurs), mais ces données ne sont pas toujours cohérentes ni complètes. Même une fois les données collectées, il est difficile de décider quel poids de risque attribuer à chaque signal. Si le scoring est trop agressif, on finit par générer davantage de faux positifs ; s’il est trop faible, on risque de passer à côté de menaces réelles. »

Pour réussir l’adoption, Haylee Mills conseille aux équipes d’ingénierie sécurité de rapprocher dès le départ la logique de détection et le travail quotidien des analystes.

« Assurez-vous que les analystes sont impliqués avant que les alertes ne commencent à leur parvenir ; vous seriez surpris de voir à quel point c’est rarement le cas, prévient-elle. Organisez un retour hebdomadaire où au moins un analyste consacre une heure à traiter vos alertes de préproduction et à dire franchement ce qui a été difficile, ce qui lui manquerait, etc. »

Alors que les SOC évaluent les nouveaux outils de tri des alertes fondés sur l’IA et les grands modèles de langage (LLM), la recherche montre qu’une chaîne d’alerte fondée sur le risque, correctement configurée, constitue une base de référence peu gourmande en calcul, qui soulage l’épuisement des analystes sans surcoût significatif.

Au-delà de l’efficacité des analystes, Rafael Uetz voit cette approche jouer un rôle essentiel à mesure que les équipes de sécurité adoptent l’automatisation par l’IA.

« Elle pourrait servir de préfiltre au tri des alertes par LLM, estime-t-il. Grâce notamment au scoring continu du risque, cela permettrait d’utiliser efficacement un volume limité de tokens LLM, exactement comme pour les ressources limitées des analystes humains. ».............

James Walker, Rédacteur en chef de TechTarget Cybersecurity.

Ce conseil est initialement paru en anglais sur Techtarget.com, une publication sœur du MagIT.