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

Éditorial

Analyse des raisons pour lesquelles la dette technique de sécurité est rarement quantifiée financièrement et de ce que cela révèle sur la priorité réelle donnée à la sécurité face à la vélocité produit.

~11 min de lecture8 sections

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

La dette technique logicielle entre peu à peu dans les budgets parce qu’elle ralentit visiblement la livraison. La dette technique de sécurité, elle, reste souvent un registre de risques sans prix, donc sans propriétaire économique. Ce traitement différent n’est pas un défaut de tableur : il révèle l’arbitrage réel entre continuité de la vélocité produit et réduction d’un sinistre futur.

Explication de la marmotte

Une maison peut avoir une fuite d’eau visible qui empêche de cuisiner, ou un détecteur de fumée sans pile qui ne gêne personne aujourd’hui. La première réparation est payée vite parce qu’elle bloque la vie quotidienne. La seconde attend souvent un incendie, ou au moins une inspection un peu gênante.

→ Lire l’explication complète de la marmotte

La dette de sécurité échappe au modèle financier de la dette logicielle

La dette technique logicielle est généralement financée quand son coût marginal devient mesurable : temps de cycle qui augmente, incidents récurrents, migrations bloquées, capacité de livraison consommée par la maintenance. Une équipe peut rattacher une partie des jours perdus à un composant, comparer un avant et un après, puis transformer ce ralentissement en coût de personnel ou en manque à gagner.

La dette de sécurité fonctionne autrement. Une bibliothèque sans correctif, un compte de service sans expiration, une clé de chiffrement partagée entre environnements ou une interface d’administration exposée n’empêchent pas nécessairement une livraison. Le défaut peut même réduire le délai de mise à disposition. Le coût immédiat est donc négatif du point de vue produit : corriger consomme du temps, sans créer de fonctionnalité visible.

C’est le compromis central : reporter la correction achète de la vélocité immédiatement, mais accumule une exposition dont le prix est incertain et parfois discontinu. Une dépendance obsolète peut n’avoir aucun effet pendant trois ans, puis ouvrir une exécution de code à distance le jour où une vulnérabilité exploitable paraît. La comptabilité préfère les flux réguliers aux falaises. Les attaquants aussi, mais pour des raisons moins décoratives.

Le problème n’est pas l’absence de méthodes. Le problème est que la plupart des méthodes sont utilisées pour classer, pas pour décider. Une matrice de vraisemblance et d’impact produit des couleurs. Une couleur rouge déclenche une réunion, pas nécessairement une ligne budgétaire. Sans estimation du coût d’exposition, la sécurité devient une liste de réserves formulées avec soin, puis contournées avec enthousiasme.

La recommandation est donc de ne pas tenter de valoriser chaque faiblesse isolée. Il faut chiffrer des portefeuilles de dette de sécurité liés à des capacités critiques : gestion des identités, administration d’infrastructure, secrets de déploiement, chiffrement des données, journalisation exploitable. Le niveau pertinent n’est ni le ticket ni le risque abstrait, mais le mécanisme commun qui rend plusieurs scénarios possibles. Les pages sur les identités et la cryptographie rappellent pourquoi ces mécanismes concentrent souvent le risque systémique.

Le coût d’incident n’est pas une probabilité décorative

Une quantification sérieuse sépare trois éléments : la fréquence attendue, la perte par occurrence et le coût certain du maintien de l’exposition. La fréquence attendue ne doit pas être inventée à partir d’un chiffre de rapport marketing. Elle se construit avec des signaux vérifiables : exposition Internet, privilèges accessibles, exploit public, absence de correctif, capacité de détection, temps de révocation et dépendance à un tiers.

La perte par occurrence doit inclure les coûts techniques réellement déclenchés par un incident : investigation, indisponibilité, reconstruction de postes ou de serveurs, rotation de secrets, réémission de certificats, assistance externe, restauration et validation. Les pénalités contractuelles et les conséquences réglementaires peuvent être présentées séparément, car leur calcul relève de clauses et de juridictions précises. La sécurité ne gagne rien à jouer au cabinet d’avocats déguisé en tableur.

Le coût certain est plus intéressant qu’il n’en a l’air. Maintenir un composant en fin de vie impose souvent des exceptions de pare-feu, des images de conteneurs distinctes, des contrôles manuels et des procédures de restauration particulières. Ces coûts sont observables. Ils peuvent être affectés au produit qui refuse la correction, au lieu d’être absorbés par une équipe plateforme condamnée à faire tourner un musée sous perfusion.

Une estimation utile peut prendre la forme suivante :

coût annuel attendu = fréquence annuelle estimée × perte technique par incident + coût annuel de maintien

Ce résultat n’est pas une prédiction. C’est une hypothèse falsifiable, qui doit afficher ses bornes et ses sources. Afficher un chiffre unique à l’euro près pour une compromission hypothétique est du théâtre de tableur. En revanche, dire qu’une faiblesse coûte déjà 40 jours par an de contrôles compensatoires, et qu’elle rend plausible une reconstruction complète, permet un arbitrage.

La quantification doit aussi incorporer la réduction de risque réellement obtenue. Déployer une authentification multifacteur ne réduit pas toutes les compromissions au même niveau. Elle limite fortement le réemploi de mots de passe, mais ne protège pas contre le vol de session, une approbation frauduleuse ou l’abus d’un compte déjà privilégié. Une mesure vendue comme une réponse universelle est généralement une réponse vendue par quelqu’un qui n’assurera pas l’astreinte.

La vélocité produit bénéficie d’une comptabilité asymétrique

Le produit bénéficie de mesures quotidiennes : délai de mise sur le marché, taux de conversion, fonctionnalités livrées, disponibilité. La sécurité est fréquemment évaluée par conformité documentaire, nombre de vulnérabilités ouvertes ou achèvement de campagnes. Ces indicateurs disent rarement si l’architecture résiste à une attaque réaliste.

Cette asymétrie donne un avantage structurel au report. Une équipe produit peut justifier une exception par une date de livraison. L’équipe sécurité répond avec une gravité théorique, parfois accompagnée d’un score de vulnérabilité. Le débat est perdu d’avance : une date est un engagement observable, un score n’est qu’une convention de classement.

Il faut donc traduire la dette de sécurité dans la même unité de gouvernance que la vélocité : capacité d’ingénierie et revenu protégé. Un accès administrateur sans authentification forte n’est pas seulement une anomalie de contrôle. C’est une dépendance qui impose un périmètre d’administration plus coûteux, limite l’externalisation d’opérations et augmente le temps de remise en service après compromission.

La bonne règle est sévère : toute exception de sécurité qui dépasse une fenêtre de correction définie doit porter un propriétaire produit, une date d’expiration, un coût de maintien et un scénario de défaillance documenté. Sans expiration, une exception devient une architecture. Sans propriétaire, elle devient une tradition. Les traditions d’infrastructure ont la robustesse d’un château de cartes, avec davantage de réunions.

Cette approche est cohérente avec la gouvernance : le comité d’arbitrage ne choisit pas entre « sécurité » et « produit ». Il choisit explicitement qui finance le risque, quelle capacité est sacrifiée et à quelle échéance la décision sera réexaminée.

Un registre de dette de sécurité qui permet de décider

Un registre exploitable ne doit pas recopier un outil de gestion des vulnérabilités. Il doit agréger les défauts par cause architecturale et conserver les données nécessaires à une décision financière :

• capacité exposée et actifs concernés ;
• chemin d’attaque vérifiable, depuis le point d’entrée jusqu’au privilège ou à la donnée ;
• contrôles existants, leurs limites et leur délai de détection ;
• coût annuel de maintien des compensations ;
• coût de remédiation, incluant tests, migration, rotation et reprise ;
• fourchette de perte technique si le scénario aboutit ;
• date d’expiration de l’acceptation de risque ;
• propriétaire capable d’allouer la capacité nécessaire.

