Couverture MITRE ATT&CK : votre vrai chiffre est plus bas que celui de votre dashboard

Presque toutes les équipes sécurité affichent un pourcentage de couverture MITRE ATT&CK, et ce chiffre tient lieu à lui seul de posture de détection. Presque tous ces pourcentages sont flatteurs. Pour son rapport 2025 State of SIEM Detection Risk, CardinalOps a analysé les métadonnées de configuration de SIEM en production : des détections pour 21 % des techniques MITRE ATT&CK, sur des parcs où les données déjà collectées auraient permis d'en couvrir 90 %. Le même rapport constate que 13 % des règles réellement présentes étaient cassées, sans que personne le sache.

Ce n'est donc pas un problème de données. C'est l'écart entre ce que compte un dashboard de couverture et ce qui se déclencherait vraiment un mardi ordinaire.

Si vous ne retenez qu'une chose : un pourcentage de couverture compte presque toujours les règles mappées sur une technique, jamais les règles dont on a prouvé qu'elles se déclenchent dessus. Le mapping est un exercice de tableur. Le déclenchement, lui, dépend de la télémétrie qui arrive, des champs qui correspondent, des exclusions qui ne se sont pas élargies en silence, et de quelqu'un pour s'en apercevoir quand elles le font. Le mapping se publie facilement. Le déclenchement, c'est ce que rencontre l'attaquant.

Ce que mesure vraiment un pourcentage de couverture MITRE ATT&CK

Un seul chiffre recouvre trois questions différentes, et elles divergent d'autant plus que le parc tourne depuis longtemps.

La première question donne le chiffre que l'on cite en comité de direction. La deuxième est un travail de detection engineering. La troisième relève du premier tri et de l'escalade, et c'est elle qui décide si la détection valait la peine d'être écrite. Une technique dont la règle part dans une file que personne ne traite est couverte exactement comme un détecteur de fumée sans pile est installé.

Compter les règles au lieu des techniques aggrave encore le biais. Six règles sur le vol d'identifiants, cela fait une technique couverte, pas six ; et un dashboard qui additionne les règles flattera un portefeuille très fourni sur deux tactiques et vide sur cinq.

Pourquoi une règle de détection morte reste au vert

C'est le constat sur lequel il faut s'arrêter. Une règle morte ne se signale pas, parce que dans une stack de détection la panne et le fonctionnement normal produisent exactement la même sortie : rien.

Une règle cesse de fonctionner pour des raisons banales, dont aucune ne ressemble à un incident sur le moment.

• Une source cesse d'émettre. Un collecteur est décommissionné, un forwarder ne repart pas après un reboot, un abonnement expire.
• Un champ est renommé. Une montée de version ou un changement de schéma déplace l'attribut sur lequel la règle s'appuie, et la requête ne remonte plus rien au lieu de lever une erreur.
• Une exclusion s'élargit. Quelqu'un fait taire un chemin de faux positifs pendant une semaine chargée, le filtre est plus large que prévu, et la règle ne survit plus que de nom.
• Un changement d'index ou de rétention déplace les données hors de portée de la recherche.
• Un parser change de forme : les valeurs sont toujours là, mais plus dans le format que la règle attend.

Chacune de ces pannes laisse une règle activée, mappée, au vert sur la vue de couverture — et morte. Une règle qui n'a rien déclenché depuis quatre-vingt-dix jours surveille une technique que personne n'a employée contre vous, ou bien elle a lâché, et aucun outillage standard ne permet de distinguer les deux. La différence se paie en dwell time. C'est pour cela que les 13 % de CardinalOps sont plus inquiétants que les 21 % : une couverture de 21 %, c'est un trou que vous connaissez, alors que 13 % de règles cassées, c'est un trou que vous êtes déjà persuadé d'avoir bouché.

Pourquoi brancher plus de données ne fait pas bouger le chiffre

Le réflexe, devant une couverture faible, est de raccorder une source de logs de plus. Le constat de CardinalOps dit exactement l'inverse : les données déjà ingérées permettraient de détecter 90 % des techniques. La contrainte, c'est la capacité de detection engineering, pas la collecte.

Cela compte, parce que l'ingestion est précisément ce que votre plateforme vous facture, et l'écriture de règles ce qu'elle ne facture pas. Un programme de raccordement piloté par la couverture produit invariablement une facture plus lourde et à peu près le même pourcentage : la nouvelle source arrive sans aucun use case écrit dessus, sans mapping de champs validé, et sans que personne soit libéré pour faire l'un ou l'autre. Brancher des sources, c'est le geste visible. Prouver que ce que vous collectez déjà sert réellement à quelque chose, c'est celui qui fait bouger le chiffre.

Comment auditer votre propre couverture MITRE ATT&CK

Vous pouvez en produire une version défendable en une après-midi, sans rien acheter.

