Vers une simplification de la priorisation dans un SOC?


Vers une simplification de la priorisation dans un SOC?

La priorisation des incidents dans les SOC reposent sur une classification souvent trop complexe, n'aidant ni au pilotage, ni à la bonne priorisation.

Publié le 17/05/2025 par Stefan THIBAULT

SOC Process Ingénierie de détection

1 min de lecture

Dans la gestion des alertes, et des incidents qui en découlent, on observe dans la plupart des SOCs au moins 4 niveaux (P1 à P4, ou Critique/Majeur/Modéré/Faible…), parfois plus (on m’a déjà présenté une échelle à 10 niveaux…), utilisés pour représenter un degré de priorité de traitement par les équipes de cyberdéfense. Cette logique se retrouve dès la source des alertes, puisque les outils de détection disposent aussi de leur propre classement.

Mais ce mode de gestion entraine des biais qu’on observe très fréquemment :

  • le premier niveau de priorité est généralement réservé aux incidents qui doivent vous réveiller la nuit (déclencher les astreintes), et n’est donc positionné que face à des cas bien précis et rares,
  • le deuxième niveau de priorité contient toutes les alertes qui pourraient indiquer un incident grave (et il est souvent trop rempli, avec tous les cas qui nécessitent une levée de doute auprès d’un utilisateur ou administrateur),
  • les niveaux suivants ne sont traités que quand on a le temps : autrement dit, jamais traités ou clôturés à la chaine pour éviter le rouge dans le reporting.

Alors que la plupart des équipes convergent vers des outils fonctionnant en “Risk Based Alerting”, qui feront remonter un score de risque si plusieurs alertes concernent un même objet, est-il pertinent de garder autant de niveaux ?

On pourrait par exemple imaginer se limiter à deux niveaux :

  • P1. les urgences (compromissions avérées dont le traitement n’est pas automatisé ou alertes nécessitant une levée de doute immédiate),
  • P2. les comportements à investiguer obligatoirement sous un court délai,
  • Les autres alertes seraient alors de l’information pertinente pour du hunting visant à créer de nouvelles règles fiables, ou des événements raccrochés à un incident plus large dans les deux catégories précédentes.

Ce changement d’approche aiderait à limiter la charge d’analyse de tickets pour libérer du temps de hunting et d’amélioration continue. Le suivi du niveau de service, de la charge de l’équipe et de l’apport des actions visant à limiter les faux positifs par une meilleure qualité de données et de règles en serait également facilité.