Как ранжировать уязвимости по уровню опасности

Уязвимости, обнаруживаемые в информационных системах, необходимо не только своевременно обнаруживать, но и ранжировать. Это позволит сразу понять, насколько серьёзна проблема, нужно ли решать её незамедлительно или можно отложить. Рассказываем, как это делать правильно.

Информация о новых уязвимостях появляется практически ежедневно. Только в январе 2024 года в базе данных общеизвестных уязвимостей Common Vulnerabilities and Exposures (CVE) зарегистрировано почти пять тысяч новых записей, часть из которых уже подтверждены. Некоторые бреши могут представлять серьёзную опасность для информационной инфраструктуры и требуют немедленных действий, вплоть до отказа от использования каких-то компонентов, а часть являются «проходными». В этом материале поговорим о том, что собой представляет оценка опасности уязвимости, какие компоненты в неё входят и каким образом можно ею управлять.

Оценка критической значимости уязвимостей может проводиться в соответствии с различными методиками:

VPR (Vulnerability Priority Rating — оценка приоритета уязвимости), предложенная компанией Tenable.
CVSS (Common Vulnerability Scoring System — общая система оценки уязвимостей), разработанная форумом команд реагирования на инциденты и обеспечения безопасности (Forum of Incident Response and Security Teams, FIRST).
EPSS (The Exploit Prediction Scoring System — система оценки с прогнозированием эксплойтов), разработана тем же FIRST.
Методика оценки уровня критической значимости уязвимостей программных и программно-аппаратных средств, утверждённая Федеральной службой РФ по техническому и экспортному контролю 28 октября 2022 г.
SSVC (Stakeholder-Specific Vulnerability Categorization Guide — руководство по классификации уязвимостей для конкретных заинтересованных сторон), разработанное Федеральным агентством США по кибербезопасности и защите инфраструктуры (Cybersecurity and Infrastructure Security Agency, CISA).
CCWAPSS (Common Criteria Web Application Security Scoring — общие критерии оценки безопасности веб-приложений), разработанные специалистом по ИБ Фредериком Шарпантье (Frederic Charpentier).

Наиболее популярной из всех перечисленных выше методик является CVSS. Это открытый стандарт оценки серьёзности уязвимостей в системном и прикладном программном обеспечении. Поэтому далее мы поговорим о нём.

1 ноября 2023 года была официально выпущена четвёртая версия CVSS, к которой, однако, сообщество пока не привыкло: она не поддерживается ни поставщиками оценок, ни автоматизированными сканерами. Поэтому будем говорить о версии стандарта 3.1, имеющей практическое применение.

Для оценки серьёзности уязвимостей в версии стандарта CVSS 3.1 используются следующие группы метрик:

Base (базовые) — учитывают внутренние характеристики уязвимости, которые не зависят от пользовательской среды и не меняются со временем (например, требуемый уровень доступа — локальный или сетевой). Включают в себя две подгруппы: метрики эксплуатируемости (Exploitability) и воздействия (Impact).
Temporal (временные) — характеристики уязвимости, которые меняются со временем, но не зависят от пользовательской среды (например, наличие готового эксплойта).
Environmental (метрики среды, или контекстные) — уточняют результирующую оценку серьёзности уязвимости в конкретной среде (например, важность затронутого ИТ-актива для конкретного случая).

Оценка производится в несколько этапов: вначале вычисляется базовая метрика, которая далее уточняется на основе временных метрик и метрик среды. При этом поставщики данных предоставляют только базовые и временные метрики. Аналитику или владельцу информационной системы, который получил отчёт по результатам выявления уязвимостей, остаётся самостоятельно скорректировать оценку на основе метрик среды.

По умолчанию для группы метрик «Temporal» присваиваются значения соответствующие наихудшему варианту конкретной метрики (например, существование готового функционального эксплойта).

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

Контекстная группа метрик включает в себя:

Требования к конфиденциальности, целостности и доступности — позволяют настраивать оценку в зависимости от важности затронутого ИТ-актива для организации (например, система электронной очереди может предъявлять высокие требования к целостности и доступности, но низкие — к конфиденциальности).
Изменённые базовые метрики — группа состоит из тех же метрик, что и базовая (Base), и позволяет пользователю переопределять отдельные метрики в зависимости от характеристик конкретной среды (например, наличие какого-либо средства защиты или какой-либо политики может влиять на сложность атаки).

При этом если изменённая базовая метрика не определена (X), то при расчёте оценки будет использоваться значение исходных базовых метрик, в противном же случае значение базовой метрики будет заменено на то, что указывает оценщик.

Для того чтобы лучше понимать, каким образом производить оценку уязвимостей, рассмотрим подробнее контекстные метрики.

Метрики эксплуатируемости

