Pourquoi MTTD et MTTR biaisent la sécurité

Éditorial

Le MTTD et le MTTR valorisent les incidents détectés et traités, mais masquent structurellement ceux qui restent invisibles.

~11 min de lecture8 sections

Pourquoi MTTD et MTTR biaisent la sécurité

Le MTTD (Mean Time To Detect, temps moyen de détection) et le MTTR (Mean Time To Respond, temps moyen de réponse) dominent les tableaux de bord sécurité parce qu’ils donnent deux nombres propres, descendants et présentables. Le problème n’est pas leur calcul : il est dans la population qu’ils excluent. Un incident non détecté ne dégrade jamais le MTTD, ce qui est une étrange façon de mesurer une capacité de détection.

Explication de la marmotte

Mesurer seulement les incendies éteints rapidement ne dit pas combien de départs de feu restent cachés derrière les murs. Ces chiffres servent à raconter que les secours vont vite, mais pas à vérifier que le bâtiment est réellement surveillé.

→ Lire l’explication complète de la marmotte

MTTD et MTTR : des moyennes construites sur les survivants

Le MTTD mesure généralement l’écart entre le début estimé d’un incident et sa détection. Le MTTR mesure ensuite l’écart entre cette détection et un état considéré comme rétabli. Déjà, le vocabulaire triche un peu : dans certains rapports, le second R signifie response, dans d’autres remediation, recovery ou resolve. Ces durées ne couvrent pas les mêmes opérations. Comparer deux MTTR sans définition opérationnelle commune revient à comparer la vitesse d’un train avec le temps de cuisson d’un gratin.

Le défaut central est plus profond : ces métriques sont conditionnelles. Elles portent sur les incidents connus, parfois même uniquement sur les incidents fermés. Soit un ensemble réel d’intrusions $I$, et un sous-ensemble détecté $D$. Le MTTD observé est calculé sur $D$, pas sur $I$. Lorsque la détection baisse, le dénominateur se réduit. Une organisation peut donc afficher un meilleur MTTD après avoir perdu de la visibilité sur ses postes, ses identités ou ses flux chiffrés. La moyenne s’améliore pendant que l’exposition augmente. Mathématiquement valide, opérationnellement grotesque.

Cette sélection produit aussi un biais de gravité. Les ransomwares bruyants, les indisponibilités et les alertes à haute confiance sont détectés vite parce qu’ils cassent quelque chose de visible. Les accès persistants par jeton de session, les abus de comptes légitimes, l’exfiltration lente et les modifications discrètes de politiques d’identité restent plus longtemps hors échantillon. Or ce sont précisément les scénarios où la durée de présence d’un attaquant compte.

Une médiane réduit l’effet des incidents extrêmes, mais ne corrige pas ce biais de sélection. Un percentile à 95 % documente mieux la queue de distribution, pas les événements absents. Changer la formule ne ressuscite pas les morts administratifs. La métrique devient honnête seulement si son périmètre est écrit : sources de détection incluses, événements exclus, horodatage de départ, règle de clôture et proportion d’incidents validés par une source externe.

Pourquoi les conseils d’administration aiment ces chiffres

Le MTTD et le MTTR se sont imposés parce qu’ils donnent l’illusion d’une chaîne causale rassurante : détecter plus vite, répondre plus vite, réduire l’impact. Cette relation existe, mais seulement après détection et seulement lorsque la réponse est correcte. Une détection rapide suivie d’une révocation incomplète laisse l’accès actif. Une restauration rapide depuis une sauvegarde compromise remet l’attaquant au travail avec une ponctualité admirable.

Ces métriques ont trois avantages politiques. Elles sont calculables depuis un outil de gestion des alertes, elles évoluent chaque mois, et elles permettent un graphique à flèche verte. Elles répondent donc parfaitement à la demande institutionnelle d’un indicateur stable. La sécurité, elle, n’est ni stable ni propre : les capteurs changent, les règles changent, les adversaires changent de technique et les journaux disparaissent quand la capacité de stockage a été sous-dimensionnée.

Le compromis central est là : le MTTD et le MTTR offrent une mesure de pilotage peu coûteuse, mais paient cette commodité par une invisibilité structurelle des échecs de détection. Il faut les conserver comme métriques de fonctionnement du centre opérationnel de sécurité, jamais comme preuve de maturité globale. Les présenter seules au conseil d’administration revient à évaluer un guichet sur le délai de traitement des dossiers déjà enregistrés, sans demander combien d’usagers repartent faute d’avoir trouvé l’entrée.

La recommandation est donc nette : publier le MTTD et le MTTR avec un indicateur explicite de couverture de détection et avec des résultats d’exercices contrôlés. Sans cette paire, ces durées décrivent l’efficacité du traitement des alertes, pas l’efficacité de la sécurité.

La page sur l’observabilité en architecture cyber apporte le cadre nécessaire : une métrique dépend d’abord de la qualité, de la disponibilité et de l’intégrité des signaux collectés. Un tableau de bord n’observe pas le système, il observe les traces que le système a bien voulu conserver.

Les incidents invisibles faussent la mesure de maturité

Il est impossible de compter exhaustivement les intrusions non détectées en temps réel. Cette limite n’autorise pas à faire comme si elles n’existaient pas. Une estimation imparfaite mais instrumentée vaut mieux qu’une moyenne impeccable construite sur un angle mort.

La première source d’estimation est la validation indépendante. Les exercices d’émulation d’adversaire doivent mesurer, pour chaque technique testée, la télémétrie générée, l’alerte créée, le délai de qualification et la qualité de la réponse. Une simulation qui déclenche uniquement des signatures connues mesure l’outillage de démonstration, pas la résistance. Les scénarios doivent couvrir les identités, les postes, les environnements cloud, les flux d’administration et les mouvements latéraux.

La seconde source est la réconciliation. Comparer les journaux d’authentification, les événements d’administration, les flux réseau et les traces applicatives révèle des divergences. Un compte ayant accédé à une ressource sensible sans événement correspondant dans l’outil de surveillance n’est pas automatiquement une compromission. C’est une dette de visibilité jusqu’à preuve du contraire. Une architecture qui ne peut pas croiser ces sources ne peut pas distinguer une absence d’attaque d’une absence de capteur.

La troisième source est l’investigation rétrospective. Après une compromission confirmée, il faut recalculer le temps de présence à partir du premier artefact fiable, puis rechercher les signaux qui existaient déjà. Cette analyse doit alimenter une mesure de taux de détection rétrospective : parmi les événements désormais identifiés comme malveillants, quelle part avait produit un signal exploitable, une alerte, une alerte qualifiée, puis une action correcte ? Mesurer seulement la première alerte finale masque toute la chaîne ratée avant elle.

L’identité mérite une attention particulière. Une authentification réussie avec des identifiants valides ne prouve rien sur l’intention de son détenteur. Les compromis de session, les délégations abusives et les élévations de privilèges discrètes imposent une surveillance des changements d’autorisation, des créations de secrets et des usages administratifs atypiques. Les mécanismes décrits dans le durcissement de NTLM rappellent la règle : un protocole ancien conservé par compatibilité élargit la zone où les signaux deviennent ambigus.

Un exemple de calcul qui expose le biais

Un export d’incidents peut calculer un MTTD sans difficulté. Le résultat reste utile pour suivre une équipe, à condition de ne pas le vendre comme une mesure de protection.

# incidents.csv contient uniquement les incidents confirmés et détectés.
# Les dates sont en UTC au format ISO 8601.
import csv
from datetime import datetime, timezone

delais_heures = []