1. Exportez le mapping et comptez des techniques, pas des règles. Une technique couverte par six règles compte pour une. Le résultat est votre plafond, et attendez-vous à ce qu'il soit nettement en dessous du chiffre de votre dernier reporting.
2. Mettez une date de dernier déclenchement en face de chaque règle activée. Triez par ordre croissant. Tout ce qui est silencieux depuis un trimestre passe sur une liste de suspects — pas condamné, simplement plus présumé en état de marche.
3. Vérifiez que la télémétrie dont dépend chaque règle arrive toujours, et dans le format que la règle attend. C'est ce qui attrape les renommages et les défauts de parser, les plus silencieux des cinq ci-dessus.
4. Testez un échantillon. Quelques atomic tests sans danger par tactique, joués délibérément, vous apprendront plus que n'importe quel exercice de mapping. Déclenchez-les, et vérifiez qu'une alerte arrive vraiment dans la file N1.
5. Relisez vos exclusions avec les yeux d'un attaquant. Chacune est un moyen documenté de passer inaperçu ; certaines devaient être temporaires.
6. Consignez les techniques que vous ne pouvez pas couvrir, et pourquoi. Un angle mort assumé et documenté vaut mieux qu'un voyant vert qui ment ; les auditeurs et les régulateurs le prennent bien mieux, et celui qui héritera du parc aussi. Il donne aussi un point de départ à la chasse aux menaces.

Faites-le une fois, et vous aurez un vrai chiffre de couverture MITRE ATT&CK. Il sera plus bas que le précédent et il vaudra quelque chose : vous perdez des points, vous gagnez un chiffre vrai.

La couverture est un plancher, pas une ligne d'arrivée

Arrive alors le second problème, celui qui fait caler les projets de couverture à mi-parcours : chaque technique que vous couvrez pour de bon ajoute du volume à un backlog que quelqu'un doit encore corréler à la main. L'étude State of the SOC 2026 de Microsoft et Omdia, commanditée par un éditeur, estime que la corrélation manuelle consomme près d'un cinquième de la capacité hebdomadaire dans deux tiers des SOC. Améliorer la détection sans améliorer la décision ne vous donne que davantage de preuves que personne n'a le temps de lire.

C'est sur cette couche que travaille Seculogik. Elle se place au-dessus de la stack de détection que vous exploitez déjà — Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, Cortex XDR, Elastic, OpenSearch, ClickHouse, Wazuh, ou un connecteur que nous développons si le vôtre manque — et transforme ce qui se déclenche en une courte liste de dossiers qualifiés, chacun avec un verdict, le raisonnement qui l'explique, une échéance et un responsable.

Neuf contrôles indépendants examinent chaque alerte et doivent s'accorder sur un seul verdict, et le dossier garde le raisonnement. Le détail est sur la page du moteur de corrélation, et la raison pour laquelle cette couche est la partie difficile est développée dans pourquoi le moteur de corrélation est notre joyau.

Ce que nous apportons sur le problème de couverture

Deux choses, volontairement peu spectaculaires.

72 packs de détection mappés MITRE, importables depuis un écran. Ils sont livrés avec chaque édition, Free comprise : un parc qui démarre dispose donc d'une vraie couverture de techniques dès le premier jour, au lieu d'un jeu de règles vide et d'un trimestre de detection engineering. Vous voyez quelle technique chaque pack traite avant de l'importer, ce qui rend votre chiffre de couverture traçable dès le départ.

Une couche de verdict qui rend les alertes dignes d'être produites. Les alertes deviennent des dossiers, les dossiers portent un verdict et un responsable, et la file est classée selon ce qu'un dossier est devenu, pas selon la façon dont il a commencé. Notre analyste IA, SIROC, expose ses hypothèses et les argumente ouvertement, et chaque preuve qu'il cite est recoupée avec les alertes du dossier lui-même. La position officielle de Gartner est qu'il n'y aura jamais de SOC autonome ; nous la partageons. Ce que nous livrons, c'est une autonomie encadrée : toute action destructrice s'arrête à une validation avant action, avec un humain derrière.

Un peu d'honnêteté, puisque c'est la même discipline que l'audit ci-dessus. Nous sommes en pré-GA. Aucun client à citer, aucune qualification ANSSI ou CSPN, aucun rapport de pentest tiers, aucun SLA. Nous ne publions aucun chiffre de précision de détection qui nous soit propre : les chiffres de ce texte sont ceux de CardinalOps et d'Omdia, et nous vous avons dit qui les a mesurés et comment.

Par où continuer

Si votre chiffre de couverture n'a jamais été audité, auditez-le avant d'acheter quoi que ce soit. S'il l'a été, et que la conclusion était que vos détections partent correctement mais que vos analystes ne suivent toujours pas, c'est exactement le problème pour lequel Seculogik a été conçu. Commencez par la présentation de la plateforme, regardez quelle édition correspond à votre parc, ou demandez une démonstration en apportant une semaine de vos propres alertes.