crml

Qu'est-ce que crml ?

crml (CRML — Cyber Risk Modeling Language) est un langage déclaratif open source pour la modélisation du risque cyber. Il permet de décrire les modèles de risque, cartographies de télémétrie, pipelines de simulation, dépendances et sorties requises au format YAML/JSON — sans imposer une méthode de quantification, un moteur de simulation ou un framework de contrôles/menaces spécifique.

Le projet est conçu pour supporter les workflows « Risk as Code », où les hypothèses et définitions de modèles vivent dans des artefacts versionnés et vérifiables (ex. dans Git). Cela vise à rendre les modèles de risque cyber plus faciles à valider, reproduire et échanger entre équipes et outils en standardisant la représentation des entrées, hypothèses et sorties.

Fonctionnalités clés

• Descriptions de modèles déclaratives YAML/JSON : Exprimez les modèles de risque et leurs exigences d'exécution dans un format portable plutôt que d'intégrer la logique dans des tableurs ou outils ponctuels.
• Spécification de simulation indépendante du moteur : Définissez les pipelines de simulation et dépendances pour que différents moteurs de simulation consomment la même définition de modèle (tant qu'ils sont conformes à CRML).
• Cartographies indépendantes des frameworks de contrôles/attaques : Représentez les cartographies vers les contrôles et attaques sans verrouiller le modèle à un framework ou catalogue unique, ce qui aide lors de l'évolution des frameworks.
• Modélisation de l'efficacité des contrôles : Modélisez comment les contrôles réduisent le risque, y compris les hypothèses de « défense en profondeur ».
• Paramétrage basé sur la médiane pour distributions lognormales : Spécifiez directement les médianes pour les distributions lognormales, en alignement avec la paramétrisation des distributions de risque dans l'approche CRML.
• Validation stricte via JSON Schema : Validez les documents de modèle avant simulation pour détecter les erreurs structurelles précocement.

Comment utiliser crml

1. Récupérer le projet et la documentation : Commencez par le dépôt (README et docs inclus via le contenu du repo) et installez le package disponible sur PyPI.
2. Écrire un document CRML : Créez un document YAML/JSON décrivant les éléments de modèle à exécuter — comme les cartographies de télémétrie, dépendances, structure du pipeline de simulation et exigences de sortie.
3. Valider le document : Utilisez la validation basée sur schéma du projet pour vérifier les erreurs avant de lancer les simulations.
4. Exécuter avec un moteur compatible : Lancez le modèle via un pipeline de simulation compatible avec CRML. Comme CRML est conçu pour être indépendant du moteur, le même document CRML peut être réutilisé avec différents moteurs conformes.

Cas d'usage

• Rendre les modèles de risque vérifiables dans Git : Convertissez les hypothèses de modèles basées sur tableurs ou présentations en documents CRML versionnés pour que les changements soient visibles dans les diffs et auditables.
• Standardiser l'échange de modèles entre équipes : Partagez un modèle de risque défini en CRML unique entre analystes et outils pour une interprétation cohérente des entrées/hypothèses/sorties.
• Comparaison de risques quantifiés avec hypothèses explicites : Lancez des scénarios comme « avec vs. sans investissement » ou « sur différentes périodes » tout en gardant les hypothèses explicites et liées à des définitions de modèles validées.
• Cartographier le risque cyber vers des workflows d'entreprise : Utilisez la représentation standardisée d'entrées/sorties de CRML pour assurer la traçabilité quand les métriques cyber alimentent les processus de risque d'entreprise et de planification financière.
• Évoluer les cartographies avec les changements de frameworks : Quand les frameworks de contrôles ou menaces (ex. ATT&CK, NIST, ISO ou catalogues internes) évoluent, mettez à jour les cartographies CRML plutôt que de réécrire la logique de modélisation spécifique au moteur.

FAQ

• crml est-il prêt pour la production ? Le dépôt indique que le statut du projet est Draft et qu'il est en développement intensif avec des changements possibles sans préavis. La branche de développement active est crml-dev-1.3.

• Quel format crml utilise-t-il pour définir les modèles ? CRML utilise un format YAML/JSON pour décrire les modèles de risque, cartographies de télémétrie, pipelines de simulation, dépendances et exigences de sortie.

• crml impose-t-il une méthode de quantification du risque spécifique ? Non. Il est conçu pour être implementation-agnostic et engine-agnostic, afin de décrire les modèles sans imposer une méthode de quantification ou un moteur de simulation spécifique.

• Comment crml réduit-il les erreurs de modélisation ? Il supporte une validation stricte via JSON Schema pour détecter les erreurs dans les documents de modèle avant simulation.

• Où le projet est-il distribué ? Les métadonnées du dépôt indiquent qu'il est disponible sur PyPI.

Alternatives

• Modélisation du risque cyber basée sur tableurs ou diapositives : Courante pour les travaux qualitatifs ou semi-quantitatifs, mais ces formats sont plus difficiles à valider et à reproduire de manière cohérente par rapport à une approche déclarative avec validation de schéma.
• Implémentations de modélisation du risque cyber spécifiques à un moteur : Les outils qui intègrent les hypothèses et la logique de simulation directement dans des formats de modèles propriétaires peuvent être plus étroitement intégrés, mais nécessitent souvent des réécritures lors du changement de moteurs quantitatifs ou de la mise à jour des cartographies.
• Formats de configuration déclarative génériques (par exemple, fichiers de configuration de modèles) : Vous pouvez utiliser des formats génériques pour externaliser les paramètres, mais ils ne fournissent généralement pas la structure spécifique au risque cyber de CRML pour la cartographie de télémétrie, les pipelines de simulation et les sorties standardisées.
• Autres approches de modélisation « Risk as Code » : Les approches qui versionnent les hypothèses et paramètres peuvent améliorer la révisabilité, mais ne sont pas forcément conçues spécifiquement pour la modélisation du risque cyber dans des contextes de contrôles/attaques et de moteurs.