Calculer le coût-bénéfice d’un incident évité

Calculer le coût-bénéfice d’un incident évité

Un incident évité ne produit ni ticket d’incident, ni indisponibilité mesurée, ni facture de remédiation. Il produit donc surtout une tentation : attribuer au dernier contrôle déployé tout ce qui ne s’est pas mal passé. Cette analyse doit mesurer une réduction de risque défendable, pas financer une légende interne avec trois graphiques verts.

Explication de la marmotte

Évaluer un incident évité ressemble à décider si une assurance ou une ceinture de sécurité a valu son prix après une année sans accident. L’objectif n’est pas de prétendre savoir ce qui serait arrivé, mais de vérifier que l’argent dépensé réduit réellement une perte plausible.

→ Lire l’explication complète de la marmotte

Le compromis entre preuve comptable et réduction de risque

Le compromis central est brutal : plus l’analyse veut prouver qu’un contrôle a évité un incident précis, plus elle repose sur une histoire invérifiable. À l’inverse, plus elle s’appuie sur des données observables et des scénarios explicités, moins elle produit de chiffres spectaculaires. La seconde approche doit gagner. Une estimation prudente est exploitable ; un gain miraculeux attribué à un pare-feu neuf finit généralement dans une slide, puis dans un audit, puis dans une poubelle conceptuelle.

La bonne question n’est pas « quel incident a été évité ? ». Elle est : « de combien le contrôle réduit-il la perte annuelle attendue, sous quelles hypothèses, et pour quel coût total ? ». La perte annuelle attendue est la somme des pertes possibles, pondérées par leur probabilité annuelle. Elle se calcule ainsi :

perte annuelle attendue = somme(probabilité du scénario × coût du scénario)

Un contrôle est économiquement justifié si la diminution estimée de cette perte dépasse son coût total de possession. Ce coût inclut acquisition, intégration, exploitation, journalisation, rotation des secrets, formation, indisponibilités induites et remplacement. Exclure l’exploitation revient à comparer une voiture au prix de ses essuie-glaces.

La réduction de risque doit être rattachée à un chemin d’attaque déterminé. Un filtrage de sortie réduit par exemple la probabilité d’exfiltration réussie après compromission, mais ne réduit pas nécessairement la probabilité d’obtenir un accès initial. Un mécanisme d’authentification forte réduit l’usurpation d’identifiants, mais ne corrige ni une autorisation excessive ni une session déjà volée. Les dépendances entre contrôles doivent être écrites, faute de quoi le même bénéfice sera compté deux fois avec une régularité presque artistique.

Les scénarios doivent provenir du registre de risque, des menaces identifiées et des actifs réellement exposés. La cartographie des menaces fournit le point de départ ; la gouvernance cybersécurité fournit le cadre de décision. Une analyse financière isolée de l’architecture fabrique des chiffres propres sur des périmètres imaginaires.

Construire un scénario contrefactuel vérifiable

Un contrefactuel décrit ce qui aurait pu se produire sans le contrôle étudié. Il ne décrit pas ce qui se serait produit. Cette nuance sépare une estimation de risque d’une reconstitution médiumnique.

Pour chaque scénario, documenter cinq éléments :

1. L’événement redouté : compromission d’un compte à privilèges, chiffrement de serveurs, exfiltration de données ou interruption d’un service.
2. Le chemin d’attaque : accès initial, élévation de privilèges, mouvement latéral, action sur l’actif et sortie de données.
3. La barrière étudiée : contrôle préventif, détectif ou correctif, avec son point exact dans le chemin.
4. La réduction attendue : baisse de probabilité, baisse d’impact, ou baisse de durée d’exposition.
5. La preuve disponible : tests d’intrusion, exercices de crise, journaux, taux de blocage qualifié, temps de détection ou restauration testée.

Une barrière qui bloque 95 % des tentatives observées ne réduit pas automatiquement le risque de 95 %. Les tentatives observées sont souvent bruyantes, opportunistes et parfois générées par des robots qui ont autant de stratégie qu’un grille-pain. L’estimation doit distinguer le trafic hostile banal des techniques capables d’atteindre l’actif critique.

La méthode la plus robuste consiste à modéliser plusieurs scénarios, avec une distribution de coûts plutôt qu’une moyenne unique. Une indisponibilité peut coûter peu dans son cas nominal et beaucoup lors d’une période métier sensible. Une fuite de données peut engendrer investigation, notification, assistance aux personnes concernées, contentieux, perte de contrats et reconstruction technique. Les coûts indirects ne doivent pas être gonflés pour rendre le contrôle vendable, mais ils ne doivent pas être omis parce qu’ils n’entrent pas dans un tableau de dépenses.