Le chemin d’attaque est non négociable. « Serveur non conforme » ne permet rien de plus qu’un soupir. « Interface d’administration accessible depuis le réseau bureautique, authentifiée par mot de passe local, journalisation non centralisée » permet de discuter des barrières, de la détection et de la correction. Les réseaux et les mécanismes d’administration concentrent souvent ce genre de dette, car une segmentation approximative transforme vite un poste compromis en promontoire.

Le registre doit distinguer la dette de sécurité d’un risque métier externe. Une indisponibilité de fournisseur n’est pas de la dette de sécurité si aucune décision technique interne ne la rend plus probable ou plus coûteuse. En revanche, ne pas tester la restauration, conserver une clé de sauvegarde dans le même domaine de sécurité que la production, ou ignorer la révocation des comptes techniques, sont bien des dettes : une action connue permet d’en réduire l’exposition.

Exemple de calcul reproductible pour une décision d’arbitrage

Le calcul suivant ne prétend pas produire une vérité actuarielle. Il force surtout l’explicitation des hypothèses. Le fichier dette-securite.csv est versionnable avec l’architecture, puis revu à chaque changement significatif de périmètre.

# Créer un registre minimal : fréquence annuelle, perte technique et coût de maintien.
cat > dette-securite.csv <<'CSV'
capacite,frequence_annuelle,perte_incident_eur,maintien_annuel_eur,remediation_eur
acces-administration,0.08,450000,60000,140000
secrets-ci-cd,0.15,280000,35000,90000
pki-interne,0.03,700000,50000,220000
CSV

# Calculer le coût annuel attendu et comparer à la remédiation.
awk -F, '
NR==1 { print "capacite;cout_annuel_attendu_eur;remediation_eur"; next }
{
  attendu=($2*$3)+$4
  printf "%s;%.0f;%.0f\n", $1, attendu, $5
}' dette-securite.csv

Pour acces-administration, le coût annuel attendu atteint 96 000 euros : 36 000 euros de perte attendue, plus 60 000 euros de maintien. Une remédiation à 140 000 euros n’est pas automatiquement prioritaire. Elle le devient si elle réduit aussi le coût de maintien, couvre plusieurs chemins d’attaque, ou si l’exposition est incompatible avec les exigences contractuelles internes.

Le script ne modélise pas la corrélation. C’est sa limite majeure. Une compromission de l’accès d’administration peut déclencher simultanément indisponibilité, fuite de données et compromission de secrets. Additionner des scénarios qui dépendent de la même intrusion gonfle artificiellement le total. Il faut regrouper les scénarios par événement initial et conserver le plus coûteux ou une distribution cohérente, pas empiler des catastrophes comme des cubes de construction.

Ce que la quantification ne garantit pas

Un montant ne transforme pas un risque en contrôle. La quantification ne détecte pas une attaque, ne révoque pas un jeton compromis, ne restaure pas une sauvegarde et ne corrige pas une autorisation excessive. Elle rend une décision visible, ce qui est déjà beaucoup, mais pas magique. Les feuilles de calcul n’ont jamais bloqué une exécution de code à distance, malgré des efforts remarquables de mise en forme conditionnelle.

La qualité dépend des prérequis opérationnels. Il faut un inventaire des actifs et des propriétaires, une classification des données, des journaux centralisés, des tests de restauration, un suivi des comptes de service et une gestion de secrets avec rotation. Sans ces éléments, les estimations reposent sur des hypothèses trop larges pour arbitrer. La dette de sécurité devient alors une dette de connaissance, ce qui est moins poétique et plus dangereux.

La supervision doit mesurer la persistance du défaut : nombre d’exceptions expirées, secrets sans rotation, actifs sans correctif dans une capacité critique, délai médian de révocation, taux de succès des restaurations. Une correction déclarée terminée sans preuve de suppression du chemin d’attaque ne réduit rien. Déplacer un secret dans une variable de pipeline sans limiter qui peut lire le journal, c’est ranger les allumettes dans un tiroir étiqueté « sécurité ».

Enfin, la reprise doit être financée avec la remédiation. Changer un système d’identité impose de prévoir la continuité des accès d’urgence, la rotation des clés et certificats, le retour arrière et la sauvegarde des configurations. Le coût de migration qui exclut ces opérations sous-estime exactement la partie qui casse en production.

🐝 Ce qui arrive si on s’en passe

Sans registre chiffré, l’acceptation d’un risque ne laisse aucune trace exploitable : après un incident, il devient impossible de retrouver qui a autorisé le report, sur quelles hypothèses et avec quelle échéance. L’analyse post-incident se limite alors à constater le défaut, sans pouvoir corriger le processus de décision qui l’a laissé passer. Le même manque ralentit la réponse lorsqu’une vulnérabilité exploitable est publiée : faute d’agrégation par capacité, il faut reconstituer dans l’urgence quels actifs partagent le composant, quels contrôles compensatoires existent réellement et qui peut allouer la capacité de correction. Pendant ce temps, l’exploit public reste utilisable. Enfin, les comptes techniques et les secrets liés aux exceptions oubliées ne figurent dans aucune liste de rotation ; ils échappent donc à la révocation au moment où elle devient nécessaire.

🦫 Explication de la marmotte 🍫

La dette de sécurité apparaît quand une décision technique réduit l’effort aujourd’hui mais augmente la possibilité ou le coût d’un problème plus tard. Par exemple, garder un logiciel non mis à jour, laisser un compte puissant actif trop longtemps ou ne pas vérifier les sauvegardes peut faire gagner du temps à court terme. Le défaut ne bloque pas forcément le travail quotidien, donc il est souvent reporté.

Pour décider, il faut d’abord regrouper les défauts qui concernent la même capacité, comme l’accès aux systèmes, les secrets de déploiement ou le chiffrement des données. Ensuite, il faut décrire comment une personne malveillante pourrait passer d’un point d’entrée à un accès interdit. Cette description permet d’identifier ce qui existe déjà pour bloquer ou repérer l’attaque, et ce qui manque.

Un montant est alors calculé avec trois éléments : la fréquence estimée d’un incident, le coût technique si l’incident arrive, et le coût déjà payé chaque année pour maintenir des protections provisoires. Ce montant est comparé au prix de la correction complète. Chaque estimation doit dire sur quelles informations elle repose.

Si aucune personne responsable, aucune date de fin et aucun budget ne sont associés au report, la dette reste cachée. Si les journaux manquent, si les accès ne sont pas recensés ou si les sauvegardes ne sont jamais restaurées pour test, le calcul devient fragile. La décision doit alors financer aussi ces fondations, sinon le risque reste inconnu et la correction ne peut pas être vérifiée.

À lire aussi

• Assurance cyber couverture et exclusions de contratAssurance cyber : ce qu’elle couvre, ce qu’elle exclut et les exigences techniques qui conditionnent l’indemnisation.
• Calculer le coût total de possession d'un contrôle de sécuritéLe coût total de possession d'un contrôle de sécurité inclut son acquisition, son exploitation, ses dépendances, ses défaillances et son retrait.
• Comment exploiter le Global Risks Report du Forum économique mondialLe Forum économique mondial publie le Global Risks Report, un signal de gouvernance qui influence les priorités cyber sans constituer un référentiel technique.
• Comment dire non en comité de sécurité sans perdre sa crédibilitéDire non en comité de sécurité exige une décision traçable, fondée sur un risque mesuré et assortie d'une voie de sortie exploitable.

Pages voisines

La citent

• ASLR DEP NX canaries et CFI contre les exploits mémoire
• Mettre en place une gestion récurrente des vulnérabilités
• Réseaux spécialisés, sobriété avancée et futurs raisonnables

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

Elle cite

• ⇄Lien dans les deux sens :Comment capitaliser et payer la dette de sécurité
• Calculer le coût-bénéfice d’un incident évité
• Justifier un budget sécurité à la direction financière

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