On nous a demandé, plus d’une fois, quel produit avait retourné un programme de sécurité. La réponse honnête, c’est que ce n’a jamais été un produit. Trois missions, trois organisations de tailles très différentes, et la même réponse à chaque fois.
Vingt usines, une petite équipe
Un groupe industriel de plus de vingt usines gérait la sécurité comme beaucoup de groupes : une poignée de personnes au siège pour les pare-feu, l’annuaire et l’antivirus de tout le monde, et des sites qui étaient, en pratique, indépendants. L’équipe du siège venait entièrement d’un seul pays. Les sites étaient sur trois continents.
À notre arrivée comme RSSI de transition, les sites s’opposaient à presque tout. Un site, à qui l’on demandait d’appliquer un nouveau jeu de politiques de durcissement, a fait remarquer qu’environ un tiers des réglages y étaient en place depuis dix ans. Il avait raison. Le même site n’appliquait pas de correctifs sur son réseau de production isolé, et comptait encore cent cinquante postes bureautiques sur un système d’exploitation hors support depuis un an. Les deux étaient vrais, et aucun n’était un problème de technique.
Le tournant du programme est venu après l’attaque par ransomware, quand le comité exécutif a eu une raison d’y prêter attention. La proposition qui a abouti n’était pas un outil. C’était une équipe mondiale : un référent par domaine technique, un responsable sécurité sur chaque site avec un nom et un rôle, des procédures écrites, et une gestion des changements obligatoire. Dix-huit mois plus tard, le programme était aligné sur un cadre reconnu et l’étape suivante annoncée était que les décisions de sécurité soient prises conjointement par l’informatique et les métiers au niveau de la direction. Une revue interne ultérieure a nommé les vrais obstacles rencontrés : un manque de légitimité sur les sites, aucun inventaire complet des actifs, et pas de sécurité sans le soutien de la direction. Aucun ne se règle par un achat.
Quarante et un points ouverts, surtout de la responsabilité
Un processeur de paiement par carte est entré dans sa première évaluation 3DS avec un système de management de la sécurité mûr, et en est sorti, après les journées sur site, avec quarante et une exigences comportant des points ouverts. À la relecture, les constats techniques étaient peu nombreux : des données d’authentification conservées plus longtemps que le standard ne l’autorise, une politique de sécurité de contenu qui autorisait les scripts en ligne, quatre personnes franchissant un sas à entrée unique avec quatre badges.
Le reste concernait qui était responsable de quoi. Aucune définition formelle de l’environnement 3DS. Des responsabilités avec l’hébergeur jamais écrites. Une liste de logiciels critiques que personne n’avait été chargé de tenir à jour. L’évaluation est passée de quarante et un points ouverts à la certification en deux mois, et presque rien de ce temps n’a été consacré à la technique. Il a servi à décider qui était responsable de chaque document et à le faire signer.
Ce qu’un régulateur lit vraiment
Une société de paiement qui préparait l’agrément de son régulateur bancaire a demandé un jeu complet de politiques de sécurité de l’information. La tentation, et les paquets de modèles en vente, disent : quarante documents, on change le logo, c’est fait.
Ce que le régulateur lit est différent. Il lit si la politique décrit quelque chose que la société fera réellement, et s’il existe une preuve que c’est fait. Les politiques de référence que nous avons comparées pour cette mission venaient de trois organisations très différentes : une grande politique révisée chaque année depuis dix ans, un jeu modulaire de quinze documents sur la structure d’une norme internationale, et une courte politique écrite par une petite société pour répondre exactement aux exigences de ses clients. Les meilleures avaient une qualité en commun. Elles ne promettaient que ce que leur organisation pouvait tenir, et disaient comment cela serait prouvé. Des délais de correctifs par criticité, avec un processus d’exception pour quand ils sont manqués. Un calendrier d’analyses avec une nouvelle analyse après tout changement significatif. Des dates de revue tenues : l’une d’elles avait six versions datées en cinq ans, ce qui est en soi une preuve.
Nous avons livré le modèle modulaire : une politique chapeau et un jeu court de politiques et de procédures, chacune avec un responsable, sur la structure d’une norme internationale. Le régulateur a accepté le jeu sans une question. Nous soupçonnons que sa barre n’était pas haute. Ce n’est pas une raison pour baisser la vôtre, parce que le prochain lecteur sera un évaluateur ou un client, et il demandera.
Ce que l’on fait de travers
On achète des produits pour compenser une gouvernance absente. Une plateforme de détection ne crée pas une personne responsable de réagir. Un paquet de politiques ne crée pas un comité qui lit les exceptions.
On traite la sécurité comme un sujet du service informatique. Les sites qui résistaient au programme du groupe ne résistaient pas à la sécurité. Ils résistaient aux instructions d’un service qui n’avait aucune légitimité pour les donner. Dès que l’instruction est venue du comité exécutif, avec un responsable sécurité de site qui rendait compte vers le haut, la résistance est devenue une conversation.
On écrit des délais qui relèvent du vœu. Une politique qui promet une fenêtre de correctif de vingt-quatre heures que l’organisation n’a jamais tenue une seule fois n’est pas ambitieuse. C’est un constat qui attend d’être écrit.
Une plateforme de détection ne crée pas une personne responsable de réagir.