L’analyse doit aussi séparer les effets du contrôle des changements simultanés : réduction de surface exposée, retrait d’un protocole ancien, migration d’identités ou changement d’hébergeur. Sans groupe comparable ni mesure avant-après cohérente, attribuer l’amélioration à un seul composant relève de la corrélation décorative. La désactivation de l’authentification faible, par exemple, ne se mesure pas avec le nombre de connexions refusées seul : il faut vérifier que les flux légitimes ont migré et que les chemins de contournement ont disparu. La page sur la désactivation de LDAP en clair et anonyme rappelle pourquoi cette vérification compte.

Exemple reproductible de perte annuelle attendue

L’exemple suivant compare un scénario d’exfiltration avant et après déploiement d’un contrôle. Les montants et probabilités sont des hypothèses, pas des vérités révélées par un tableur sous une pleine lune.

# Python 3.11+
# Modèle minimal : chaque scénario porte une probabilité annuelle et un coût.
# La réduction ne porte ici que sur la probabilité de succès, pas sur le coût.

scenarios_avant = [
    {"nom": "exfiltration limitée", "probabilite": 0.18, "cout_eur": 80_000},
    {"nom": "exfiltration majeure", "probabilite": 0.04, "cout_eur": 900_000},
]

scenarios_apres = [
    {"nom": "exfiltration limitée", "probabilite": 0.10, "cout_eur": 80_000},
    {"nom": "exfiltration majeure", "probabilite": 0.015, "cout_eur": 900_000},
]

cout_annuel_controle = 42_000  # licences, exploitation, supervision et tests

def perte_attendue(scenarios):
    return sum(s["probabilite"] * s["cout_eur"] for s in scenarios)

avant = perte_attendue(scenarios_avant)
apres = perte_attendue(scenarios_apres)
benefice_brut = avant - apres
benefice_net = benefice_brut - cout_annuel_controle

print(f"Perte attendue avant : {avant:,.0f} €")
print(f"Perte attendue après : {apres:,.0f} €")
print(f"Bénéfice net annuel : {benefice_net:,.0f} €")

Le résultat n’affirme pas qu’une perte de montant déterminé a été évitée. Il indique qu’avec les hypothèses saisies, le contrôle dégage ou non une valeur attendue. Faire varier les probabilités et les coûts est obligatoire : si le bénéfice net devient négatif dès qu’une hypothèse raisonnable change, la décision est fragile. Il faut alors réduire le coût, compléter la preuve, ou accepter explicitement que le contrôle répond à une obligation non économique.

Surface d’attaque de la mesure elle-même

La mesure devient une surface d’attaque dès qu’elle pilote un budget. Le premier risque est le biais d’attribution : compter comme bénéfice toute absence d’incident après un déploiement. L’absence d’incident peut venir d’une baisse de menace, d’un actif retiré, d’une détection incomplète ou d’une chance insolente. Aucun tableau de bord ne distingue ces causes par télépathie.

Le deuxième risque est le double comptage. Un EDR (Endpoint Detection and Response), une segmentation réseau et une sauvegarde immuable peuvent tous contribuer à limiter un rançongiciel. Additionner leurs bénéfices comme si chacun supprimait seul le sinistre produit une réduction supérieure à 100 %. Le risque ne connaît pas la comptabilité créative, même si certains catalogues de produits semblent y croire très fort.

Le troisième risque est la manipulation des indicateurs. Un taux de blocage élevé peut augmenter parce qu’une règle est trop large. Un temps moyen de détection peut diminuer parce que les cas difficiles sont exclus. Un nombre nul d’alertes peut signaler une protection parfaite, ou une collecte cassée, deux états que le silence des journaux confond avec une certaine élégance.

Les contre-mesures sont concrètes :

• conserver les hypothèses, versions de modèle et sources de données ;
• faire relire les scénarios par l’architecture, l’exploitation et le métier propriétaire de l’actif ;
• tester régulièrement le contrôle avec des techniques autorisées ;
• comparer les journaux de prévention avec des preuves indépendantes, telles que sondes réseau ou traces applicatives ;
• publier un intervalle de résultats, jamais un unique chiffre présenté comme une certitude ;
• invalider le bénéfice lorsque la télémétrie, la couverture ou le périmètre a changé.

Cette analyse ne garantit ni conformité réglementaire, ni absence de compromission, ni couverture des scénarios inconnus. Les exigences de résilience, de notification et de gouvernance viennent aussi des obligations applicables et de l’analyse de risque. L’économie aide à prioriser ; elle ne transforme pas un risque inacceptable en bonne idée parce que le retour sur investissement sourit.

Exploitation, preuves et reprise de l’analyse

Le modèle doit devenir un objet exploité, pas un fichier figé entre deux revues budgétaires. Réexaminer les probabilités après modification d’exposition, incident chez un fournisseur, découverte de vulnérabilité exploitable ou changement de dépendance. Une hypothèse âgée peut être plus dangereuse qu’une alerte bruyante : elle reste silencieuse et garde parfois un budget entier sous perfusion.

