Justifier un budget sécurité à la direction financière

Parcours « Responsable sécurité (RSSI) » — étape 09/15

← 08Quels indicateurs mesurer pour la sécurité10Gérer les risques tiers et la chaîne logicielle →

Justifier un budget sécurité à la direction financière

Un budget sécurité ne se défend pas par une liste d’outils, des alertes rouges ou la promesse vague de « réduire le risque ». Il se défend par une décision économique : financer une réduction mesurable d’exposition, avec des hypothèses contestables mais traçables, plutôt que financer du matériel pour meubler une slide.

Explication de la marmotte

Demander un budget sécurité ressemble à demander le remplacement d’un toit avant la saison des pluies. Le coût du travail est visible tout de suite, alors que le dégât évité reste hypothétique. Il faut donc montrer ce que coûterait réellement l’inondation, et pourquoi attendre n’est pas gratuit.

→ Lire l’explication complète de la marmotte

Le compromis financier du budget sécurité

Le compromis central est brutal : payer maintenant pour réduire une perte future incertaine, ou conserver du capital et accepter une exposition connue. La sécurité ne produit généralement pas un revenu direct. Elle réduit la fréquence, l’ampleur ou la durée d’événements qui détruisent du revenu, immobilisent des équipes ou empêchent une obligation contractuelle d’être tenue.

La recommandation est de présenter chaque demande comme une réduction de scénario de perte, jamais comme l’acquisition d’une technologie. Un outil de détection ne mérite pas un budget parce qu’il est classé dans la catégorie « sécurité ». Il le mérite s’il réduit le délai de détection d’une compromission, si ce délai évite une propagation, et si le coût évité dépasse le coût complet de l’outil et de son exploitation.

Le coût complet comprend le coût d’acquisition, les abonnements, les intégrations, le temps d’administration, la supervision, les exercices de reprise, les audits et les remplacements à terme. Distinguer CAPEX (Capital Expenditure, dépense d’investissement) et OPEX (Operational Expenditure, dépense opérationnelle) ne suffit pas : une licence annuelle à faible prix qui exige deux postes permanents coûte plus cher qu’un composant matériel amorti et peu administré.

Une direction financière ne finance pas une probabilité magique. Elle finance une exposition dont les bornes sont explicites. Une estimation en fourchette est plus défendable qu’un chiffre au centime : perte basse, perte vraisemblable, perte haute. Afficher 1 273 481 € comme si un rançongiciel respectait la comptabilité analytique est une manière élégante de perdre toute crédibilité avant la deuxième question.

Les pages sur l’architecture cyber et les menaces doivent alimenter cette discussion. Le budget ne remplace ni l’inventaire des actifs ni les scénarios d’attaque. Sans ces deux éléments, il ne reste qu’un catalogue de produits avec des logos rassurants. Les logos ne ferment pas les accès exposés.

Modèle de perte, hypothèses et périmètre de décision

Partir d’un actif métier et d’un événement redouté. Un actif n’est pas « le système d’information », formule commode parce qu’elle ne décide rien. C’est un service de facturation, une plateforme de production, un annuaire d’identités ou un dépôt de secrets. Pour chacun, documenter quatre valeurs :

1. la perte par heure ou par jour d’indisponibilité ;
2. le coût de reconstitution ou de restauration ;
3. le coût contractuel, réglementaire ou assurantiel déclenché par l’incident ;
4. le coût de réponse : investigation, assistance externe, communication, heures supplémentaires et arrêt contrôlé.

La perte par indisponibilité se calcule sur la marge non réalisée, les pénalités prévues et le coût des processus dégradés. Le chiffre d’affaires brut est souvent un mauvais substitut : un service indisponible peut différer une vente sans la détruire. À l’inverse, une chaîne de production arrêtée peut créer une perte supérieure au chiffre d’affaires de la période, car les matières, les créneaux logistiques et les engagements clients ne se rembobinent pas avec un bouton.

La probabilité doit être liée à un chemin d’attaque observable. Exemple : vol d’identifiants, accès à distance sans authentification multifacteur, élévation de privilèges, désactivation de sauvegardes, chiffrement de serveurs. L’authentification multifacteur exige au moins deux preuves indépendantes d’identité. Elle ne supprime pas le hameçonnage, mais réduit fortement la valeur d’un mot de passe volé lorsque le facteur supplémentaire résiste à l’interception.

Les hypothèses doivent indiquer leur source : tests de restauration, rapports d’incident internes, contrats de service, données comptables, résultats d’exercices ou métriques de supervision. Une hypothèse sans propriétaire ni date de révision devient rapidement une tradition orale. Vingt ans de métier apprennent qu’une tradition orale survit très bien à trois réorganisations, mais rarement à un audit.

Le modèle doit aussi exprimer ce que le contrôle ne garantit pas. Un coffre de secrets réduit la diffusion des identifiants privilégiés, mais ne bloque pas un administrateur légitime compromis. Un EDR (Endpoint Detection and Response, détection et réponse sur les postes) peut détecter des comportements suspects, mais ne restaure aucune donnée. Un HSM (Hardware Security Module, module matériel de sécurité) empêche l’extraction d’une clé cryptographique selon sa politique, mais ne rend pas inoffensive une opération de signature demandée par une identité volée.

Les contrôles non financés doivent figurer dans le dossier. Cette partie est inconfortable, donc indispensable : elle rend visible le risque résiduel accepté. Une direction financière peut alors choisir explicitement entre financer, transférer, réduire autrement ou accepter. C’est une décision de gouvernance, pas une séance de divination avec tableur.

Exemple reproductible de chiffrage d’exposition

Le calcul suivant compare un scénario sans contrôle et un scénario avec contrôle. Les montants sont volontairement fictifs, mais le mécanisme est exécutable avec Python 3 sans dépendance externe. La fréquence annuelle représente une estimation de survenue, pas une promesse de calendrier.

python3 - <<'PY'
# Coût d'un incident complet : arrêt, restauration et réponse.
cout_incident = 850_000

# Fréquence annuelle estimée avant le contrôle.
frequence_avant = 0.18

# Le contrôle réduit la fréquence et limite la propagation.
frequence_apres = 0.06
cout_incident_apres = 420_000

# Coût annuel complet : abonnement, exploitation et exercices.
cout_annuel_controle = 72_000

perte_annuelle_avant = cout_incident * frequence_avant
perte_annuelle_apres = cout_incident_apres * frequence_apres
reduction_exposition = perte_annuelle_avant - perte_annuelle_apres
benefice_net = reduction_exposition - cout_annuel_controle

print(f"Perte annuelle avant contrôle : {perte_annuelle_avant:,.0f} €")
print(f"Perte annuelle après contrôle : {perte_annuelle_apres:,.0f} €")
print(f"Réduction d'exposition : {reduction_exposition:,.0f} €")
print(f"Bénéfice net estimé : {benefice_net:,.0f} €")
PY

Le résultat n’est pas une preuve que l’investissement « rapporte » exactement cette somme. Il expose les conditions de validité : si la fréquence réelle est deux fois plus faible, ou si le contrôle ne réduit pas le coût de propagation, la décision peut changer. C’est précisément l’intérêt du calcul : discuter les hypothèses qui comptent, au lieu de débattre du prix catalogue d’une plateforme à laquelle un vendeur a ajouté le mot intelligence.

Pour les investissements structurants, présenter trois cas. Le cas prudent suppose une efficacité réduite et un incident moins coûteux. Le cas central reprend les hypothèses les plus documentées. Le cas sévère couvre un incident à propagation large ou une restauration lente. Si le projet n’est rentable que dans le cas sévère, il relève davantage d’une assurance que d’un retour financier direct. Ce n’est pas un défaut, à condition de le dire.

Surface d’attaque des indicateurs de sécurité

Un indicateur devient une cible dès qu’il conditionne un budget. Compter les vulnérabilités corrigées incite à fermer des tickets faciles, pas à traiter les chemins d’attaque exploitables. Compter les alertes traitées pousse à découper un incident en dizaines de dossiers. Mesurer le taux de conformité d’inventaire sans vérifier les actifs inconnus revient à féliciter un radar parce qu’il ignore les avions hors écran.

Retenir des indicateurs reliés à une barrière technique vérifiable :

• couverture réelle de l’authentification multifacteur sur les comptes à privilèges ;
• délai entre publication d’une vulnérabilité critique et correction sur les systèmes exposés ;
• taux de restauration réussie, mesuré par un exercice complet ;
• délai de révocation d’un accès privilégié après un départ ou une compromission ;
• part des secrets gérés avec rotation et journalisation.

Chaque indicateur exige une contre-mesure contre sa manipulation. Échantillonner les données sources, conserver les journaux bruts, croiser l’inventaire avec les flux réseau et séparer l’équipe qui exécute le contrôle de celle qui valide le résultat. Une CMDB (Configuration Management Database, base de données de gestion de configuration) déclarative ne prouve pas qu’un serveur existe encore ou qu’il est protégé. Les découvertes réseau et les journaux d’identité servent à contredire poliment la CMDB quand elle rêve.

La fraude aux indicateurs n’est pas toujours intentionnelle. Un changement de périmètre, une fusion d’inventaires ou une modification d’outil peut faire varier une métrique sans modifier le risque. Tout tableau présenté à la direction doit donc afficher son périmètre, sa source, sa période de mesure et les exclusions. Sans cela, le graphique est décoratif. Il peut même être bleu, ce qui n’améliore rien.

Exploitation, reprise et preuves de contrôle

Un budget défendable finance l’exploitation du contrôle, pas seulement son déploiement. Pour une solution de gestion de secrets, cela inclut la rotation des comptes, le traitement des échecs de rotation, la révocation d’urgence, les sauvegardes chiffrées et les tests de restauration. Une rotation qui échoue sur un compte de service peut interrompre une application. Une rotation jamais testée peut surtout offrir l’illusion agréable d’une serrure sans clé.

Pour les clés cryptographiques, documenter le propriétaire, l’usage autorisé, la durée de vie, les mécanismes de sauvegarde et les conditions de destruction. Une KEK (Key Encryption Key, clé de chiffrement de clés) doit être séparée des données qu’elle protège et de ses sauvegardes. Une sauvegarde restaurable mais accessible avec les mêmes identifiants que la production ne constitue pas une reprise indépendante.

Les objectifs de reprise doivent être testés. Le RTO (Recovery Time Objective, durée maximale de reprise) indique le délai maximal acceptable avant retour de service. Le RPO (Recovery Point Objective, perte maximale de données acceptable) indique l’ancienneté maximale des données restaurées. Ils ne se déduisent pas du prix d’une solution de sauvegarde. Ils se démontrent par une restauration complète, avec les dépendances d’identité, de réseau, de certificats et de secrets.

La supervision doit fournir une preuve d’efficacité : journaux d’administration, alertes sur désactivation de protection, échecs de sauvegarde, dérives de configuration et tentatives d’accès anormales. Les fondations de l’infrastructure et les identités sont des prérequis de budget, pas des annexes. Sans horodatage cohérent, inventaire fiable et comptes d’administration séparés, la détection produit surtout des mystères à payer au taux horaire.

NIS2 (Network and Information Security Directive 2, directive européenne sur la sécurité des réseaux et des systèmes d’information) ou EBIOS RM (Expression des Besoins et Identification des Objectifs de Sécurité, méthode de gestion des risques) peuvent structurer les preuves et les scénarios. Ils ne fournissent pas un montant de budget ni une garantie juridique. La conformité décrit un seuil attendu ; l’architecture doit encore montrer que les contrôles tiennent quand un composant tombe, qu’une identité est compromise ou qu’une sauvegarde refuse de se restaurer.

🐝 Ce qui arrive si on s’en passe

Sans dossier économique traçable, l’arbitrage se déplace vers le prix catalogue et la date de renouvellement. Les lignes d’exploitation (rotation des secrets, exercices de restauration, supervision, révocation) sont coupées les premières, parce qu’elles n’apparaissent dans aucun chiffrage de perte évitée : les contrôles restent installés mais cessent d’être tenus, et leur efficacité n’est plus démontrable. Le risque résiduel n’est alors accepté par personne de façon explicite, faute d’hypothèses datées et rattachées à un propriétaire. Après un incident, rien ne permet de reconstituer pourquoi une barrière n’a pas été financée, ni de distinguer une estimation invalidée d’un oubli. Les indicateurs présentés perdent leur périmètre et leurs exclusions, donc toute variation devient ininterprétable. Un déploiement partiel, sur une fraction des comptes à privilèges, se présente alors comme une couverture complète.

🦫 Explication de la marmotte 🍫

Pour obtenir de l’argent destiné à la sécurité, il faut d’abord choisir ce qui pourrait être perdu : un service arrêté, des données détruites, des contrats non respectés ou du temps de travail mobilisé pour réparer. Pour chaque problème possible, on estime combien il coûterait et à quelle fréquence il pourrait arriver. Ces estimations ne sont pas des certitudes. Elles doivent montrer leurs sources et leurs limites.

Ensuite, on décrit la protection demandée. Il faut expliquer quelle partie du problème elle réduit : empêcher une connexion volée, repérer plus tôt une intrusion, limiter la propagation ou restaurer les données. Son prix réel inclut l’achat, le fonctionnement quotidien, les personnes qui s’en occupent et les essais de réparation.

La décision compare alors la perte attendue avant la protection, la perte attendue après, et le coût de la protection. Si les hypothèses changent, le résultat peut changer aussi. C’est pourquoi elles doivent être vérifiées régulièrement.

Une protection ne supprime jamais tous les dangers. Elle peut tomber en panne, être mal réglée ou être contournée par une personne ayant déjà des droits. Il faut donc surveiller son fonctionnement, garder des preuves, renouveler les accès sensibles, sauvegarder les éléments nécessaires et tester la remise en service. Si la restauration échoue pendant un incident, le budget a payé une promesse, pas une capacité réelle.

À 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.
• Clauses de sécurité pour contrat fournisseurDéfinir des clauses de sécurité vérifiables dans un contrat fournisseur.
• 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

Justifier un budget sécurité à la direction financière

Elle cite

• ⇄Lien dans les deux sens :Calculer le coût-bénéfice d’un incident évité
• Calculer le coût total de possession d'un contrôle de sécurité
• Quels indicateurs mesurer pour la sécurité

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