Aller au contenu
Terrain · 8 min de lecture

Réduire le bruit d'alertes en priorisant par risk_score

4 500 alertes par semaine, moins de 2 % à investiguer. Comment le risk_score change l’ordre, pas le volume.

Par Hakim Djelili

Le constat

On se noie, alors on coupe des règles

Les chiffres avant le tri

4 500
alertes / semaine
parc de 800 postes, avant tri, presque tout du bruit
< 2 %
méritent une investigation
le reste est connu, répétitif, jamais désactivé
15 s
par alerte
le temps réel de « traitement » quand tout arrive à plat. Autrement dit : on ne traite plus.

Couper une règle calme la file, et ouvre un trou

Face au mur, on désactive. La file redescend. La couverture aussi. Ce qu’il faut bouger, c’est l’ordre d’affichage, pas la liste des règles encore allumées.

La mécanique

Ce qu’on met dans un risk_score

Gravité, actif, historique, cumul

Un chiffre sorti d’une boîte, personne n’y croit longtemps. On compose avec ce qu’on a.

  • Technique. Énumérer des partages, ce n’est pas le même poids qu’un dump de credentials. Le mapping ATT&CK de la règle donne déjà une gravité. Autant s’en servir.
  • Actif. Même alerte, poste stagiaire ou contrôleur de domaine : l’histoire n’est pas la même. Sans un minimum de référentiel d’actifs, le score recopie juste la gravité de la règle.
  • Historique de la règle. 200 faux positifs ce trimestre : on baisse le poids. On ne jette pas la règle.
  • Accumulation. Trois alertes moyennes sur le même compte en une heure, ça pèse plus que chacune toute seule. C’est souvent ça qui trahit, pas l’événement isolé.

Si on ne sait pas dire pourquoi c’est 82

Sur le terrain

Ce que ça donne dans la file

Une dizaine d’entités, plus 600 lignes

Après le scoring dans ARTEFACT, l’analyste ouvre une dizaine d’entités, pas 600 alertes dans l’ordre d’arrivée. Les basses priorités restent là. On peut les interroger. Elles continuent de compter pour l’accumulation. Le poste stagiaire qui enchaîne douze signaux faibles remonte. En chrono, ça disparaît dans le flux.

File chronologiqueFile par risk_score
Ce que voit l’analyste600 alertes du jour, à plat~10 entités, contexte agrégé
Faux positifsUn par un, ou ignorés en blocDescendus dans la file, règle marquée pour tuning
Signal faible répétéNoyéRemonte par cumul
CouvertureRègles coupées pour tenirRègles gardées, pondérées

La file doit rester discutable

Arriver sur une file déjà rangée, c’est le but. Encore faut-il que l’analyste puisse contester chaque facteur. Sinon c’est un autre tableau de bord qu’on n’ouvre plus.

Mise en œuvre

L’installer sans se brûler

Le scoring ne s’allume pas un lundi sur tout le parc. On le pose sur ce qui existe déjà.

Avant le premier chiffre

Sans inventaire d’actifs à peu près à jour, tout le monde pèse pareil. Sans un peu d’historique de faux positifs, la fiabilité reste à 1 partout. Ces deux trucs, même approximatifs, avant la formule.

Trois semaines pour voir si ça tient

Semaine 1 : les vingt règles les plus bruyantes, taux de faux positifs noté à la main. Semaine 2 : criticité haute / moyenne / basse sur les actifs que le SIEM voit vraiment, pas ceux du CMDB que plus personne ne met à jour. Semaine 3 : file triée à côté de la chrono. On n’éteint pas l’ancienne. Le jour où l’équipe clique d’abord sur la file triée, on range l’autre.

Les limites

Ce que le score ne fera pas

Mal compris, c’est juste un nouvel objet qu’on ignore.

Une règle pourrie reste pourrie

Le score descend le bruit dans la file. Il ne retune rien. Une règle qui tire à blanc tous les matins, on la corrige ou on la retire. La laisser cachée par le score, c’est de la dette. Et ça pourrit l’accumulation : si la moitié des signaux faibles sont du théâtre, le cumul ne veut plus rien dire.

82 n’est pas un ordre de couper

C’est « regarde ça en premier ». Observer, contenir, escalader : ça reste dans le playbook, avec un critère qu’on peut lire. Si le chiffre décide tout seul, on automatise la panique. Si on s’en sert pour se rassurer, l’attaquant avance pendant qu’on regarde un 40.