Les sources de preuve exigent les mêmes soins que les autres données de sécurité. Les journaux doivent être horodatés sur une source de temps fiable, protégés contre l’altération et conservés selon une durée définie. Les droits d’accès au registre de risque, aux exports de journalisation et aux preuves de test doivent être séparés : la même identité ne doit pas pouvoir modifier une hypothèse, altérer la preuve et approuver le bénéfice.

Les secrets utilisés pour collecter les métriques, appeler des interfaces de programmation ou exporter les événements doivent être dédiés, à privilèges minimaux et rotatifs. Une clé d’interface partagée entre supervision et production transforme un rapport financier en chemin d’accès latéral. Les sauvegardes du modèle, des données brutes et des justificatifs doivent être testées en restauration. Sauvegarder un fichier chiffré sans tester la récupération de sa clé est une cérémonie administrative avec un peu plus de cryptographie.

Conserver également la trace des contrôles retirés. Un bénéfice historique ne survit pas au démontage de la barrière qui le produisait. Les revues d’architecture doivent donc lier chaque hypothèse à un composant, un propriétaire, une source de journalisation et une date de prochaine validation. C’est moins glamour qu’un indicateur de maturité multicolore, mais le mécanisme résiste mieux quand quelqu’un demande pourquoi le chiffre existe.

🐝 Ce qui arrive si on s’en passe

Sans ce calcul, l’arbitrage budgétaire se fait au prix d’achat et non au coût total de possession : les dépenses d’exploitation, de journalisation et de test arrivent après la décision, souvent sans ligne budgétaire, et le contrôle reste installé sans supervision réelle. Les scénarios non rattachés à un chemin d’attaque laissent des étapes entières sans barrière pendant que d’autres reçoivent plusieurs couches redondantes. Faute d’hypothèses conservées, aucune revue ne peut détecter qu’un bénéfice repose sur un composant retiré, une collecte interrompue ou un périmètre réduit, et le chiffre survit au mécanisme qui le justifiait. La priorisation se déplace alors vers les risques faciles à raconter, et les scénarios coûteux mais peu probables, comme la destruction de sauvegardes, restent sans financement ni propriétaire identifié.

🦫 Explication de la marmotte 🍫

Pour évaluer un incident évité, on commence par décrire un problème possible : par exemple, une personne malveillante pourrait voler des données ou arrêter un service. Il faut ensuite écrire les étapes nécessaires pour réussir cette action, puis repérer à quelle étape une protection agit.

Chaque problème reçoit une probabilité de se produire sur une année et un coût estimé s’il réussit. Le coût comprend la réparation, l’arrêt éventuel du travail, les personnes mobilisées et les conséquences pour les personnes ou services touchés. On calcule ensuite une perte moyenne attendue en multipliant chaque probabilité par son coût.

Après l’installation d’une protection, on ne prétend pas qu’un incident précis a disparu. On estime seulement si la probabilité de réussite ou les dégâts possibles ont diminué. La différence entre les pertes moyennes avant et après représente le bénéfice attendu. Il faut ensuite retirer le prix complet de la protection, y compris son entretien, les personnes qui la surveillent et les tests.

Cette méthode échoue si les chiffres sont inventés, si plusieurs protections reçoivent le crédit du même résultat, ou si les traces utilisées pour vérifier le fonctionnement sont absentes ou modifiées. Les hypothèses doivent donc être conservées, revues régulièrement et comparées à des tests. Si la protection est retirée ou cesse de fonctionner, le calcul doit changer immédiatement.

À lire aussi

• Quels indicateurs mesurer pour la sécuritéMesurer la sécurité avec des indicateurs qui pilotent réellement la réduction du risque, plutôt que des tableaux de bord décoratifs.
• Assurance cyber couverture et exclusions de contratAssurance cyber : ce qu’elle couvre, ce qu’elle exclut et les exigences techniques qui conditionnent l’indemnisation.
• Comment capitaliser et payer la dette de sécuritéLa dette de sécurité se capitalise par l'exposition, la dépendance et la perte de capacité de correction, puis se paie par des travaux d'architecture, d'exploitation et de réduction du risque.
• Calculer le coût d’un LLM local à grande échelleMéthode de dimensionnement et d’optimisation économique d’un déploiement local de modèles de langage à grande échelle.

Pages voisines

La citent

• Pourquoi la dette technique de sécurité reste non chiffrée

Calculer le coût-bénéfice d’un incident évité

Elle cite

• ⇄Lien dans les deux sens :Justifier un budget sécurité à la direction financière
• Calculer le coût total de possession d'un contrôle de sécurité
• Grand-père Castor raconte : bind LDAP en clair, corrigé
• Pourquoi MTTD et MTTR biaisent la sécurité

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