Le socle commun des référentiels de sécurité

Les organisations répondent rarement à un seul référentiel de sécurité. Une entreprise de logiciels vend à des clients américains qui réclament un rapport SOC 2 et à des clients européens qui exigent ISO 27001 ; un prestataire de paiement ajoute PCI DSS ; un fournisseur numérique européen relève désormais de NIS2. Chaque référentiel arrive avec sa propre structure, sa numérotation et son vocabulaire, et il est tentant d'en conclure qu'il faut un programme distinct pour chacun.

C'est faux. Sous la diversité des numérotations se cache un large socle commun, dont une petite partie est partagée par chaque référentiel que nous cartographions. Nous avons recherché les sujets qui disposent d'une exigence correspondante dans les onze : NIST CSF 2.0, NIST SP 800-53, ISO 27001, CIS Controls, SOC 2, PCI DSS, CMMC Level 2, la règle de sécurité HIPAA, RGPD (GDPR), NIS2 et l'Essential Eight de l'ASD.

Les cinq sujets présents dans tous les référentiels

Sujet	ISO 27001	SOC 2	PCI DSS	NIS2
Gestion des actifs	A.5.9	CC6.1	12.5.1	12.4
Gestion des vulnérabilités	A.8.8	CC7.1	6.3.1	6.5
Sauvegarde et restauration	A.8.13	A1.2	9.4.1.1	4.2
Réponse aux incidents	A.5.24	CC7.4	12.10.1	3.1
Notification	A.5.5	CC2.3	12.10.1	3.3

5 thèmes sur 50 ont une exigence mise en correspondance dans l'ensemble des 11 référentiels. Chaque page de thème répertorie les identifiants d'exigences de chaque référentiel ainsi que les éléments justifiant chaque lien.

C'est le socle commun : gestion des actifs, gestion des vulnérabilités, sauvegarde et restauration, réponse aux incidents et notification des incidents. Chacun des onze référentiels comporte au moins une exigence pour chacun de ces sujets, y compris le RGPD, qui est une loi sur la protection de la vie privée, et l'Essential Eight, qui est une courte liste de mesures techniques d'atténuation.

La liste est volontairement courte. De nombreux autres sujets, comme la gestion des accès, la journalisation ou le chiffrement, sont couverts par dix des onze référentiels, et la plupart partagent bien plus que cinq sujets. Mais ces cinq-là sont ceux qu'aucun référentiel n'omet.

Pourquoi ces cinq

Ils suivent le cycle de vie d'un incident. On ne peut pas protéger ce qu'on ignore posséder (gestion des actifs). La plupart des attaques exploitent encore des faiblesses connues (gestion des vulnérabilités). Quand quelque chose tourne mal, il faut restaurer les systèmes et les données (sauvegarde et restauration), traiter l'incident (réponse aux incidents) et informer ceux qui doivent savoir : la direction, les clients, les régulateurs (notification des incidents).

Les référentiels divergent sur presque tout le reste : la gouvernance doit-elle être un système de management ou un ensemble de résultats, dans quelle mesure les contrôles techniques doivent-ils être prescriptifs, à quelle fréquence les actions doivent-elles être menées. Sur ces cinq points, ils s'accordent, car sans eux le reste ne fonctionne pas.

Même sujet, profondeur différente

Un sujet commun ne signifie pas une exigence identique. Prenons la gestion des vulnérabilités :

Référentiel	Gestion des vulnérabilités	Lien
NIST CSF 2.0	ID.RA-01ID.RA-08	Définition du sujet
ISO 27001	A.8.8	Correspondance
CIS v8.1	CIS 7.1CIS 7.2CIS 7.5CIS 7.6CIS 7.7CIS 16.6CIS 18.1CIS 18.2CIS 18.3CIS 18.4CIS 18.5	Correspondance
SOC 2	CC7.1	Éditorial
PCI DSS	6.3.111.3.111.3.2	Correspondance
CMMC	RA.L2-3.11.2RA.L2-3.11.3	Correspondance
800-53	RA-5CA-8	Correspondance
HIPAA	§164.308(a)(1)(ii)(A)§164.308(a)(1)(ii)(B)§164.308(a)(8)	Correspondance
GDPR	Art.32(1)(d)	Éditorial
NIS2	6.56.10	Correspondance
Essential Eight	ISM-1807ISM-1808ISM-1698ISM-1699ISM-1701ISM-1702	Éditorial

