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

Face à ce mur, la réaction classique est de désactiver des règles. C'est la mauvaise variable : on réduit le bruit en créant des trous de couverture. La bonne variable n'est pas quelles alertes produire mais dans quel ordre les présenter.

Un score utile est composite. Aucun facteur seul ne suffit :

• ✓Gravité de la technique : une énumération de partages ne pèse pas comme un dump de credentials. Le mapping ATT&CK de la règle donne cette pondération gratuitement.
• ✓Criticité de l'actif : la même alerte sur un poste stagiaire ou sur le contrôleur de domaine ne raconte pas la même histoire. Sans référentiel d'actifs, pas de score, c'est le prérequis.
• ✓Fiabilité historique de la règle : une règle qui a produit 200 faux positifs ce trimestre voit son poids baisser automatiquement, au lieu d'être désactivée à la hache.
• ✓Accumulation par entité : trois alertes moyennes sur le même compte en une heure valent plus que leur somme. C'est l'accumulation qui trahit une attaque réelle, rarement l'alerte isolée.

Sur le parc évoqué plus haut, après mise en place du scoring dans ARTEFACT, la file de travail de l'analyste s'ouvre sur une dizaine d'entités scorées, pas sur 600 alertes chronologiques. Les alertes basse priorité ne sont pas supprimées : elles restent interrogeables et continuent d'alimenter l'accumulation. Si le poste du stagiaire cumule douze signaux faibles, il remonte, et c'est exactement le scénario que le tri manuel rate.

La théorie du scoring tient en une phrase : on ne demande plus à l'humain de trouver l'aiguille, on lui présente la botte déjà triée. La pratique tient en une exigence : chaque facteur du score doit rester lisible et contestable par l'analyste.