CRML — Язык моделирования киберрисков (Cyber Risk Modeling Language)

Статус: Черновик. Этот проект находится в активной разработке и может изменяться без предварительного уведомления. Мы приветствуем замечания, вопросы и вклад. ⚠️ ВНИМАНИЕ Эта кодовая база в настоящее время разрабатывается в ветке 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-подобный Монте-Карло, Bayesian/QBER, актуарные модели, внутренние платформы), что приводит к дорогостоящим переписываниям и переинтерпретациям.
• Аудиторские доказательства фрагментированы: трудно доказать, «что моделировалось, с какими параметрами, с использованием каких данных и с какими результатами».

CRML решает эту проблему, стандартизируя описание моделей киберрисков и их входов/выходов, чтобы разные движки и организации могли обмениваться и выполнять одну и ту же модель с четкой валидацией и прослеживаемостью.

Почему качественных оценок недостаточно

Качественные методы (красный/желтый/зеленый, «высокий/средний/низкий», оценки зрелости) полезны для коммуникации и расстановки приоритетов, но часто дают сбой, когда требуется:

• Обосновать расходы на безопасность (или новый продукт безопасности), сравнивая ожидаемый риск с инвестициями и без них
• Последовательно сравнивать риски между бизнес-подразделениями, поставщиками или периодами времени
• Показать измеренное снижение риска от средств защиты (а не просто «улучшение состояния»)
• Связать киберриск с корпоративным риском, страхованием и финансовым планированием
• Получить воспроизводимые, готовые к аудиту доказательства того, «как мы рассчитали это число»

Следующая эволюция — это количественное управление рисками: рассмотрение киберриска как оцениваемого распределения результатов, основанного на явных предположениях и данных, вычисляемого повторяемыми методами. Но количественные подходы масштабируются только тогда, когда модели стандартизированы — чтобы их можно было валидировать, проверять, повторно использовать и выполнять в различных инструментах и командах.

Цель CRML — стать этим стандартом: он делает модель переносимой, предположения явными, а результаты воспроизводимыми.

Ключевые возможности

• Моделирование эффективности средств защиты — количественная оценка того, как средства защиты снижают риск (включая эшелонированную оборону)
• Параметризация на основе медиан — прямое указание медиан для логнормальных распределений
• Поддержка нескольких валют — моделирование в разных валютах с автоматической конвертацией
• Автокалибровка — калибровка распределений на основе данных об убытках
• Строгая валидация — проверка с помощью JSON Schema выявляет ошибки до симуляции
• Независимость от реализации — работает с любым совместимым симуляционным движком
• Человекочитаемый YAML — легко читать, проверять и аудировать

Видение (мир, где CRML является стандартом)

Представьте недалекое будущее, в котором CRML так же привычен для работы с рисками, как IaC для инфраструктуры:

• Архитектор безопасности предлагает новую программу контроля, обновляя документы CRML; изменения проходят рецензирование в Git с четкими diffs.
• Команды GRC и аудита могут проследить каждую метрику до валидированной, версионированной модели (входные данные, предположения, сопоставления, выходные данные).
• Различные движки количественной оценки (вендорские платформы, внутренний FAIR Monte Carlo, Bayesian QBER, страховые актуарные модели) потребляют одни и те же документы CRML.
• Изменения фреймворков обрабатываются обновлением каталогов/сопоставлений (также версионированных), а не переписыванием логики модели.
• Организации могут обмениваться моделями с партнерами, страховщиками и регуляторами без отправки электронных таблиц или скриншотов.
• Орган кибербезопасности может публиковать свой ежегодный отчет об угрозах в формате CRML — кодируя более богатые нюансы, чем повествовательные PDF (предположения, распределения, зависимости, базовые уровни контроля и сопоставления) — и в свою очередь получать выгоду от более стандартизированных, машиночитаемых представлений данных от отрасли.

В этом мире киберриск становится воспроизводимым, сопоставимым и автоматизируемым в разных командах, при этом сохраняя методологическое разнообразие.

См. Общая архитектура: wiki/Concepts/Architecture.md

Краткий пример (как выглядит «стандартизированный CRML»)

Типичная организация может хранить CRML вместе с кодом обнаружения и инфраструктуры:

• risk/models/ — сценарии и портфели в CRML
• risk/catalogs/ — версионированные каталоги средств защиты + атак (внутренние или внешние)
• risk/mappings/ — сопоставления телеметрии/средств защиты/угроз с владельцами и историей изменений
• CI запускает crml-lang validate на каждом PR; ночная задача запускает crml simulate и публикует дашборды

Пример фрагмента (иллюстративный):

crml_scenario: "1.0"
meta:
  name: "ransomware-baseline"
  description: "Простая модель риска программ-вымогателей"

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

  # Опционально, средства защиты, ориентированные на угрозы (позиция организации обычно относится к портфелям/оценкам)
  controls:
    - id: "org:iam.mfa"
      effectiveness_against_threat: 0.35