with open("incidents.csv", newline="", encoding="utf-8") as fichier:
    for incident in csv.DictReader(fichier):
        debut = datetime.fromisoformat(incident["started_at"]).astimezone(timezone.utc)
        detecte = datetime.fromisoformat(incident["detected_at"]).astimezone(timezone.utc)
        delais_heures.append((detecte - debut).total_seconds() / 3600)

mttd = sum(delais_heures) / len(delais_heures)
print(f"MTTD observé : {mttd:.1f} heures")
# Ne mesure pas les intrusions absentes du fichier, donc jamais détectées.

Le commentaire final est la partie la plus coûteuse du programme. Le fichier contient une décision humaine ou automatisée ayant déjà déclaré l’incident détecté. Une compromission découverte des mois plus tard peut être ajoutée rétroactivement, mais les intrusions encore inconnues resteront absentes. Aucun traitement statistique ne les inventera.

Pour éviter les comparaisons frauduleuses, conserver aussi le nombre de sources actives, le taux de couverture des actifs critiques, la durée de rétention, le volume d’événements rejetés et le taux d’échec de collecte. Une baisse du MTTD accompagnée d’une baisse de la couverture n’est pas une amélioration. C’est un voyant vert débranché.

Conditions d’exploitation des métriques de détection

Les horodatages doivent être synchronisés par une source de temps fiable. Sans synchronisation, l’ordre entre exécution, journalisation et alerte devient incertain. Une dérive de quelques minutes suffit à fausser une enquête automatisée ; une dérive plus longue transforme le MTTD en fiction comptable.

Les journaux doivent être protégés contre l’altération par un compte compromis. Envoyer les événements vers un stockage séparé, appliquer des droits d’écriture minimaux et conserver une rétention adaptée aux temps de présence plausibles sont des prérequis. Une collecte centralisée sans isolation d’administration concentre surtout un futur point de suppression. Le silence d’un collecteur doit lui-même déclencher une alerte, avec une procédure de vérification hors bande.

La rotation des secrets d’ingestion, des certificats et des comptes de service mérite le même niveau de discipline que les identités de production. Un agent de collecte doté de privilèges excessifs devient un canal d’administration déguisé en télémétrie. Les clés de signature ou de chiffrement des journaux doivent être sauvegardées avec leurs métadonnées de rotation ; perdre la capacité à vérifier l’intégrité historique revient à conserver des cartons fermés sans savoir qui les a remplis.

Enfin, définir une restauration testée des plateformes de journalisation et de gestion des incidents. Lors d’une attaque, l’outil de supervision peut être chiffré, saturé ou volontairement aveuglé. La reprise doit préciser quelles données restaurer, quels comptes casser, quelles intégrations désactiver temporairement et comment conserver les éléments de preuve. La gouvernance de la sécurité commence ici : une métrique sans propriétaire, définition versionnée et seuil de dégradation est juste un chiffre qui attend sa prochaine slide.

Une mesure de maturité qui résiste aux angles morts

Une évaluation honnête doit séparer quatre dimensions. La première est la couverture : part des actifs, identités, interfaces d’administration et chemins de données produisant une télémétrie exploitable. La deuxième est l’efficacité de détection : part des techniques testées qui produisent une alerte qualifiée dans un délai défini. La troisième est la qualité de réponse : capacité à contenir, éradiquer et rétablir sans laisser les accès de persistance en place. La quatrième est la résilience : capacité à enquêter et à reprendre lorsque les outils habituels sont indisponibles.

Le MTTD et le MTTR restent dans la troisième dimension, avec un peu de la deuxième selon la définition retenue. Ils ne remplacent ni le taux de détection lors d’exercices, ni la couverture des actifs critiques, ni le délai de découverte rétrospective, ni la proportion d’alertes sans données suffisantes pour enquêter.

Le bon tableau de bord montre donc des tensions plutôt qu’une seule courbe flatteuse : délai médian de détection, taux de détection par scénario, couverture de collecte, délai de confinement, taux de rechute, durée de rétention et résultats de restauration. Cette pluralité coûte plus cher à produire et plus de temps à expliquer. C’est précisément son mérite. Une sécurité mature n’est pas celle qui trouve vite ce qu’elle voit ; c’est celle qui sait démontrer ce qu’elle ne voit pas encore, et réduire méthodiquement cette zone.

