CRML — Cyber Risk Modeling Language (Langage de modélisation des risques cyber)

Statut : Projet en chantier. Ce projet est en développement actif et peut changer sans préavis. Nous accueillons les retours, les signalements de problèmes et les contributions. ⚠️ AVERTISSEMENT Ce code est actuellement développé sur la branche crml-dev-1.3. Pour la dernière version en cours et la source de vérité, voir : https://github.com/Faux16/crml/tree/crml-dev-1.3

Version : 1.2

Maintenu par : Zeron Research Labs et CyberSec Consulting LLC

Soutenu par :

• Contributeurs de la communauté et premiers adoptants

CRML est un langage ouvert, déclaratif, indépendant du moteur et indépendant des cadres de contrôle/attaque pour la modélisation des risques cyber. Il fournit un format YAML/JSON pour décrire des modèles de risque cyber, les correspondances de télémétrie, les pipelines de simulation, les dépendances et les exigences de sortie — sans vous enfermer dans une méthode de quantification spécifique, un moteur de simulation, ou un catalogue de contrôles/menaces.

CRML permet le RaC (Risk as Code) : les hypothèses de risque et de conformité deviennent des artefacts versionnés et vérifiables qui peuvent être validés et exécutés de manière cohérente entre équipes et outils.

Problème résolu (ce que CRML résout)

Les professionnels de la cybersécurité, de la conformité et de la gestion des risques sont souvent confrontés aux mêmes problèmes pratiques :

• Les modèles de risque sont enfermés dans des feuilles de calcul, des présentations ou des outils propriétaires, ce qui les rend difficiles à examiner, auditer, reproduire et automatiser.
• Les hypothèses d’efficacité des contrôles et de « défense en profondeur » sont documentées de manière incohérente, de sorte que les résultats varient selon l’analyste et le trimestre.
• Les cadres de menaces et de contrôles (par ex. ATT&CK, CIS, NIST, ISO, SCF, catalogues internes) évoluent dans le temps ; ne fournissent pas un format lisible par machine cohérent ; les correspondances sont fragiles et rarement versionnées.
• Les moteurs de quantification diffèrent (Monte Carlo de type FAIR, Bayesian/QBER, modèles actuariels, plateformes internes), ce qui entraîne des réécritures et réinterprétations coûteuses.
• Les preuves prêtes pour l’audit sont fragmentées : « ce qui a été modélisé, avec quels paramètres, en utilisant quelles données, et produisant quelles sorties » est difficile à prouver.

CRML répond à cela en normalisant la description des modèles de risque cyber et de leurs entrées/sorties, afin que différents moteurs et organisations puissent échanger et exécuter le même modèle avec une validation et une traçabilité claires.

Pourquoi les évaluations qualitatives ne suffisent pas

Les méthodes qualitatives (rouge/ambre/vert, « élevé/moyen/faible », scores de maturité) sont utiles pour la communication et la priorisation, mais elles tendent à montrer leurs limites lorsque vous devez :

• Justifier les dépenses de sécurité (ou un nouveau produit de sécurité) en comparant le risque attendu avec et sans l’investissement
• Comparer les risques de manière cohérente entre unités commerciales, fournisseurs ou périodes
• Montrer la réduction mesurée du risque grâce aux contrôles (et pas seulement « une posture améliorée »)
• Relier le risque cyber au risque d’entreprise, à l’assurance et à la planification financière
• Produire des preuves reproductibles et prêtes pour l’audit de « comment nous avons calculé ce nombre »

La prochaine évolution est la gestion quantifiée des risques : traiter le risque cyber comme une distribution estimable de résultats, fondée sur des hypothèses et des données explicites, et calculée par des méthodes reproductibles. Mais les approches quantifiées ne passent à l’échelle que si les modèles sont standardisés — afin qu’ils puissent être validés, revus, réutilisés et exécutés à travers les outils et les équipes.

L’objectif de CRML est d’être cette norme : il rend le modèle portable, les hypothèses explicites et les résultats reproductibles.

Fonctionnalités clés

• Modélisation de l’efficacité des contrôles — quantifier comment les contrôles réduisent le risque (y compris la défense en profondeur)
• Paramétrage basé sur la médiane — spécifier directement les médianes pour les distributions lognormales
• Support multi-devises — modéliser dans plusieurs devises avec conversion automatique
• Auto-étalonnage — étalonner les distributions à partir de données de pertes
• Validation stricte — la validation par schéma JSON détecte les erreurs avant la simulation
• Indépendant de l’implémentation — fonctionne avec tout moteur de simulation conforme
• YAML lisible par l’humain — facile à lire, revoir et auditer

Vision (un monde où CRML est la norme)

Imaginez un futur proche où CRML est aussi normal pour le travail sur les risques que l’IaC pour l’infrastructure :

• Un architecte sécurité propose un nouveau programme de contrôle en mettant à jour des documents CRML ; le changement est revu par les pairs dans Git avec des diffs clairs.
• Les équipes GRC et d’audit peuvent tracer chaque métrique jusqu’à un modèle validé et versionné (entrées, hypothèses, correspondances, sorties).
• Différents moteurs de quantification (plateformes fournisseurs, FAIR Monte Carlo interne, Bayesian QBER, modèles actuariels d’assurance) consomment tous les mêmes documents CRML.
• Les changements de cadre sont gérés en mettant à jour les catalogues/correspondances (également versionnés), plutôt qu’en réécrivant la logique du modèle.
• Les organisations peuvent échanger des modèles avec leurs partenaires, assureurs et régulateurs sans envoyer de feuilles de calcul ou de captures d’écran.
• Une autorité de cybersécurité peut publier son rapport annuel sur le paysage des menaces au format CRML — encodant une nuance plus riche que des PDF narratifs (hypothèses, distributions, dépendances, lignes de base de contrôles et correspondances) — et bénéficier en retour de soumissions de données plus standardisées et lisibles par machine de la part de l’industrie.

Dans ce monde, le risque cyber devient reproductible, comparable et automatisable entre les équipes — tout en permettant la diversité méthodologique.

Voir Architecture générale : wiki/Concepts/Architecture.md

Petit exemple (à quoi ressemble un CRML « standardisé »)

Une organisation typique pourrait conserver CRML aux côtés du code de détection et d’infrastructure :

• risk/models/ — scénarios et portefeuilles en CRML
• risk/catalogs/ — catalogues de contrôles et d’attaques versionnés (internes ou externes)
• risk/mappings/ — correspondances télémétrie/contrôle/menace avec historique de propriété et de modifications
• CI exécute crml-lang validate sur chaque PR ; un travail nocturne exécute crml simulate et publie des tableaux de bord

Exemple d’extrait (illustratif) :