Les organisations opèrent rarement dans un cadre de cybersécurité unique.
Un fournisseur SaaS peut avoir besoin de la norme ISO 27001 pour son système de gestion de la sécurité de l'information, de SOC 2 pour satisfaire les attentes des clients, du RGPD pour les obligations de confidentialité et de NIS2 en raison de son secteur ou de sa clientèle. Un fournisseur de défense devra peut-être prendre en compte simultanément le NIST SP 800-171, le CMMC, les exigences contractuelles et ses contrôles ISO existants.
Le problème est que ces frameworks ne sont pas complètement indépendants. Ils demandent fréquemment aux organisations d'effectuer des activités similaires en utilisant une terminologie, des structures et des niveaux de détail différents.
C’est là que le cross-mapping du framework devient précieux.
Toutefois, l’identification d’exigences similaires n’est qu’un début. Pour rendre le mappage croisé fiable, réutilisable et adapté à l'automatisation, les organisations doivent également savoir d'où vient une relation, quelle est sa force, à quelles versions du framework elle s'applique et où subsistent des lacunes importantes.
Deux initiatives du NIST sont particulièrement pertinentes pour relever ce défi : le Programme national de références informatives en ligne, mieux connu sous le nom d'OLIR, et le Modèle de mappage de contrôle OSCAL.
Ils abordent différentes parties du même problème.
Les programmes de conformité traditionnels sont souvent organisés autour de cadres individuels.
Une feuille de calcul contient les contrôles ISO 27001. Un autre suit les exigences NIS2. Un tiers est conservé pour un questionnaire client ou un prochain audit SOC 2. Les preuves, les politiques, les descriptions de contrôle et les notes de mise en œuvre sont copiées entre eux.
Cela permet de traiter facilement chaque nouveau cadre comme un tout nouveau programme de conformité.
Cartographie croisée identifie les exigences communes ou qui se chevauchent afin que les contrôles et les preuves existants, tels que les politiques, les journaux, les captures d'écran et les procédures, puissent être réutilisés le cas échéant. Les avantages pratiques vont au-delà de la réduction du travail en double. La cartographie croisée peut également améliorer la préparation des audits, le reporting, la visibilité des risques et la capacité à répondre aux changements réglementaires.
Le résultat le plus précieux n’est souvent pas le chevauchement lui-même, mais le delta.
Un processus de réponse aux incidents peut prendre en charge les exigences des normes ISO 27001, SOC 2 et NIS2. Cela ne veut pas dire que les exigences sont identiques. Un cadre peut exiger des délais de reporting spécifiques, un autre peut se concentrer sur les responsabilités en matière de gouvernance et un autre peut s'attendre à des preuves particulières lors d'un audit.
Une cartographie utile doit donc répondre à deux questions :
Cette distinction sépare un tableau de correspondance fiable d’un simple tableau de contrôles supposés équivalents.
OLIR signifie Online Informative Reference et fait partie du programme national de références informatives en ligne du NIST.
Le programme permet aux experts en la matière de décrire les relations entre les éléments de leurs propres normes, cadres, produits ou conseils et les éléments des documents NIST pris en charge. Ces documents NIST sont appelés documents focaux et peuvent inclure des publications telles que le NIST Cybersecurity Framework, le NIST SP 800-53 ou le NIST IA Risk Management Framework.
Un OLIR peut, par exemple, connecter une exigence d'un cadre industriel à une sous-catégorie NIST CSF 2.0.
OLIR offre plus qu'une structure de feuille de calcul. Il fournit :
Le NIST distingue trois styles de mappage OLIR : les correspondances conceptuelles, les mappages de relations fondés sur la théorie des ensembles et les mappages de relations de soutien.
Pour les correspondances de conformité détaillées, les mappages fondés sur la théorie des ensembles sont particulièrement intéressants. Au lieu de simplement indiquer que deux exigences sont liées, ils peuvent préciser si l’une est égale à l’autre, en est un sous-ensemble ou un sur-ensemble, ou la recoupe partiellement.
OLIR fournit donc deux éléments qui manquent à de nombreux projets de cartographie internes : un contenu cartographique découvrable et une structure de gouvernance autour de ce contenu.
OSCAL, le langage d'évaluation des contrôles de sécurité ouverts fournit des modèles lisibles par machine pour représenter les catalogues de contrôle, les profils, les plans de sécurité du système, les plans d'évaluation, les résultats d'évaluation et les informations de conformité associées.
Le modèle de cartographie des contrôles OSCAL étend cet écosystème en fournissant une représentation structurée des relations entre les contrôles et les éléments de contrôle provenant de différentes sources documentaires.
Contrairement à une correspondance narrative, le modèle est conçu pour être traité par un logiciel. Il peut être représenté en JSON, YAML ou XML et mapper des contrôles ou des instructions de contrôle individuelles provenant de catalogues et de profils OSCAL.
Ses types de relations comprennent :
equal-toequivalent-tosubset-ofsuperset-ofintersects-withno-relationshipLe modèle peut également décrire si une cartographie était basée sur une similarité syntaxique, une signification sémantique ou un résultat fonctionnel.
Cela est important car deux exigences peuvent sembler similaires tout en produisant des résultats opérationnels différents. À l’inverse, des exigences qui utilisent un langage complètement différent peuvent néanmoins remplir presque la même fonction de sécurité.
Le modèle peut en outre consigner la provenance, les parties responsables, le statut, le niveau de confiance, la couverture, les lacunes et le mode de production manuel, automatique ou hybride du mappage. Il convient ainsi non seulement à l’affichage des correspondances, mais aussi à l’analyse automatisée des écarts, à l’analyse d’impact des changements, à la validation et à la réutilisation dans les flux de conformité.
Il est tentant de se demander si une organisation doit utiliser OLIR ou le modèle de mappage de contrôle OSCAL.
En pratique, ils résolvent différents problèmes.
OLIR est avant tout un programme, un catalogue, un processus de soumission et une source d'assertions de mappage. Il aide les organisations à trouver et à publier des mappages impliquant des documents focaux du NIST.
Le modèle de mappage de contrôle OSCAL est un modèle de données techniques. Il détermine la manière dont les relations de mappage peuvent être stockées, échangées, validées et traitées au sein d'un système.
OLIR peut indiquer à une plateforme qu'un expert ou une organisation a affirmé une relation particulière. OSCAL peut intégrer cette relation dans un système de conformité plus vaste et calculable.
OSCAL a également une portée plus générale. Une collection de cartographie OSCAL peut connecter n’importe quel catalogue ou profil OSCAL approprié. Cela ne se limite pas aux relations impliquant un document focal du NIST.
Cela signifie qu'une organisation peut utiliser OSCAL pour représenter des relations directes telles que :
Ces mappages ne seraient pas nécessairement considérés comme des soumissions OLIR officielles, mais ils pourraient toujours utiliser des concepts de relation comparables et être stockés de manière cohérente via OSCAL.
Une implémentation pratique pourrait traiter OLIR comme l'une des nombreuses sources de mappage externes et OSCAL comme la représentation interne canonique.
Mappages OLIR
Correspondances BSI ou réglementaires
Mappages fournis par les éditeurs
Mappages créés par des experts
Mappages propres aux clients
Suggestions de mappage générées par l’IA
↓
Importation et normalisation
↓
Résolution des référentiels et versions
↓
Collections de mappage OSCAL
↓
Examen, approbation et confiance
↓
Analyse des écarts, réutilisation des preuves et analyse d’impact
Lors de l'importation d'un OLIR, une plate-forme identifierait le document de référence et le document focal, résoudrait leurs identifiants d'éléments par rapport aux catalogues OSCAL correspondants et traduirait chaque relation en une entrée de mappage OSCAL.
L’OLIR original doit rester attaché comme provenance. Les utilisateurs doivent pouvoir voir :
Cela rend les cartographies traçables plutôt que de les traiter comme des faits universels.
L'automatisation crée le risque que les organisations commencent à considérer les mappages comme la preuve qu'une seule implémentation satisfait automatiquement à toutes les exigences associées.
Cette conclusion est rarement justifiée.
Un tableau de correspondance décrit les relations entre les exigences. Il ne prouve pas automatiquement qu’une organisation a mis en œuvre ces exigences de manière efficace.
Les preuves peuvent également être réutilisables sans être suffisantes. Une politique de sauvegarde peut prendre en charge plusieurs frameworks, mais un framework peut en outre nécessiter des tests de restauration, des objectifs de restauration définis, des périodes de conservation spécifiques ou une preuve d'examen par la direction.
Une cartographie croisée fiable nécessite donc :
Les relations dérivées appellent une prudence particulière. OLIR peut générer des mappages de relations dérivées entre deux documents de référence en comparant leur relation avec un document focal commun du NIST. Le NIST les décrit comme des points de départ non autoritatifs, et non comme des correspondances directes vérifiées.
Ils peuvent accélérer l’analyse, mais ils doivent générer des tâches de révision, et non des réclamations de conformité automatiques.
L’argument pratique en faveur de la cartographie croisée est convaincant : les organisations ne devraient pas créer de manière répétée les mêmes contrôles, rassembler les mêmes preuves et maintenir des programmes de conformité déconnectés pour chaque cadre. Un référentiel centralisé et une automatisation évolutive peuvent réduire la duplication et rendre les lacunes plus visibles.
L’étape suivante consiste à rendre ces correspondances portables, versionnées et lisibles par machine.
OLIR peut fournir des connaissances cartographiques existantes, une gouvernance des publications et un moyen de contribuer à de nouveaux mappages orientés NIST. Le modèle de mappage de contrôle OSCAL peut transformer ces relations en objets structurés que les outils de conformité peuvent valider, interroger, étendre et connecter à des flux de travail d'évaluation plus larges.
Chez Secani, nous considérons OSCAL comme le fondement technique canonique. OLIR n'est pas un modèle concurrent, mais une source précieuse qui peut l'enrichir.
L’opportunité à long terme est plus grande que de montrer que deux contrôles se chevauchent. Il s'agit de créer une couche de cartographie fiable qui montre ce qui peut être réutilisé, ce qui reste découvert, pourquoi une relation existe, qui l'a approuvée et comment une mise à jour du cadre affecte le reste du programme de conformité.
C’est ainsi que la cartographie croisée passe d’une collection de feuilles de calcul à une infrastructure de conformité réutilisable.
Secani réunit Scopes, preuves, tâches et agents d’IA dans un espace de travail partagé.
Chaque validateur OSCAL prétend valider OSCAL. Nous avons énuméré les 348 occurrences de contraintes dans les sources du NIST, prouvé ou exclu chacune d'elles, puis effectué la comparaison avec la CLI Java pour de vrai.
OSCAL transforme les documents de conformité en données structurées : huit modèles de documents, trois formats et un écosystème qui devient la norme en matière de réglementation.
Avec la RFC-0024 et les règles consolidées 2026, FedRAMP rend obligatoires les données d'autorisation structurées. Les délais sont échelonnés – la direction est sans ambiguïté.