La vente la plus difficile en sécurité n’est pas un produit. C’est l’application des correctifs, dans un groupe qui ne l’a jamais faite de façon cohérente, à un comité exécutif à qui l’on n’a jamais demandé de s’y intéresser. Voici comment un tel dossier a été écrit, et ce qui s’est passé après son approbation.
La situation
Un groupe industriel de plus de vingt usines appliquait ses correctifs site par site, chacun à sa manière, surtout sur son parc Windows, sans aucune vue au niveau du groupe. Quand on a demandé la preuve que les correctifs étaient appliqués, la réponse honnête dans le dossier de direction a été « des données informelles du personnel informatique ». Trois intrusions en six mois avaient chacune été contenues avant la fin de la journée et oubliées avant la fin de la semaine.
Comment le dossier a été écrit
Pas avec des fonctionnalités, des scores de vulnérabilités ou des quadrants d’analystes. Le problème a été posé en quatre verbes simples : voir, évaluer, corriger, vérifier. Voir ce qui est sur le réseau. Évaluer ce qui est vulnérable. Corriger, par criticité, avec des échéances. Vérifier que c’est corrigé. Un dirigeant peut garder quatre verbes en tête. Personne ne peut garder un système de notation.
Quatre outils ont été comparés sur les mêmes quatre verbes, avec en regard un coût annuel pour les huit mille actifs du groupe. La preuve de concept a déployé neuf cents agents sur seize sites dans trois pays, et produit, pour la première fois, un chiffre : combien de machines, combien de vulnérabilités sur chacune.
Puis les directeurs informatiques de sites ont parlé. Officiellement, dans le dossier, avec leurs mots, depuis trois continents : ce qu’ils avaient vu dans la preuve de concept et s’ils en voulaient. L’avis du responsable de la sécurité figurait aussi dans le dossier, mais ce n’est pas cet avis qui l’a emporté. Les dirigeants minorent la personne dont le métier est de demander un budget sécurité. Ils écoutent ceux qui devront vivre avec l’outil.
Le dossier disait aussi, par écrit, qu’une attaque significative était probable d’ici quelques semaines ou quelques mois, et que le ransomware était le risque le plus élevé. Il fixait des objectifs datés : visibilité complète du parc sous trois mois, failles critiques des postes de travail éliminées sous six, une politique de groupe avec des niveaux de service pour la fin de l’année.
Ce qui s’est passé
Il a été approuvé. Deux mois plus tard, avant que l’outil ne soit déployé, l’attaque par ransomware qu’il prédisait est arrivée, et le groupe a perdu trois semaines.
Le déploiement a ensuite été rapide, parce que la décision était déjà prise. En quelques mois, l’outil couvrait six mille systèmes, chaque faiblesse connue de l’annuaire avait été fermée, et le chiffre que la direction voyait désormais chaque mois était d’environ deux cents vulnérabilités par poste de travail en moyenne, en baisse. La tendance était le point essentiel. Un chiffre qui baisse est un programme. Un chiffre présenté une fois est une diapositive.
Un chiffre qui baisse est un programme. Un chiffre présenté une fois est une diapositive.
Ce que l’on fait de travers
On commence par la technologie. Les dirigeants n’achètent pas des scanners. Ils achètent le pire scénario évité : la production arrêtée, les données volées, un contrat client en péril, et le coût de ne rien faire à côté du coût de faire quelque chose.
On fait du RSSI la seule voix. La personne qui demande l’argent est la moins convaincante dans la pièce, aussi juste soit-elle.
On présente un état au lieu d’une tendance. « Nous avons quatre mille vulnérabilités » est un chiffre sur lequel personne ne peut agir. « Nous en avions six mille le trimestre dernier, quatre mille aujourd’hui, et voici quand nous atteindrons mille » est un programme avec un budget en face.
On confond approbation et déploiement. Le dossier avait raison, l’argent était approuvé, et l’attaque est venue quand même, parce qu’un budget approuvé ne corrige rien. Le délai entre la décision et le premier agent est la période la plus dangereuse du programme.