CRML (Cyber Risk Modeling Language)

What is CRML (Cyber Risk Modeling Language)?

CRML, the Cyber Risk Modeling Language, is an open-source, declarative specification built to address the fragmentation and inconsistency plaguing modern cyber risk quantification. It provides a standardized YAML/JSON format for defining complex cyber risk models, including telemetry mappings, simulation pipelines, control dependencies, and required outputs. The core philosophy behind CRML is to enable Risk as Code (RaC), transforming risk and compliance assumptions into versioned, reviewable, and executable artifacts that can be consistently validated across different teams and tools.

This language acts as an abstraction layer, decoupling the model definition from the execution engine. This means organizations are no longer locked into proprietary tools or specific quantification methodologies, such as FAIR Monte Carlo engines or Bayesian/QBER approaches. By standardizing the model description, CRML ensures that the same risk scenario, defined with explicit assumptions, can be reliably executed across various compliant simulation platforms, drastically improving auditability, reproducibility, and the ability to justify security investments based on quantified outcomes.

Key Features

CRML is engineered to bring rigor and standardization to quantitative cyber risk management:

• Engine-Agnostic Design: Works seamlessly with any simulation engine that adheres to the CRML specification, including those supporting FAIR-style Monte Carlo, Bayesian methods, or actuarial models.
• Declarative YAML/JSON Format: Models are described using human-readable YAML or JSON, making them easy to read, review, version control (via Git), and audit.
• Control Effectiveness Modeling: Allows users to explicitly quantify how security controls, including complex defense-in-depth scenarios, reduce overall risk exposure.
• Median-Based Parameterization: Simplifies the input process by allowing direct specification of median values for common distributions like lognormal distributions.
• Strict Validation: Incorporates JSON Schema validation to catch structural and logical errors in the model definition before simulation begins, saving time and preventing flawed results.
• Multi-Currency Support: Facilitates global risk modeling by supporting automatic conversion across different currencies.
• Auto-Calibration: Features mechanisms to calibrate distributions automatically based on provided loss data.

How to Use CRML (Cyber Risk Modeling Language)

Getting started with CRML involves defining your risk model structure using the declarative specification. The workflow generally follows these steps:

1. Define the Model Structure: Create a CRML file (typically YAML) that outlines the risk scenario. This includes defining threat events, loss event frequencies, loss event magnitudes, and the relationships between them.
2. Map Controls and Assumptions: Explicitly define the security controls in scope and quantify their effectiveness (e.g., using reduction factors or probability modifiers) as per the CRML specification.
3. Specify Simulation Requirements: Detail the required outputs, validation checks, and any specific simulation parameters (like the number of Monte Carlo runs or Bayesian priors).
4. Execute with a Compliant Engine: Feed the standardized CRML file into a compatible simulation engine (e.g., a custom FAIR engine or a Bayesian solver). Because the model is standardized, the engine knows exactly how to interpret the inputs and run the calculation.
5. Review and Version: Since the model is now a versioned artifact (like Infrastructure as Code), it can be tracked in source control, reviewed by peers, and used as auditable evidence for risk decisions.

Use Cases

CRML is invaluable for organizations moving beyond qualitative risk assessments toward rigorous, defensible quantification:

1. Justifying Security Spend: Quantifying the Expected Annualized Loss (ALE) reduction achieved by implementing a specific control (e.g., MFA rollout) to justify budget requests to executive leadership or the board.
2. Enterprise Risk Aggregation: Standardizing risk models across disparate business units or geographies, allowing for consistent aggregation and comparison of cyber risk exposure against enterprise-level financial targets.
3. Vendor Risk Management: Creating standardized, machine-readable risk profiles for critical third-party vendors, enabling automated comparison of their security posture against internal benchmarks.
4. Audit and Compliance Traceability: Generating immutable, versioned records that explicitly link the final risk number back to the exact assumptions, control mappings, and data used in the calculation, satisfying strict audit requirements.
5. Modeling Defense-in-Depth: Accurately modeling complex security architectures where multiple overlapping controls mitigate a single threat, ensuring that risk reduction is not double-counted.

FAQ

Q: Is CRML proprietary, or can I use any tool with it? A: CRML is an open-source, declarative language. It is intentionally engine-agnostic. Any simulation platform that implements the CRML specification can process and execute models defined in this format.

Q: What is the relationship between CRML and established frameworks like FAIR? A: CRML is designed to describe models that might be executed using FAIR principles or other methodologies. It standardizes the input and structure of the risk scenario, allowing you to use FAIR concepts (like Threat Event Frequency and Loss Magnitude) within a standardized, portable file format.

Q: Is this project stable for production use? A: The project is currently under heavy development (as noted in the repository). While the core concepts are robust, users should monitor the development branch (crml-dev-1.3) and be prepared for potential breaking changes until the project reaches a stable major release.

Q: How does CRML help with inconsistent control documentation? A: By forcing control effectiveness and defense-in-depth assumptions into the structured YAML/JSON definition, CRML eliminates reliance on inconsistent spreadsheets or narrative documents. Every analyst uses the same machine-readable definition, ensuring consistency in how controls impact the final risk calculation.

Q: Where can I find the official documentation or examples? A: The project maintains documentation, often generated via MkDocs, and includes examples within the repository structure to demonstrate how to define various risk scenarios and control mappings.