Первоначальные намётки по ОСОКА. 🙂 Думаю должно быть три группы метрик:

▪️Базовые
▪️Эксплуатационные
▪️Инфраструктурные

1. Базовые метрики будут ровно такие же как в CVSS v3.0/3.1. Почему? Это текущий стандарт, использующийся с 2015 года. Для большей части уязвимостей из NVD можно будет взять CVSS v3 Base вектор как он есть. Для уязвимостей, у которых доступен только CVSS v2 Base вектор есть более-менее рабочие способы конвертации в v3, которые можно будет взять за основу. Когда CVSS v4 появится в NVD, проблемы с конвертацией v4->v3 будут только из-за исключения метрики Scope, её придется как-то генерить, скорее всего из Impact Met­rics для Sub­se­quent Sys­tems (но это неточно). Также для User Inter­ac­tion будет 3 значения, а не два, но это тривиально схлопывается. В общем, оставаться на базовых метриках полностью повторяющих CVSS v3 нам должно быть достаточно комфортно.

2. Эксплуатационные предлагаю сделать такие:

Exploit Matu­ri­ty: Not Defined (X), High (H), Func­tion­al (F), Proof-of-Con­cept ℗, Unre­port­ed (U) — эту штуку можно заполнять через анализ баз эксплоитов/малварей и получать из CVSS Tem­po­ral вектора некоторых вендоров (например Microsoft).

Exploita­tion Activ­i­ties: Not Defined (X), Report­ed ®, Unre­port­ed (U) — это можно заполнять на основе баз отслеживающих эксплуатацию типа CISA KEV или Attack­erKB. Фактов эксплуатации in the wild никогда не было в CVSS и не будет в 4.0 — преимущество ОСОКи. 😉

Exploita­tion Prob­a­bil­i­ty: Not Defined (X), High (H), Medi­um (M), Low (L) — это можно заполнять на основе EPSS. Я думаю, что EPSS пока ещё полный шлак, но возможно такие системы скоро станут гораздо лучше и неплохо бы заранее их поддержать.

Кажется с такими метриками по эксплуатации можно будет не упахиваться ручным описанием и получить приоритизацию с учётом того, что нужно зафиксить ASAP.

3. Инфраструктурные думаю лучше взять ровно как в методике ФСТЭК, чтобы повысить шансы на официальное признание. 😉 Кроме того, они в принципе неплохие. Во всяком случае всяко лучше абстрактного CVSS Envi­ron­men­tal. Хотя и придется все активы покрыть VM-процессом и знать об активах хотя бы их тип и доступность на периметре.

Тип компонента информационной системы, подверженного уязвимости
- Не определено
- Компоненты ИС обеспечивающие реализацию критических процессов (бизнес-процессов), функций, полномочий
- Серверы
- Телекоммуникационное оборудование, система управления сетью передачи данных
- Рабочие места
- Другие компоненты

Количество уязвимых активов
- Не определено
- Более 70%
- 50–70%
- 10–50%
- Менее 10%

Влияние на эффективность защиты периметра системы, сети
- Не определено
- Уязвимое программное, программно-аппаратное средство доступно из сети «Интернет»
- Уязвимое программное, программно-аппаратное средство недоступно из сети «Интернет»

Конечно, нужно будет конкретные формулировки подправить, чтобы было единообразна с другими метриками, а подробности убрать в руководство по заполнению, но по смыслу должно быть ровно так как в методике ФСТЭК.

Как вам?