Modified Attack Vector (MAV) — определяет удалённость (логическую и физическую) злоумышленника, при которой возможна эксплуатация уязвимости.

Modified Attack Complexity (MAC) — наличие условий и обстоятельств, не зависящих от злоумышленника, но требующих от него дополнительных усилий на подготовку и проведение атаки.

Modified Privileges Required (MPR) — уровень привилегий, которыми должен обладать злоумышленник для того, чтобы успешно использовать уязвимость.

Modified User Interaction (MUI) — необходимость каких-либо действий пользователя для успешной реализации атаки.

Modified Scope (MS) — возможность влияния на безопасность смежных компонентов, отличных от собственно уязвимого.

Метрики воздействия

Modified Confidentiality (MC) — влияние на конфиденциальность информации, управляемой уязвимым компонентом.

Modified Integrity (MI) — влияние на целостность информации, управляемой уязвимым компонентом.

Modified Availability (MA) — влияние на доступность информации, управляемой уязвимым компонентом.

Modified Security Requirements (CR, IR, AR) — возможность настроить оценку CVSS в зависимости от важности затронутого ИТ-актива для организации либо требований к конфиденциальности, целостности, доступности конкретной информационной системы, для которой осуществляется оценка уязвимости.

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

Пример № 1

Из-за уязвимости CVE-2024-20698 в Windows 10, 11, Server 2019 и Server 2022 злоумышленник может повысить привилегии до уровня «SYSTEM». Базовые оценки:

CVSS:3.1 7.8 HIGH

CVSS:3.1 / AV:L / AC:L / PR:L / UI:N / S:U / C:H / I:H / A:H

Однако предположим, что в среде функционирования исследуемого экземпляра Windows используются политики запрещающие подключение внешних устройств и доступ в интернет. Это влияет на метрики «Изменённая сложность атаки» (MAC) и «Изменённый вектор атаки» (MAV). Новая оценка критической значимости уязвимости выглядит следующим образом:

CVSS:3.1 6.3 MEDIUM

CVSS:3.1 / AV:L / AC:L / PR:L / UI:N / S:U / C:H / I:H / A:H / CR:X / IR:X / AR:X / MAV:P / MAC:H / MPR:X / MUI:X / MS:X / MC:X / MI:X / MA:X

Таким образом, мы несколько снизили оценку.

Пример № 2

Из-за уязвимости CVE-2024-22198 в Nginx-UI до версии 2.0.0.beta.9 возможны удалённое выполнение кода с проверкой подлинности, повышение привилегий и раскрытие информации. Базовая оценка уязвимости выглядит следующим образом:

CVSS:3.1 8.8 HIGH

CVSS:3.1 / AV:N / AC:L / PR:L / UI:N / S:U / C:H / I:H / A:H

Однако предположим, что данный экземпляр Nginx-UI работает в локальной сети организации, где используются белые списки. Это повлияет на метрики «Изменённая сложность атаки» (MAC), «Изменённый вектор атаки» (MAV) и «Изменённые требуемые привилегии» (MPR). В результате новая оценка критической значимости уязвимости выглядит следующим образом:

CVSS:3.1 6.4 MEDIUM

CVSS:3.1 / AV:N / AC:L / PR:L / UI:N / S:U / C:H / I:H / A:H / CR:X / IR:X / AR:X / MAV:L / MAC:H / MPR:H / MUI:X / MS:X / MC:X / MI:X / MA:X

Таким образом, мы получили значительно более низкую оценку в сравнении с исходной.

Пример № 3

IceWarp 12.0.2.1 / 12.0.3.1 имеет уязвимость CVE-2024-0246, приводящую к межсайтовому скриптингу.

CVSS:3.1 6.1 MEDIUM

CVSS:3.1 / AV:N / AC:L / PR:N / UI:R / S:C / C:L / I:L / A:N

Однако предположим, что с помощью данного экземпляра IceWarp обрабатываются в том числе данные администраторов (пароли, конфиденциальная информация, cookie-файлы), поэтому требования к конфиденциальности и целостности информации в группе метрик среды изменены на «H» (высокий уровень). Тогда мы получим следующую оценку:

CVSS:3.1 7.4 HIGH

CVSS:3.1 / AV:N / AC:L / PR:N / UI:R / S:C / C:L / I:L / A:N / CR:H / IR:H / AR:H / MAV:X / MAC:X / MPR:X / MUI:X / MS:X / MC:X / MI:X / MA:X

Таким образом, при учёте требований к конкретному экземпляру IceWarp в конкретной среде функционирования оценка серьёзности уязвимости выросла со средней до высокой.

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

Как ранжировать уязвимости по уровню опасности

Введение

Что такое группы метрик, зачем они нужны

Почему важны контекстные метрики

Практические примеры использования контекстной метрики

Выводы