Архив метки: CVSS

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

2 комментария

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

Не успели решить что же делать с необходимостью откуда-то брать Temporal и Environmental метрики CVSS 3 (3.1) для оценки критичности по ФСТЭК, как грядет CVSS 4.0, где всё переделали. 😅 Доступно краткое описание изменений и более детальная презентация. На скрине калькулятора не показали групп Temporal (теперь называется Threat) и Environmental, но они остались в несколько измененном виде. Новая Supplemental Metric Group не влияет на общий расчёт скора CVSS-BTE (Base + Threat + Environmental). Ждем подробностей после 8 июня.

Про CVE_Prioritizer и Vulristics

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

Про CVE_Prioritizer и Vulristics

Про CVE_Prioritizer и Vulristics. Несколько раз за последние месяцы натыкался на посты про CVE_Prioritizer. Но сегодня появился повод прокомментировать.

"CVE_Prioritizer is a powerful tool that helps you prioritize vulnerability patching by combining CVSS, EPSS, and CISA's Known Exploited Vulnerabilities. It provides valuable insights into the likelihood of exploitation and the potential impact of vulnerabilities on your information system."

Прикольная утилита, но, имхо, мой Vulristics приоритизирует покруче. 🙂 Он учитывает не только CVSS, EPSS и CISA KEV, но и тип уязвимости, распространенность софта, информацию об эксплоитах (из многих паков на Vulners) и атаках из AttackersKB.

И CVE_Prioritizer, и Vulristics для каждой уязвимости в динамике выполняют запросы к внешним источникам. Только у CVE_Prioritizer таких источников только 2 и поэтому он отрабатывает быстрее. Кроме того, Vulristics каждый раз в динамике определяет наименование софта и тип уязвимости по описанию. Это медленная операция. А в случае использования Vulners в качестве источника, всё это ещё и стоит денег 💸 (хотя лично мне не стоит, т.к. у меня ресерчерская лицензия - спасибо ребятам из Vulners!❤️). Так что с помощью Vulristics достаточно удобно оценивать 100-200 уязвимостей за раз (как в MS Patch Tuesday), а оценивать больше не особо рационально. 🙁

Что с этим можно сделать? Если заранее формировать полный (и желательно бесплатный/общедоступный 😉) фид по всем уязвимостям, чтобы Vulristics строил отчёт по готовым данным, это было бы гораздо быстрее и эффективнее. В этом случае можно было бы приоритизировать уязвимости хоть для всей инфраструктуры разом. У меня есть в некоторых долгосрочных планах этим заняться. Кто хочет поучаствовать - всегда welcome! 🙂

Чтение произвольных файлов в GitLab (CVE-2023-2825), CVSS Base Score 10 (!)

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

Чтение произвольных файлов в GitLab (CVE-2023-2825), CVSS Base Score 10 (!)
Чтение произвольных файлов в GitLab (CVE-2023-2825), CVSS Base Score 10 (!)Чтение произвольных файлов в GitLab (CVE-2023-2825), CVSS Base Score 10 (!)

Чтение произвольных файлов в GitLab (CVE-2023-2825), CVSS Base Score 10 (!). К счастью, уязвимость существует только в версии 16.0.0 и ранние версии не затронуты. А версия 16.0.0 вышла только 3 дня назад, поэтому пострадали только "ранние пташки".

Неаутентифицированный пользователь может читать произвольные файлы на сервере, когда "an attachment exists in a public project nested within at least five groups" 🤔

Кажется разбираться с этим доп. условием напряжнее, чем просто обновиться.

К слову, вот так выглядит CVSS вектор для Base Score 10: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N, на скриншоте в развернутом виде.

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

7 комментариев

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

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

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

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

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

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

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

Какие впечатления:
1. Методика это хорошо. Стандартизация от регулятора должна быть. Описано все просто и понятно.
2. Дополнительные критерии помимо CVSS это хорошо, критерии связанные с инфраструктурой выглядят в целом адекватно.
3. Не увидел учета такого важнейшего фактора как признак Exploitation in the wild. Когда я делаю приоритизацию с помощью своего проекта Vulristics наличие публичного эксплоита и признаков эксплуатации вживую играет наибольшую роль. Если наличие эксплоита ещё как-то учитывается (но кажется недостаточно) в CVSS Temporal Metrics, то эксплуатация вживую не отражена совсем. Кстати, давно уже пора делать наш аналог CISA Known Exploited Vulnerabilities Catalog.
4. Не увидел учет типа уязвимости. Когда я приоритизирую в Vulristics тип уязвимости также играет важную роль. Можно сказать, что тип уязвимости опосредованно учитывается в CVSS, но кажется этого также недостаточно.
5. Хочется надеяться, что тестирование обновлений зарубежного ПО и опенсурса мы все же будем не сами делать, а это отсылка к тому самому конкурсу. Так ведь? Да? 🧐