Руслан Рахметов, Security Vision
Мы уже рассказывали про то, как устроена система оценки уязвимостей CVSS (Common Vulnerability Scoring System). В прошлом обзоре мы рассказали про то, как возник этот стандарт и почему унификация стала удобным инструментом. Способы оценки уязвимостей дополнялись и улучшались, каждая новая версия стандарта стремилась не просто исправить недочеты предыдущей, а сделать оценку уязвимостей более точной, гранулярной и релевантной современному ландшафту угроз. Мы сосредоточимся на самой последней версии, а об эволюции подробно можете почитать у наших партнеров.
- Большая детализация.
Добавлены новые метрики для более тонкой оценки. Например, сложность атаки (Attack Complexity) теперь дополнена требованиями атаки (Attack Requirements, AT), которые описывают предварительные условия для успешной атаки на уязвимый компонент.
- Устранение двусмысленности.
Некоторые метрики из v3.1 были переработаны для большей ясности. Например, метрика «Взаимодействие с пользователем» (UI) теперь имеет значение «Пассивное» (P), когда от пользователя требуется лишь посетить вредоносный сайт, и «Активное» (A), когда нужно выполнить более сложные действия.
- Новые группы метрик.
Это, по сути, более формализованная и расширенная версия «Временных метрик» из v3.1 с дополнением метрики доступности эксплойта (E), метрики «угрозы». Моделирование угроз, которое можно, например, провести в модулях Risk Management (RM) и Compliance Management (CM) Security Vision также использует базу данных угроз, чтобы актуализировать со временем различные показатели. Если же сравнивать с более ранними версиями, то разница еще более ощутима, например, версия 3 приобрела метрику Scope (Область влияния), а в 3.1 были уточнены определения и формулировки для повышения ясности и согласованности оценок, что сделало стандарт еще более удобным и точным.
Переход на CVSS v4.0 будет постепенным, но он знаменует собой важный шаг в эволюции оценки уязвимостей, делая ее более гибкой и информативной для всех участников процесса обеспечения кибербезопасности. Но, несмотря на свою огромную пользу, оценка не является «серебряной пулей» для приоритизации уязвимостей, это оценка серьезности, а не риска. Риск же можно рассчитать количественно как серьезность, умноженная на вероятность. CVSS отлично справляется с оценкой серьезности, но не учитывает реальную вероятность эксплуатации «в дикой природе». Например, уязвимость с оценкой 10.0, которую никто не эксплуатирует, может быть менее рискованной, чем уязвимость с оценкой 7.5, под которую уже существует массовая атакующая кампания.
Большинство баз данных (NVD, CVE) показывают только базовую оценку, которая может быть далека от реальной опасности для вашей конкретной инфраструктуры. CVSS оценивает уязвимости изолированно, но не покажет, как комбинация из трех уязвимостей со средней степенью опасности может привести к полному захвату системы. В процессе управления инцидентами мы называем это цепочкой атаки (Kill-chain), формирование которой является важной частью работы модуля SV SOAR наравне с динамическими плейбуками и ИИ-помощниками.
В процессе инсталляции модулей VS/VM и в ходе эксплуатации мы сталкиваемся с несколькими вопросами заказчиков, приступающих к формализации процессов поиска и устранения уязвимостей.
1) Например, про разницу между CVSS и CVE, можно сказать следующее: CVSS – это система оценки, которая присваивает числовую оценку серьезности (от 0 до 10) для CVE (Common Vulnerabilities and Exposures). Это же в свою очередь уникальный идентификатор для конкретной уязвимости. По сути, это ее «серийный номер» (например, CVE-2021-44228). Проще говоря, CVE – это имя уязвимости, а CVSS – ее рейтинг опасности.
2) CVSS-оценки могут присваивать разные организации. Чаще всего это делает NVD (National Vulnerability Database), которая анализирует CVE. Также оценки могут предоставлять сами производители программного обеспечения, исследователи безопасности или специалисты внутри компании, которые проводят собственный анализ рисков. В России уязвимости также обрабатываются ФСТЭК, которые публикуют отдельные материалы.
3) CVSS не является юридически обязательным стандартом для всех, однако он де-факто стал отраслевым стандартом. Многие регуляторы и стандарты безопасности (например, PCI DSS) требуют наличия процесса управления уязвимостями, где CVSS является ключевым компонентом для оценки и приоритизации.
4) Крупные обновления (как переход с v2 на v3 или с v3.1 на v4.0) происходят раз в несколько лет. За этот процесс отвечает специальная группа в рамках организации FIRST, которая собирает обратную связь от сообщества и адаптирует стандарт к меняющемуся ландшафту киберугроз.
Эти вопросы приводят к периодическому обновлению модулей сканера и управления уязвимостями, за ходом которых вы можете следить в нашем блоге. Именно поэтому современные подходы к управлению уязвимостями дополняются информацией из Threat Intelligence (данные об актуальных угрозах), сведениями о важности активов и бизнес-логикой (в ресурсно-сервисной модели SV AM) и передают данные в центры реагирования для обеспечения устранения последствий инцидентов (например, модуль SV SOAR).
В завершении обзора мы бы хотели также привести пример расчета метрик на конкретной уязвимости в популярной платформе для совместной работы Atlassian Confluence. Она позволяла неаутентифицированному злоумышленнику выполнить произвольный код на сервере.
Вектор для расчета базовой оценки: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
Разберем его по частям:
- Вектор атаки (Attack Vector) – AV:N (Network): уязвимость эксплуатируется путем отправки специально сформированного HTTP-запроса на уязвимый сервер. Атакующему достаточно иметь сетевой доступ к веб-интерфейсу Confluence.
- Сложность атаки (Attack Complexity) – AC:L (Low): атака чрезвычайно проста в исполнении. Вредоносная команда помещается прямо в URL-адрес запроса. Никаких сложных манипуляций или обхода защитных механизмов не требуется.
- Необходимые привилегии (Privileges Required) – PR:N (None): это один из самых опасных сценариев. Для эксплуатации уязвимости не требуется быть авторизованным пользователем системы. Атаку может провести абсолютно любой, кто может «достучаться» до сервера.
- Вмешательство пользователя (User Interaction) – UI:N (None): атака нацелена напрямую на серверное приложение. Участие легитимного пользователя (например, заставить его нажать на ссылку) не требуется.
- Область влияния (Scope) – S:U (Unchanged): это важное отличие от Log4Shell. Несмотря на получение полного контроля над сервером, область влияния считается неизменной. Это означает, что атакующий выполняет код с правами того же пользователя, от имени которого работает само приложение Confluence. Атака не позволяет «выпрыгнуть» из-под контроля приложения и захватить, например, другую виртуальную машину на том же гипервизоре.
Далее идет классическая триада влияния:
- Конфиденциальность (Confidentiality) – C:H (High): получив возможность выполнять код, атакующий может прочитать любые данные, доступные приложению: содержимое всех страниц Confluence, файлы конфигурации, ключи доступа к базам данных и т.д.
- Целостность (Integrity) – I:H (High): атакующий может изменять любые файлы, модифицировать страницы, внедрять вредоносный код или полностью удалять данные.
- Доступность (Availability) – A:H (High): злоумышленник может остановить сервис Confluence, удалить ключевые файлы для его работы или запустить шифровальщик, сделав систему полностью недоступной.
Если ввести эти параметры в калькулятор CVSS, мы получим базовую оценку (Base Score): 9.8 (Критическая), но дополнительно рассмотрим, как на эту оценку влияют временные и контекстные метрики:
- Буквально через день после публикации информации об уязвимости в открытом доступе появились рабочие эксплойты и сканеры для поиска уязвимых серверов, метрика E стала H (High). Это оставило оценку на критическом уровне.
- Однако, когда Atlassian оперативно выпустил исправленные версии, метрика RL стала O (Official), для администраторов это стало сигналом, что существует надежное решение, и итоговая временная оценка для их систем могла быть снижена после установки патча.
- Представим, что в компании «А» сервер Confluence доступен только из внутренней сети и изолирован от интернета, тогда администратор может изменить вектор атаки на MAV:A (Adjacent), что кардинально снизит оценку опасности для их среды.
- В компании «Б» перед сервером Confluence стоит современный Web Application Firewall (WAF), который блокирует подозрительные URL-адреса. Это можно отразить, повысив сложность атаки до MAC:H (High), так как теперь злоумышленнику нужно найти способ обойти WAF.
Оба этих примера показывают, как общая оценка 9.8 превращается в гораздо более низкую и специфичную для конкретной организации. CVSS-BTE (Base + Threat + Environmental), наиболее полная и точная оценка, учитывающая все факторы, учитывает все три группы метрик, о которых мы рассказывали ранее. Этот пример наглядно показывает, почему для точной оценки рисков необходимо использовать все три группы метрик.
Конечно же, наша компания, специализирующаяся на автоматизации процессов, не оставила в стороне и процедуры оценки метрик уязвимостей. Однако, помимо наших инструментов, вы можете также воспользоваться, например, официальным CVSS Калькулятором, поддерживаемый FIRST. Это интерактивный веб-инструмент, где вы можете выбрать значения для каждой метрики (AV, AC, PR и т.д.) и мгновенно получить итоговую базовую, временную и контекстную оценки, а также соответствующий вектор. Использование автоматизированного способа – лучший способ понять взаимосвязь между различными метриками и тем, как они влияют на итоговый результат.
Освоение CVSS — это инвестиция в более зрелый, эффективный и, в конечном счете, более безопасный процесс управления уязвимостями. Это незаменимый инструмент для любого специалиста, работающего с уязвимостями.
.jpg)
.jpg)