Détail complet et raison de chaque lien : Gestion des vulnérabilités dans les référentiels →

L'A.8.8 de l'ISO 27001 demande d'obtenir des informations sur les vulnérabilités techniques, d'évaluer son exposition et de prendre les mesures appropriées, et laisse le délai à l'appréciation de votre évaluation des risques. PCI DSS exige des analyses internes tous les trois mois et après des changements significatifs (11.3.1), des analyses externes réalisées par un Approved Scanning Vendor (11.3.2), et l'application des correctifs de criticité critique et élevée dans le mois suivant leur publication (6.3.3). L'Essential Eight fixe des délais de correctifs qui se resserrent à chaque niveau de maturité. HIPAA aborde le sujet par ses exigences d'analyse des risques et de gestion des risques, et non par une exigence spécifique aux vulnérabilités.

Ainsi, le socle commun indique ce que chaque référentiel attend de vous, et non dans quelle mesure. Lorsque vous concevez un contrôle, dimensionnez-le selon le référentiel le plus exigeant auquel vous êtes soumis : les autres suivront généralement.

À quoi cela ressemble en pratique

• Gestion des actifs : un inventaire unique du matériel, des logiciels, des services cloud et des magasins de données, avec leurs propriétaires, maintenu à jour par des outils de découverte et non sur tableur uniquement.
• Gestion des vulnérabilités : analyses planifiées (internes et externes), une évaluation de la criticité, des délais de correction fixés selon la criticité, et des preuves que ces délais sont respectés.
• Sauvegarde et restauration : des sauvegardes des données, des logiciels et de la configuration, protégées contre les modifications et les suppressions, avec des tests de restauration planifiés.
• Réponse aux incidents : un plan écrit définissant les rôles, les niveaux de gravité et l'escalade, testé au moins une fois par an.
• Notification des incidents : une procédure précisant qui doit être informé, dans quel délai et par qui : la direction interne, les clients sous contrat et les régulateurs (par exemple, l'alerte précoce de NIS2 sous 24 heures ou la notification sous 72 heures à l'autorité de contrôle prévue par le RGPD (GDPR)).

Pourquoi le socle compte

Si vous mettez en place un programme de sécurité, construisez d'abord ces cinq éléments. Ce sont les exigences que vous retrouverez dans chaque référentiel que vous pourriez adopter ensuite : le travail n'est donc jamais perdu.

Si vous jonglez déjà avec plusieurs référentiels, utilisez le socle comme colonne vertébrale d'un jeu de contrôles commun : un contrôle pour chacun de ces sujets, mis en correspondance avec chaque référentiel auquel vous êtes soumis, avec des preuves collectées une seule fois. La même logique s'étend aux sujets partagés par dix, neuf ou huit référentiels. Notre matrice de couverture présente les cinquante sujets face aux onze référentiels, et l'analyse d'écarts montre, exigence par exigence, ce qui se transpose d'un référentiel à l'autre.

Comment nous l'avons mesuré

Chaque sujet de ControlMapping est défini par les résultats de NIST CSF 2.0 et répertorie l'exigence de chaque référentiel qui le traite. Un lien est étiqueté « Correspondance » lorsqu'une correspondance publiée (de NIST, de l'ENISA, du CIS ou du PCI SSC) l'étaye, et « Éditorial » lorsqu'il relève de notre appréciation, avec la raison indiquée. Les liens pour SOC 2, le RGPD et l'Essential Eight sont toujours éditoriaux, car aucune correspondance sous licence ouverte n'existe pour eux. La méthode complète figure sur la page méthodologie, et tous les chiffres ci-dessus proviennent des données en ligne, qui sont mises à jour lorsque les correspondances changent.

Questions

Quels contrôles de sécurité sont exigés par tous les référentiels ?

Dans les données de ControlMapping, cinq sujets disposent d'une exigence correspondante dans les 11 référentiels : gestion des actifs, gestion des vulnérabilités, sauvegarde et restauration, réponse aux incidents, et notification des incidents. La formulation et la profondeur varient selon le référentiel.

La conformité à la version d'un référentiel suffit-elle pour les autres ?

Pas automatiquement. Une correspondance signifie que les exigences traitent le même sujet ; l'une peut être bien plus précise (PCI DSS et l'Essential Eight fixent des délais et des fréquences que ISO 27001 vous laisse définir). Vérifiez le texte de chaque référentiel.