Прочитал "Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средств"

Прочитал Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средствПрочитал Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средств

Прочитал "Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средств"

Кто-то может подумать из названия, что это наверное про CVSS. И будет отчасти прав. CVSS v3.0/3.1 это один из компонентов итоговой цифири. Причем не только Base Score. "Итоговый показатель I cvss определяется совокупностью показателей базовых, временных и контекстных метрик применительно к конкретной информационной системе". И все кроме базовых придется накликивать самим. Даже этого было бы достаточно для веселья. Но…

Есть ещё второй компонент "характеризующий влияние уязвимости … на функционирование информационной системы". 🙂 Там про тип уязвимого актива, массовость уязвимости, доступность через Интернет.

В зависимости от итогового значения выдвигаются требования по оперативности исправления. И там есть связь со вторым документом про тестирование обновлений:

"3.4. В случае если уязвимости содержатся в зарубежных программных, программно-аппаратных средствах или программном обеспечении с открытым исходным кодом, решение об установке обновления такого программного обеспечения, программно-аппаратного средства принимается оператором информационной системы с учетом результатов тестирования этого обновления, проведенного в соответствии с Методикой тестирования обновлений безопасности программных, программно-аппаратных средств, утвержденной ФСТЭК России от 28 октября 2022 г., и оценки ущерба от нарушения функционирования информационной системы по результатам установки обновления."

А уж какое там веселье. Ммм… 🙂 Но это как-нибудь в следующий раз.

Какие впечатления:
1. Методика это хорошо. Стандартизация от регулятора должна быть. Описано все просто и понятно.
2. Дополнительные критерии помимо CVSS это хорошо, критерии связанные с инфраструктурой выглядят в целом адекватно.
3. Не увидел учета такого важнейшего фактора как признак Exploita­tion in the wild. Когда я делаю приоритизацию с помощью своего проекта Vul­ris­tics наличие публичного эксплоита и признаков эксплуатации вживую играет наибольшую роль. Если наличие эксплоита ещё как-то учитывается (но кажется недостаточно) в CVSS Tem­po­ral Met­rics, то эксплуатация вживую не отражена совсем. Кстати, давно уже пора делать наш аналог CISA Known Exploit­ed Vul­ner­a­bil­i­ties Cat­a­log.
4. Не увидел учет типа уязвимости. Когда я приоритизирую в Vul­ris­tics тип уязвимости также играет важную роль. Можно сказать, что тип уязвимости опосредованно учитывается в CVSS, но кажется этого также недостаточно.
5. Хочется надеяться, что тестирование обновлений зарубежного ПО и опенсурса мы все же будем не сами делать, а это отсылка к тому самому конкурсу. Так ведь? Да? 🧐

Прочитал "Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средств": 5 комментариев

  1. Уведомление: Не успели решить что же делать с необходимостью откуда-то брать Temporal и Environmental метрики CVSS 3 (3.1) для оценки критичности по ФСТЭК, как грядет CVSS

  2. Уведомление: Расписал таймкоды, комментарии и ссылки на дополнительные материалы для выпуска подкаста "КиберДуршлаг" про Управление Уязвимостями

  3. Уведомление: Как обучать Vulnerability Management-у? | Александр В. Леонов

  4. Уведомление: Темы по управлению уязвимостями для Бауманского курса записывали сегодня вместе с Павлом Поповым | Александр В. Леонов

  5. Уведомление: Методические документы регуляторов, связанные с Управлением Уязвимостями | Александр В. Леонов

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *