Aller au contenu

Quels indicateurs mesurer pour la sécurité

Un indicateur de sécurité ne vaut que s’il déclenche une décision vérifiable : corriger, isoler, financer, accepter ou transférer un risque. Compter des alertes, des formations suivies ou des vulnérabilités ouvertes produit surtout une impression de contrôle, ce qui est une denrée abondante dans les tableaux de bord.

→ Lire l’explication complète de la marmotte

Indicateurs de sécurité : mesurer une décision, pas une activité

Section intitulée « Indicateurs de sécurité : mesurer une décision, pas une activité »

Le compromis central oppose la fidélité au risque et le coût de mesure. Un indicateur très précis exige des données complètes, rapprochées et contrôlées, donc de l’intégration, de l’exploitation et des arbitrages. Un indicateur bon marché couvre souvent un périmètre flou et se laisse manipuler. La recommandation est de retenir peu d’indicateurs, liés à des décisions de risque explicites, puis d’investir dans leur qualité de données.

Un indicateur exploitable répond à quatre questions :

  1. Quel actif, service ou processus est concerné ?
  2. Quel événement redouté cherche-t-on à réduire ?
  3. Quelle action doit être prise si le seuil est dépassé ?
  4. Qui est responsable de cette action et dans quel délai ?

Sans quatrième réponse, le graphique est un meuble. Très lumineux, parfois animé, mais un meuble.

Le nombre total de vulnérabilités est un indicateur de façade classique. Il mélange postes abandonnés, composants non exposés, failles critiques exploitables et faux positifs. Il incite à fermer des tickets, pas à réduire une voie d’attaque. À l’inverse, la proportion d’actifs exposés à Internet portant une vulnérabilité activement exploitée, corrigée dans le délai défini par criticité, relie une exposition à une action.

La mesure doit partir d’un scénario de risque. Pour une compromission d’identité, on mesure par exemple la couverture de l’authentification multifacteur résistante à l’hameçonnage sur les comptes à privilèges, le délai de révocation des accès après un départ, et la part des comptes de service sans propriétaire identifié. La page sur les identités fournit le cadre technique qui manque souvent à ces chiffres : un compte n’est pas une identité, et une identité n’est pas automatiquement un droit justifié.

Un seuil n’est pas une cible décorative. Il doit être issu d’une capacité de détection, d’un délai de correction tolérable et de l’impact métier. Fixer « 95 % des correctifs critiques sous 30 jours » sans distinguer les actifs accessibles depuis Internet des environnements isolés revient à annoncer que tous les incendies seront traités avec le même seau.

Couverture, délai et efficacité : les trois familles qui comptent

Section intitulée « Couverture, délai et efficacité : les trois familles qui comptent »

Les indicateurs de couverture vérifient qu’un contrôle existe là où il doit exister. Ils se calculent sur un dénominateur inventorié et versionné. Exemple : nombre de charges de travail disposant d’une journalisation exploitable, divisé par le nombre total de charges de travail en production. Le dénominateur ne doit jamais provenir du même outil que le numérateur : sinon, tout actif oublié devient miraculeusement conforme.

Les indicateurs de délai mesurent le temps entre deux événements datés. Le délai moyen de détection, souvent nommé MTTD (Mean Time To Detect), est moins informatif que des percentiles. Une moyenne de quatre heures peut masquer des intrusions détectées après trente jours. Mesurer le 50e, le 90e et le 95e percentile par catégorie d’incident permet de voir la queue longue, celle qui finit dans un rapport d’incident avec beaucoup trop de captures d’écran.

Les indicateurs d’efficacité vérifient que le contrôle bloque ou détecte réellement l’événement attendu. Le taux de succès d’exercices de restauration, le taux de détection d’une élévation de privilèges simulée ou la part des certificats renouvelés avant expiration sont meilleurs que la seule présence d’un produit. Un agent déployé mais muet est un indicateur de couverture positif et un contrôle de sécurité négatif. Les deux peuvent être vrais simultanément, ce qui agace les présentations trimestrielles.

