Ce que février 2024 a réellement changé
Le NIST a publié la version 2.0 du Cybersecurity Framework le 26 février 2024, dix ans après la première. Tout le monde retient l'arrivée d'une sixième fonction, Govern, aux côtés d'Identify, Protect, Detect, Respond et Recover. Presque personne ne relève les trois mots qui ont disparu du titre. La version 1.1 s'appelait Framework for Improving Critical Infrastructure Cybersecurity. La 2.0 s'appelle le NIST Cybersecurity Framework, point, et son périmètre déclaré couvre toute organisation, quels que soient sa taille, son secteur et son niveau de maturité.
Pour un RSSI européen, cette seconde nouvelle pèse plus lourd que la première : elle retire l'argument commode selon lequel le CSF serait un dispositif fédéral américain réservé aux opérateurs d'importance vitale. Ce n'était déjà pas exact ; ce ne l'est plus du tout.
Le Core, lui, s'est resserré : six fonctions, 22 catégories, 106 sous-catégories, contre cinq, 23 et 108 en version 1.1. Le référentiel a gagné une fonction et perdu deux sous-catégories — il ne s'agissait pas d'ajouter de la matière, mais de redistribuer les responsabilités. Les correspondances vers ISO/IEC 27001, SP 800-53 ou COBIT ont par ailleurs quitté les annexes pour le CPRT, l'outil de référence en ligne du NIST : elles vivent au lieu de rester gelées dans un PDF.
Govern au centre, et non en tête de file
Sur le schéma officiel, les cinq fonctions historiques forment un cycle. Govern n'y prend pas la sixième place : elle occupe le centre et touche les cinq autres. Ce n'est pas une décision de mise en page : Govern n'est pas une étape qu'on exécute avant Identify, c'est ce qui détermine si les cinq autres produisent quoi que ce soit.
Six catégories la composent : contexte organisationnel, stratégie de gestion des risques, rôles et autorités, politique, surveillance par la direction, et risque cyber de la chaîne d'approvisionnement. Ce dernier point mérite qu'on s'y arrête : en version 1.1, la supply chain vivait sous Identify ; elle a déménagé sous Govern. C'est une prise de position, et elle est juste : choisir un fournisseur, tolérer un hébergeur sans clause d'audit, ce sont des décisions de gouvernance, pas un exercice d'inventaire.
La catégorie qui fait le plus mal en évaluation reste la surveillance. Elle demande si la stratégie de gestion des risques est revue et ajustée au vu des résultats. Presque toutes les organisations ont une stratégie ; très peu savent montrer ce qu'elles y ont changé après l'avoir confrontée au réel.
Les Tiers ne sont pas une note
Partial, Risk Informed, Repeatable, Adaptive. Numérotés de 1 à 4. Il ne faut pas trente secondes à un comité de direction pour les lire comme une note sur quatre, et c'est l'erreur la plus fréquente et la plus coûteuse que nous rencontrions.
Les Tiers décrivent la rigueur avec laquelle une organisation gouverne son risque cyber : la manière dont elle décide, dont elle raccroche le cyber au risque d'entreprise, dont elle tient compte de ses dépendances. Ils ne décrivent pas le niveau de protection obtenu. On peut être Tier 3 et se faire chiffrer un lundi matin ; on peut être Tier 2 avec un parc durci et des sauvegardes qui fonctionnent.
Le Tier 4 n'est pas la cible de tout le monde. Une posture adaptative se paie : renseignement sur la menace réellement exploité, réallocation dynamique des moyens, révision permanente de la stratégie. Pour une ETI industrielle de trois cents personnes dont le scénario redouté principal est le rançongiciel entré par un accès distant, viser le Tier 4 est un contresens budgétaire. Elle a besoin d'authentification multifacteur, de sauvegardes dont la restauration a été jouée, et d'une segmentation qui tienne. Déclarer le Tier 2 comme cible et l'atteindre vaut mieux que déclarer le Tier 4 et fabriquer les preuves qui vont avec.
Quand un conseil demande « où en sommes-nous ? », la réponse honnête n'est pas un chiffre : c'est une liste de scénarios, ce que nous savons leur opposer aujourd'hui, et la preuve correspondante.
Le profil est l'instrument de travail
Le profil courant décrit les résultats effectivement atteints. Le profil cible décrit ceux qu'on vise, sur un horizon donné. L'écart entre les deux est le plan d'action. Toute la méthode tient là, et elle vaut mieux que n'importe quel diagramme en radar.
Deux formes coexistent, et la seconde est très sous-employée. Le profil organisationnel est le vôtre. Le profil communautaire est un socle publié par une communauté — un secteur, une technologie, une famille de menaces — que vous reprenez comme base de votre cible. Il en existe pour le risque rançongiciel, les données génomiques, les réseaux satellitaires hybrides, et le NIST a publié un guide dédié à leur construction. Partir de là fait gagner des mois et supprime la négociation stérile sur ce que « cible » veut dire.
Une remarque de terrain : ne construisez pas un profil cible à ambition uniforme. Un profil qui vise le même niveau sur les 22 catégories est un profil que personne n'a arbitré. Le déséquilibre prouve qu'un choix a été fait et qu'il se défendra devant un directeur financier.
Les six fonctions, et ce qui trahit un travail bâclé
| Fonction | La question qu'elle pose | Le symptôme d'un travail bâclé |
|---|---|---|
| Govern | Qui décide, sur quelle base, et qui répond du résultat ? | Une politique signée il y a quatre ans, jamais révisée, que personne ne cite |
| Identify | Que possédons-nous, qu'est-ce qui compte, qu'est-ce qui nous vise ? | Un inventaire exporté d'un outil, sans propriétaire ni criticité métier |
| Protect | Qu'avons-nous mis en place pour réduire la probabilité ? | Des contrôles solides sur le poste de travail, absents du SaaS métier et de l'OT |
| Detect | Combien de temps avant que nous le sachions ? | Un SIEM qui collecte tout et n'alerte sur rien d'exploitable |
| Respond | Que faisons-nous, dans quel ordre, et qui parle ? | Un plan jamais joué, avec des numéros d'astreinte périmés |
| Recover | En combien de temps revenons-nous, et dans quel état ? | Des sauvegardes validées par le succès du job, jamais par une restauration |
CSF et ISO 27001 ne s'affrontent pas
La question « faut-il faire du CSF ou de l'ISO 27001 ? » est mal posée : les deux objets n'exercent pas le même métier.
ISO/IEC 27001 est un système de management certifiable. Périmètre déclaré, déclaration d'applicabilité, cycle d'audit, organisme accrédité, et un certificat que vous transmettez au service achats de votre client. Sa valeur est en bonne part une valeur de preuve opposable à un tiers.
Le CSF n'a rien de tout cela. Pas de certification, pas d'auditeur, pas de certificat. Ce qu'il apporte est un vocabulaire commun pour décrire des résultats de sécurité et une structure pour arbitrer entre eux. Il excelle à parler à un conseil, à comparer deux filiales qui n'ont ni le même outillage ni le même vocabulaire, à construire une trajectoire à trois ans qui tienne dans une page.
Nous faisons souvent tourner les deux : le CSF comme grille de lecture pour le comité de direction et la feuille de route, l'ISO 27001 sur le périmètre qu'un client exige de certifier. Les correspondances entre les deux sont imparfaites, et ce n'est pas grave : ce qu'on cherche dans un mapping, c'est une direction, pas une équivalence terme à terme.
Ni l'un ni l'autre ne vous dit comment analyser un scénario de risque. EBIOS Risk Manager fait ce travail : des scénarios stratégiques et opérationnels crédibles, avec des sources de risque nommées. Le CSF consomme volontiers ce qu'EBIOS RM produit ; il ne le remplace nulle part.
Un référentiel de résultats, pas un référentiel de contrôles
Lisez une sous-catégorie du CSF. Elle énonce un résultat attendu. Elle ne vous dit pas d'activer le MFA sur les comptes d'administration ni comment journaliser un contrôleur de domaine. Cette abstraction est délibérée : elle permet au même référentiel de s'appliquer à un CHU et à une fintech de quarante personnes. Elle le rend aussi inutilisable tel quel comme plan de mise en œuvre.
Il faut donc l'appareiller avec quelque chose de prescriptif. Les CIS Controls s'y prêtent particulièrement bien, et le CIS a fait le travail dans le bon sens : la version 8.1 des contrôles, publiée en juin 2024, a ajouté une fonction Govern à sa propre taxonomie pour s'aligner sur le CSF 2.0, et publie la correspondance de ses mesures. Dix-huit contrôles, 153 mesures de sécurité, trois groupes d'implémentation ; l'IG1 et ses 56 mesures constituent le point de départ honnête pour la plupart des organisations de taille moyenne.
La répartition des rôles est nette. Le CSF répond à « quel résultat visons-nous, et la direction est-elle d'accord ». Les CIS Controls répondent à « qu'est-ce que je fais lundi matin ». Les CIS Benchmarks répondent à « à quoi ressemble un Windows Server correctement configuré ». Wavatec distribue CIS SecureSuite, lisez donc cet avis comme intéressé ; c'est cette répartition qui nous a conduits à le distribuer, et non l'inverse.
Là où ces évaluations dérapent
La dérive la plus banale est celle de l'auto-évaluation. Un score interne monte tous les ans sans qu'aucun test n'ait été rejoué : le 2,7 devient 3,1 parce que la personne qui remplit le questionnaire a changé de poste, ou parce que l'an dernier elle était d'humeur pessimiste. Un score auto-déclaré et non étayé ne mesure que la confiance en soi de celui qui le déclare.
La règle qui corrige cela est simple et impopulaire : aucune cotation sans artefact. Une sous-catégorie déclarée atteinte doit pointer vers une procédure datée, une capture de configuration, un ticket clos, un compte rendu d'exercice. Si l'artefact ne peut pas être produit en dix minutes, la sous-catégorie n'est pas atteinte : elle est envisagée. Cette seule règle fait chuter le score déclaré de vingt à trente pour cent au premier passage, et rend les passages suivants comparables entre eux — tout l'intérêt de l'exercice.
Deux autres travers reviennent. L'évaluation uniforme, d'abord : instruire 106 sous-catégories à profondeur constante revient à n'en instruire correctement aucune. Creusez les scénarios qui feraient réellement mal, et traitez le reste au déclaratif en l'assumant. Le profil sans propriétaire, ensuite : un profil dont aucune catégorie n'a de responsable nommé est un document, pas un programme ; il sera relu une fois l'an et n'aura rien déplacé.
Reste ce qu'on remonte au conseil. Remplacez le diagramme en toile d'araignée par trois phrases : voici notre profil cible et pourquoi ce niveau-là, voici où nous en sommes et avec quelles preuves, voici les trois écarts que nous finançons cette année. C'est moins joli. C'est vérifiable.
Par où commencer
Prenez le périmètre qui compte le plus, pas l'entreprise entière, et établissez-y un profil courant en appliquant la règle de preuve dès le premier entretien. Cherchez un profil communautaire pour votre secteur avant d'écrire votre cible sur une page blanche. Choisissez un Tier consciemment, et écrivez la phrase qui explique pourquoi celui-là et pas celui du dessus — elle vous sera redemandée. Traduisez chaque écart en mesures CIS, pour que le plan contienne des verbes plutôt que des intentions. Puis refaites l'exercice douze mois plus tard, sous la même règle de preuve : c'est la seule façon d'obtenir une trajectoire au lieu d'une série de photographies incomparables.
C'est le travail que nous conduisons depuis Paris et Aix-en-Provence chez une cinquantaine d'organisations : évaluations de maturité, analyses EBIOS RM, tests d'intrusion, et l'outillage — Elyys360, la plateforme GRC que nous éditons — qui fait survivre un profil au consultant qui l'a écrit.
