Arrêtez de compter les alertes du SOC
#1 Pourquoi traiter 3 952 alertes par mois ne veux absolument rien dire
Vous avez externalisé votre SOC. Vous assistez aux comités, les indicateurs sont au vert. Mais vous n’êtes pas sûr que ça tourne bien. Ce numéro est pour vous.
“Mehdi, fais bien ressortir le nombre d’alertes pour montrer qu’on travaille bien au SOC.” C’est ce que m’a dit un jour mon RSSI dans un grand groupe français.
Je l’ai regardé d’un demi-œil. Il m’a regardé aussi. Je savais, il savait.
Alors j’ai acquiescé. J’ai sorti les chiffres. La slide a été présentée à la direction. Les chiffres sont parlants. Avec ça, on défend notre budget pour l’année prochaine.
Cette semaine-là, on avait raté un incident majeur qui aurait pu être détecté plus tôt. On ne manquait pas de monde. On ne manquait pas de savoir-faire. On était occupés à traiter le backlog.
C’est le problème fondamental des KPIs SOC tels qu’ils sont souvent présentés : on mesure ce qui est facile à comprendre pour un décideur. Pas ce qui compte vraiment.
Le piège du volume
Quand vous vous demandez “est-ce que le SOC fonctionne bien ?”, le réflexe naturel est de vous sortir un chiffre rassurant. 3 952 alertes traitées ce mois.
50 000 cette année. Les équipes sont occupées, tout va bien.
C’est un biais cognitif classique : on accorde de la valeur à ce qui est facile à voir et à compter. Le volume d’alertes ici, même s’il ne dit rien sur l’essentiel.
Car traiter beaucoup d’alertes (manuellement, j’entends), ça veut aussi dire que le SOC est sous pression constante. Que les analystes ferment des tickets en boucle sans jamais lever la tête. Et que les règles de détection génèrent tellement de bruit que les vrais signaux se noient dedans.
Le volume d’alertes mesure l’activité. Il ne mesure pas l’efficacité.
Cette confusion-là coûte cher.
Ce qu’il faut mesurer à la place
Voici les indicateurs que je regarde quand je veux vraiment évaluer la maturité d’un SOC. Pour savoir si le dispositif tient la route face à une vraie attaque.
Le taux de faux positifs
C'est le ratio entre les alertes qui ne mènent à rien et le total des alertes générées. Un taux élevé, c'est le signe que vos règles de détection sont mal calibrées. Et un SOC qui traite 80% de faux positifs finit par développer un réflexe dangereux : ses analystes ferment les alertes plus vite, avec moins d'attention.
C'est dans ce contexte que les attaques réelles passent inaperçues.
Le MTTD (Mean Time to Detect)
Combien de temps s’écoule entre le début d’une attaque et le moment où votre SOC la détecte ? C’est le KPI qui fait mal, parce que la réponse est souvent mauvaise. La moyenne mondiale dépasse 200 jours. DEUX CENT JOURS pendant lesquels un attaquant peut se déplacer latéralement dans votre réseau, exfiltrer des données, préparer une attaque élaborée.
Combien de temps se passe entre l’infection et la détection? Mesurez-le
Le ratio de revue des use cases
Un use case SOC, c’est un scénario d’attaque que votre équipe surveille activement. Une règle de détection associée à un comportement suspect précis. Le problème : ces règles vieillissent. Les environnements changent, les formats de logs évoluent, les techniques des attaquants aussi. Une règle jamais révisée devient progressivement inutile - un bout de code qui ne sert plus à grand chose.
Quel pourcentage de vos règles ont été revues ces six derniers mois ? Si la réponse est “on ne sait pas” ou “très peu”, c’est un signal d’alarme.
Le taux de détection sur scénarios simulés
C’est le test de réalité ultime. Lors d’un exercice red team, purple team ou pentest, est-ce que votre SOC voit ce que l’attaquant fait ? Détecte-t-il les mouvements latéraux, les tentatives d’escalade de privilèges, les exfiltrations simulées ?
Ce KPI est inconfortable parce qu’il expose vraiment les angles morts du SOC. Mais c’est précisément pour ça qu’il est utile. Perso, je préfère largement le découvrir lors d’un exercice contrôlé que lors d’un vrai incident.
Le nombre de threat huntings proactifs par mois
On parle ici d’investigation qui part d’une hypothèse, pas à la suite d’une alerte.
“Et si un attaquant était déjà dans notre SI en ce moment ? Où regarderions-nous ?”
“Et si il avait dump les credentials d’un admin AD. comment est-ce qu'on le saurait ?”
C’est une démarche proactive, structurée, qui demande du temps et de la compétence.
Un SOC qui ne fait jamais de threat hunting est un SOC purement réactif. Il attend que l’alarme sonne. Un SOC mature cherche avant que ça sonne.
Ce que ça change concrètement pour vous
Vous n’avez pas besoin de maîtriser ces indicateurs dans le détail. Mais vous avez besoin de les poser sur la table lors de votre prochain comité. C’est eux les experts après tout.
Posez simplement ces deux questions : “Quel est notre MTTD actuel, et comment il évolue ?” “Quel pourcentage de nos use cases ont été révisés ces six derniers mois ?”
S’ils ne savent pas répondre, vous avez votre réponse sur l’état de votre SOC.
Mehdi Charki est SOC Manager avec 10 ans d’experience. SOC Performance est sa newsletter indépendante sur la gouvernance, stratégie et pilotage SOC.