Pour chaque famille, conserver un indicateur de qualité de mesure : taux d’actifs sans source de vérité, proportion d’événements sans horodatage fiable, nombre de sources ayant cessé d’émettre. Un taux de conformité de 99 % calculé sur 60 % du parc ne décrit pas une posture. Il décrit un angle mort avec deux décimales.

La modélisation des scénarios doit s’appuyer sur les menaces et sur l’architecture réelle : flux, dépendances, identités techniques, données et frontières d’administration. Une métrique transversale n’a de valeur que si ces relations sont connues. Sinon, elle mesure l’application d’une politique, pas l’exposition effective.

La loi de Goodhart énonce qu’une mesure cesse d’être une bonne mesure lorsqu’elle devient une cible. En sécurité, le phénomène est brutal : imposer un taux de clôture de tickets conduit à requalifier les tickets, à réduire leur sévérité ou à exclure les actifs pénibles. La menace, elle, ne lit pas les règles de gestion.

Les indicateurs suivants demandent une méfiance immédiate :

  • Nombre d’alertes bloquées : il dépend des règles, du bruit et du périmètre observé. Une baisse peut signaler une meilleure prévention ou une sonde cassée.
  • Pourcentage de collaborateurs formés : il mesure la présence à une formation, pas la résistance à une fraude ni la capacité de signalement.
  • Nombre de vulnérabilités corrigées : il favorise les correctifs faciles et laisse les dépendances critiques, anciennes et exposées au fond du panier.
  • Score global unique : il agrège des réalités incomparables dans une couleur rassurante. Le rouge devient orange, l’orange devient une stratégie.
  • Conformité déclarative : une case cochée ne prouve ni l’application du contrôle, ni son maintien, ni sa résistance à un contournement.

Un indicateur peut rester imparfait et demeurer nécessaire. Le taux de formation est utile pour piloter une obligation de déploiement, à condition de ne pas le vendre comme une mesure de réduction de fraude. La question décisive est : « quelle hypothèse sur le risque ce nombre teste-t-il ? ». Si aucune hypothèse ne survit à cette question, supprimer le nombre.

Les métriques ne remplacent pas une analyse de risque. La directive NIS2 (Network and Information Security 2) impose une gestion des risques, pas un culte du feu tricolore. Une démarche EBIOS RM (Expression des Besoins et Identification des Objectifs de Sécurité Risk Manager) permet de rattacher les indicateurs aux scénarios redoutés, aux sources de risque et aux mesures de sécurité. Cela évite de mesurer avec ferveur ce qui est facile à extraire d’une console.

Exemple : calculer un délai de correction exploitable

Section intitulée « Exemple : calculer un délai de correction exploitable »

Le délai de correction doit être calculé depuis la première détection fiable jusqu’à la date de correction vérifiée, pas jusqu’à la fermeture administrative. Le calcul part d’un export des constats de sécurité, écarte tout ce qui fausserait la mesure, puis résume les délais retenus par des percentiles plutôt que par une moyenne, qu’un seul cas extrême suffit à déformer.

Calcul du délai de correction en quatre temps. Les constats exportés passent trois filtres : l'actif est-il exposé ? La correction est-elle vérifiée, et pas seulement déclarée ou le ticket fermé ? Sinon, le constat est écarté de la mesure. Pour chaque constat retenu, le délai va de la correction vérifiée moins la première détection fiable ; une durée négative signale un problème d'horloge ou de donnée, à corriger à la source. Les délais sont triés et résumés par trois percentiles : p50, le délai typique, que la moitié des cas bat ; p90, les cas lents, un sur dix fait pire ; p95, la traîne, là où dort le risque. Si aucun constat n'est retenu, rien n'est mesuré et le tableau de bord ne doit afficher aucun chiffre.

Le p90 et le p95 comptent davantage que le p50 : un délai typique honorable peut masquer une poignée de vulnérabilités exposées qui restent ouvertes des mois, et ce sont elles qu’un attaquant trouve.

Ce calcul ne garantit pas que le correctif élimine l’exploitation. Il confirme uniquement une remise en conformité déclarée et vérifiée selon une règle définie. Une vulnérabilité peut rester exploitable après mise à jour si une configuration faible, une clé volée ou un accès persistant subsiste. La preuve d’efficacité doit venir de tests de contrôle, d’analyse de configuration ou de détection comportementale.

