CRML — サイバーリスクモデリング言語

ステータス: ドラフト。このプロジェクトは活発に開発中であり、予告なく変更される可能性があります。 インプット、問題報告、コントリビューションを歓迎します。 ⚠️ 警告 このコードベースは現在 crml-dev-1.3 ブランチで開発されています。最新の作業中コードと正本については、次を参照してください: https://github.com/Faux16/crml/tree/crml-dev-1.3

バージョン: 1.2

メンテナー: Zeron Research Labs および CyberSec Consulting LLC

サポート:

• コミュニティのコントリビューターとアーリーアダプター

CRMLは、オープンで宣言的な、エンジン非依存かつコントロール/アタックフレームワーク非依存のサイバーリスクモデリング言語です。サイバーリスクモデル、テレメトリマッピング、シミュレーションパイプライン、依存関係、出力要件を記述するためのYAML/JSON形式を提供し、特定の定量化手法、シミュレーションエンジン、セキュリティコントロール/脅威カタログに強制することはありません。

CRMLは**RaC（Risk as Code）**を可能にします。リスクとコンプライアンスの前提はバージョン管理され、レビュー可能な成果物となり、チームやツールをまたいで一貫して検証・実行できます。

問題提起（CRMLが解決すること）

サイバーセキュリティ、コンプライアンス、リスク管理の専門家は、しばしば同じ実際的な問題に直面します:

• リスクモデルがスプレッドシート、プレゼンテーション資料、またはプロプライエタリなツールに閉じ込められており、レビュー、監査、再現、自動化が困難です。
• コントロールの有効性と「多層防御」の前提が一貫して文書化されていないため、結果がアナリストや四半期ごとに異なります。
• 脅威およびコントロールのフレームワーク（例: ATT&CK、CIS、NIST、ISO、SCF、内部カタログ）は時間とともに変化し、一貫した機械可読形式を提供せず、マッピングは脆く、バージョン管理されることはほとんどありません。
• 定量化エンジンは異なります（FAIRスタイルのモンテカルロ、ベイズ/QBER、保険数理モデル、内部プラットフォーム）ため、コストのかかる書き直しと再解釈が発生します。
• 監査対応の証拠が断片化しています。「何が、どのパラメータで、どのデータを使ってモデル化され、どの出力が生成されたのか」を証明するのは困難です。

CRMLは、サイバーリスクモデルとその入出力の記述を標準化することでこれに対処し、異なるエンジンや組織が同じモデルを明確な検証とトレーサビリティのもとで交換・実行できるようにします。

定性的評価だけでは不十分な理由

定性的手法（赤/黄/緑、「高/中/低」、成熟度スコア）は、コミュニケーションや優先順位付けには有用ですが、以下の場合には機能しなくなる傾向があります:

• 投資を行う場合と行わない場合の予想リスクを比較して、セキュリティ支出（または新しいセキュリティ製品）を正当化する
• 事業部、ベンダー、期間をまたいでリスクを一貫して比較する
• コントロールによるリスク削減の測定値を示す（単なる「態勢改善」ではなく）
• サイバーリスクをエンタープライズリスク、保険、財務計画に結び付ける
• 「この数値をどのように計算したか」という再現可能で監査対応の証拠を生成する

次の進化は定量化されたリスク管理です。サイバーリスクを、明示的な前提とデータに基づき、再現可能な方法で計算される推定可能な結果の分布として扱います。しかし、定量化アプローチがスケールするのは、モデルが標準化されている場合だけです。つまり、ツールやチームをまたいで検証、レビュー、再利用、実行ができるようにする必要があります。

CRMLの目標は、この標準となることです。モデルをポータブルに、前提を明示的に、結果を再現可能にします。

主な機能

• コントロール有効性のモデリング — コントロールがリスクをどの程度削減するかを定量化（多層防御を含む）
• 中央値ベースのパラメータ化 — 対数正規分布の中央値を直接指定
• 多通貨サポート — 自動換算による複数通貨でのモデリング
• 自動キャリブレーション — 損失データから分布を較正
• 厳格な検証 — JSON Schema検証によりシミュレーション前にエラーを検出
• 実装非依存 — あらゆる準拠シミュレーションエンジンで動作
• 人間が読みやすいYAML — 読み取り、レビュー、監査が容易

ビジョン（CRMLが標準となる世界）

IaCがインフラにとって当たり前であるように、CRMLがリスク業務にとって当たり前となる近い未来を想像してみてください:

• セキュリティアーキテクトがCRMLドキュメントを更新して新しいコントロールプログラムを提案し、その変更は明確な差分をもってGitでピアレビューされます。
• GRCおよび監査チームは、すべてのメトリクスを検証済みでバージョン管理されたモデル（入力、前提、マッピング、出力）まで遡って追跡できます。
• 異なる定量化エンジン（ベンダープラットフォーム、内部FAIRモンテカルロ、ベイズQBER、保険数理モデル）がすべて同じCRMLドキュメントを消費します。
• フレームワークの変更は、モデルロジックを書き直すのではなく、カタログ/マッピング（これもバージョン管理）を更新することで処理されます。
• 組織は、スプレッドシートやスクリーンショットを送信せずに、パートナー、保険会社、規制当局とモデルを交換できます。
• サイバーセキュリティ当局は、年間の脅威レポートをCRMLで公開できます。これにより、文章によるPDFよりも豊かなニュアンス（前提、分布、依存関係、コントロールベースライン、マッピング）をエンコードでき、さらに業界からより標準化された機械可読なデータ提出を受ける恩恵も得られます。

その世界では、サイバーリスクは方法論の多様性を保ちながら、チームをまたいで再現可能、比較可能、自動化可能になります。

一般的なアーキテクチャを参照: wiki/Concepts/Architecture.md

短い例（「標準化されたCRML」とはどのようなものか）

一般的な組織では、CRMLを検知コードやインフラコードと一緒に管理するかもしれません:

• risk/models/ — CRML形式のシナリオとポートフォリオ
• risk/catalogs/ — バージョン管理されたコントロール＋攻撃カタログ（内部または外部）
• risk/mappings/ — 所有者と変更履歴を持つテレメトリ/コントロール/脅威マッピング
• CIはすべてのPRで crml-lang validate を実行し、夜間ジョブが crml simulate を実行してダッシュボードを公開します

コード例（例示）:

crml_scenario: "1.0"
meta:
  name: "ransomware-baseline"
  description: "A simple ransomware risk model"

scenario:
  frequency:
    basis: per_organization_per_year
    model: poisson
    parameters:
      lambda: 0.15

  severity:
    model: lognormal
    parameters:
      median: "250 000"
      currency: USD
      sigma: 1.2

  # Optional, threat-centric controls (org posture typically belongs in portfolios/assessments)
  controls:
    - id: "org:iam.mfa"
      effectiveness_against_threat: 0.35

このリポジトリには、2つのPythonパッケージとWeb UIが含まれています:

• crml-lang: 言語/仕様モデル＋スキーマ検証＋YAML IO
• crml-engine: リファレンスランタイム＋crml CLI（crml-langに依存）
• web/: CRML Studio — 検証とシミュレーションのためのブラウザUI（Next.js）

インストール

CLIが必要な場合:

pip install crml-engine

言語ライブラリのみが必要な場合:

pip install crml-lang
# or with SCF support:
pip install "crml-lang[scf]"

クイックスタート（CLI）

crml-lang validate examples/scenarios/qber-enterprise.yaml
crml simulate examples/scenarios/data-breach-simple.yaml --runs 10000

# Import SCF Catalog from Excel
crml-lang scf-import-catalog path/to/SCF_2025.xlsx scf-catalog.yaml

クイックスタート（Python）

読み込みと検証:

from crml_lang import CRScenario, validate

scenario = CRScenario.load_from_yaml("examples/scenarios/data-breach-simple.yaml")
report = validate("examples/scenarios/data-breach-simple.yaml", source_kind="path")
print(report.ok)

シミュレーションの実行:

from crml_engine.runtime import run_simulation

result = run_simulation("examples/scenarios/data-breach-simple.yaml", n_runs=10000)
print(result.metrics.eal)

リポジトリ構成

• crml_lang/ — 言語/仕様パッケージ
• crml_engine/ — リファレンスエンジンパッケージ
• web/ — Web UI（Next.js）
• examples/ — CRML YAMLモデルとFX設定の例
• wiki/ — ドキュメントソース（MkDocs）

CRML Studio

CRML Studioはweb/内にあります。

ローカルで実行する場合:

pip install crml-engine
cd web
npm install
npm run dev

http://localhost:3000 を開いてください。

スクリーンショット

ドキュメント

wiki/ にあるドキュメントを参照してください（wiki/Home.mdから始めてください）。

OSCAL相互運用性とマッピングルール: wiki/Guides/OSCAL.md

SCF統合とマッピングガイド: wiki/Guides/SCF.md

現在のドキュメントタイプ:

• シナリオドキュメント: トップレベルの scenario: を持つ crml_scenario: "1.0"
• ポートフォリオドキュメント: トップレベルの portfolio: を持つ crml_portfolio: "1.0"

ライセンス

MITライセンス — LICENSEを参照してください。