🐝 Ce qui arrive si on s’en passe

Sans indicateur de couverture publié à côté du MTTD et du MTTR, les arbitrages budgétaires se retournent contre la collecte : un capteur coûteux supprimé, une rétention raccourcie ou un flux chiffré non déchiffré améliorent les deux courbes, et le financement suit la courbe, pas la visibilité. La pression sur le délai de réponse encourage aussi des clôtures anticipées et des requalifications en faux positif, ce qui efface du registre des cas qui auraient dû être investigués. Un attaquant opérant par jetons de session valides ou par délégation abusive profite alors d’une zone où l’absence d’alerte est lue comme absence d’attaque. Enfin, les engagements contractuels et les déclarations d’assurance adossés à ces seules durées deviennent invérifiables : sans traces conservées ni horodatage fiable, la reconstitution du temps de présence après coup n’est plus démontrable.

🦫 Explication de la marmotte 🍫

Le temps moyen de détection mesure le délai entre le début connu d’une attaque et le moment où une alerte la signale. Le temps moyen de réponse mesure ensuite le délai nécessaire pour arrêter l’attaque et remettre les systèmes dans un état accepté. Pour calculer ces nombres, il faut des dates enregistrées dans les outils de surveillance et dans les dossiers d’incident.

Le défaut apparaît avant le calcul : une attaque qui n’est jamais repérée n’a ni date de détection ni dossier. Elle n’entre donc pas dans la moyenne. Si un système repère moins d’attaques, il peut afficher un meilleur résultat parce qu’il ne compte plus que les cas les plus visibles. Ce résultat ne prouve pas qu’il est mieux protégé.

Il faut donc mesurer autre chose en parallèle. Des tests contrôlés vérifient si des actions dangereuses créent des alertes. La comparaison de plusieurs journaux montre si certains accès ou changements ne sont suivis nulle part. Après la découverte d’une attaque, une enquête recherche les traces plus anciennes pour savoir ce qui aurait pu être vu plus tôt.

Ces mesures ne suppriment pas l’incertitude. Elles montrent où elle se trouve. Il faut aussi protéger les journaux, conserver les données assez longtemps, synchroniser les horloges et préparer la remise en route des outils de surveillance. Le temps de détection et le temps de réponse restent nécessaires, mais ils décrivent seulement le traitement des attaques déjà connues.

À lire aussi

• SOC centre des opérations de sécurité : rôle, organisation, mesureCe qu'est un SOC (centre des opérations de sécurité), comment il s'organise, quel modèle choisir et comment juger s'il détecte vraiment les attaques.
• Pourquoi un analyste SOC rate une alerte critiqueCharge cognitive en SOC : comprendre pourquoi une alerte critique échappe à l’analyste et comment concevoir une détection exploitable.
• Pourquoi la dernière heure de garde échoueLa fatigue de vigilance rend la dernière heure de garde dangereuse et impose des contrôles d’exploitation qui ne reposent pas sur la mémoire humaine.
• Comment mener un exercice de simulation d'incidentGuide pratique pas-à-pas pour préparer, animer et capitaliser un exercice de simulation d'incident avec une équipe technique.

Pages voisines

La citent

• Calculer le coût-bénéfice d’un incident évité
• SOC centre des opérations de sécurité : rôle, organisation, mesure

Pourquoi MTTD et MTTR biaisent la sécurité

Elle cite

• ⇄Lien dans les deux sens :Quels indicateurs mesurer pour la sécurité
• Détecter la persistance d’un attaquant après incident
• NTLM : protocole authentification LAN Manager New Technology Microsoft
• Reconstruire une timeline d'attaque après incident

⇄ : les deux pages se citent l’une l’autre.