Surface d’attaque des tableaux de bord de sécurité

Section intitulée « Surface d’attaque des tableaux de bord de sécurité »

Les données de sécurité deviennent elles-mêmes une surface d’attaque. Un compte ayant le droit de modifier les étiquettes d’actifs, la criticité ou l’état d’un constat peut dégrader les indicateurs sans toucher au contrôle mesuré. La falsification silencieuse est plus dangereuse que l’absence visible de données.

Les contre-mesures minimales sont les suivantes :

  • séparer les droits de production des droits de modification des référentiels de mesure ;
  • journaliser les changements de périmètre, de criticité, de seuil et de règle de calcul ;
  • conserver les valeurs historiques recalculables avec la version de formule associée ;
  • comparer périodiquement l’inventaire de sécurité à des sources indépendantes, notamment gestion de configuration, annuaire et facturation d’infrastructure ;
  • alerter sur la disparition d’une source, pas seulement sur les valeurs qu’elle émet.

Les accès aux données brutes méritent le même traitement que les journaux d’administration. Ils révèlent fréquemment des noms de systèmes, des identifiants, des chemins d’accès et parfois des secrets malheureux. Chiffrer les sauvegardes, limiter les exports, tracer les consultations et appliquer une rétention documentée relèvent de l’exploitation normale, pas d’un supplément premium.

La rotation des jetons d’accès aux interfaces de collecte doit être automatisée. Un jeton de lecture omnipotent, oublié dans un outil de visualisation, offre une cartographie pratique à un attaquant. Les secrets de collecte doivent provenir d’un gestionnaire de secrets, disposer d’un propriétaire et être testés après rotation. Une sauvegarde de tableau de bord sans sauvegarde des données sources permet surtout de reconstituer une jolie absence.

Sans indicateurs rattachés à une décision, la porte reste ouverte de façon discrète. Les arbitrages budgétaires se font au volume de tickets, donc les correctifs faciles passent avant les expositions réellement atteignables depuis Internet. En cas d’incident, la chronologie ne peut plus être reconstituée : sans valeurs historiques ni version de formule, impossible de démontrer depuis quand un contrôle manquait, ni de distinguer une régression d’un changement de périmètre. Une sonde muette ou une source qui cesse d’émettre améliore les chiffres au lieu de déclencher une alerte, ce qui retarde la détection de la panne de détection elle-même. Face à un contrôle réglementaire ou à un assureur, seules des déclarations restent opposables, sans preuve de couverture ni de délai tenu. Enfin, un droit de modification des étiquettes d’actifs suffit alors à effacer un risque sans le traiter.

Pour mesurer la sécurité, il faut d’abord choisir un danger concret à réduire : vol d’un compte, accès non autorisé à un serveur, perte de données ou arrêt d’un service. Ensuite, il faut lister les éléments concernés et savoir combien existent réellement. Ce total sert à calculer une proportion fiable.

Un bon chiffre relie trois choses : une protection attendue, une preuve qu’elle est présente et une action si elle manque. Par exemple, on peut vérifier que les comptes ayant beaucoup de droits utilisent une deuxième preuve d’identité. Si certains comptes ne la possèdent pas, une équipe désignée doit corriger le problème dans un délai fixé.

Il faut aussi mesurer le temps entre la découverte d’un défaut et sa correction vérifiée. Une moyenne ne suffit pas, car quelques défauts très anciens peuvent rester cachés. Il faut regarder les cas les plus lents.

Les chiffres peuvent mentir sans être faux. Si une machine oubliée n’est pas comptée, le résultat paraît meilleur. Si une alerte disparaît parce que l’outil ne fonctionne plus, le danger n’a pas disparu. Les sources de données, les règles de calcul et les modifications doivent donc être surveillées. Enfin, un chiffre ne prouve pas qu’une attaque est impossible : il montre seulement si une protection précise fonctionne sur un périmètre connu.

À lire aussi

Pages voisines

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