В этом году исполнилось 20 лет системе CVSS — Common Vulnerability Scoring System, ставшей общепризнанным стандартом описания уязвимостей. Несмотря на десятилетия использования и четыре поколения стандарта (на сегодня внедрена версия 4.0), рейтингом CVSS продолжают пользоваться неправильно, а вокруг самой системы порой бушуют серьезные споры. Что важно знать о CVSS для эффективной защиты своих ИТ-активов?
База CVSS
Как пишут в документации CVSS разработчики системы, CVSS — инструмент описания характеристик и серьезности уязвимостей в программном обеспечении. CVSS поддерживается форумом специалистов по ИБ и реагированию на инциденты (FIRST) и была создана для того, чтобы эксперты говорили об уязвимостях на одном языке, а данные о программных дефектах было легче обрабатывать автоматически. Практически каждая уязвимость, опубликованная в реестрах уязвимостей (CVE, БДУ, EUVD, CNNVD), содержит оценку серьезности по шкале CVSS.
Эта оценка состоит из двух основных компонентов:
- числовой рейтинг (CVSS score), отражающий серьезность уязвимости по шкале от 0 до 10, где 10 — максимально опасная, критическая уязвимость;
- вектор — стандартизованная текстовая строка, описывающая основные характеристики уязвимости: можно ли ее эксплуатировать по сети или только локально, нужны ли для этого повышенные привилегии, насколько сложно эксплуатировать уязвимость, на какие характеристики уязвимой системы влияет эксплуатация уязвимости (доступность, целостность конфиденциальность) и так далее.
Вот как выглядит в этой нотации опасная и активно эксплуатировавшаяся уязвимость CVE-2021-44228 (Log4Shell):
Base score 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).
Расшифруем: вектор атаки (attack vector) — сетевой, сложность атаки (attack complexity) — низкая, нужные привилегии (privileges required) — никаких, взаимодействие с пользователем (user interaction) — не требуется, влияние на другие компоненты системы (scope) — уязвимость оказывает влияние, воздействие на конфиденциальность, целостность и доступность системы (confidentiality, integrity, availability) — высокое.
Подробные описания каждого компонента доступны в спецификации (CVSS 3.1, CVSS 4.0).
Важной частью системы CVSS является методика вычисления рейтинга, то есть калькулятор (4.0, 3.1). Заполнив все компоненты вектора, можно автоматически получить числовую оценку критичности.
В методике расчета CVSS изначально было три группы метрик: базовые (base), временнЫе (temporal) и контекстные (environmental). В первую входят фундаментальные и неизменные особенности уязвимости, на них основан расчет базового рейтинга CVSS. Вторая группа — особенности, которые со временем могут измениться, например наличие опубликованного кода для эксплуатации уязвимости. Третья группа должна применяться внутри организации, чтобы учесть ее контекстные особенности, такие как область применения уязвимого приложения, наличие смягчающих угрозу средств защиты информации и так далее.
В CVSS 4.0 временные (темпоральные) метрики превратились в метрики угрозы (threat metric) и появилась группа вспомогательных (supplemental) метрик.
Взаимосвязь метрик такова. Эксперты производителя ПО или ИБ-компании оценивают базовую критичность уязвимости (CVSS-B в спецификации 4.0), а также зачастую дают оценку, связанную с наличием и публичностью эксплойта (CVSS-BT в 4.0, temporal в 3.1). Эта оценка является скорректированной базовой, поэтому CVSS-B может быть и выше, и ниже, чем CVSS-BT. Что касается контекстной оценки (CVSS-BTE, environment), то ее вычисляют на основе CVSS-BT в конкретной организации, сделав поправку на свои условия использования уязвимого ПО.
Эволюция CVSS
Первые две версии CVSS вышли в 2005 и 2007 году и на сегодня почти не используются. Оценку по старым методикам CVSS можно найти и для современных уязвимостей, но наиболее распространены CVSS 3.1 (2019) и CVSS 4.0 (2023). Многие производители ПО и реестры уязвимостей не спешат переходить на версию 4.0 и продолжают выдавать оценки CVSS 3.1.
В первой версии CVSS основной идеей было само измерение важности уязвимостей в баллах, первичное разделение на базовые, временные и контекстные метрики. При этом текстовая часть была слабо формализована и три группы метрик рассчитывались по отдельности.
В CVSS 2.0 появилась стандартизованная запись вектора, а также новая логика: обязательный и неизменный базовый рейтинг CVSS; временной рейтинг, который рассчитывается на основе базового, но с учетом меняющихся факторов; и используемый уже в конкретных организациях и условиях контекстный рейтинг, высчитанный из базового или временного.
Версии 3.0 и 3.1 внедрили понятие scope (влияние на другие компоненты системы), более точно определили параметры, касающиеся требуемых привилегий и взаимодействия с пользователем, обобщили и уточнили значения многих параметров, но самое важное — попытались закрепить в спецификации тот факт, что CVSS является мерилом серьезности уязвимости, а не создаваемых ей рисков.
В версии 4.0 авторы постарались сделать метрику более полезной для бизнес-оценки влияния уязвимостей на риски (хотя это по-прежнему не метрика риска). Сложность атаки разделили на два компонента (attack requirements, attack complexity), подчеркивая разницу между инженерной сложностью самой атаки и внешними особенностями и требованиями, без которых атаку невозможно осуществить. На практике это означает, что дефект, для эксплуатации которого уязвимый продукт должен иметь определенную настройку, отключенную по умолчанию, будет иметь более высокие attack requirements и меньший рейтинг CVSS.
Вместо малопонятного многим «влияние на другие компоненты» (scope), которое имело варианты «да» и «нет», разработчики добавили более четкое понятие «связанных систем» с указанием, на какой аспект их работы влияет уязвимость. Также добавили целый ряд вспомогательных индикаторов, таких как возможность автоматизировать эксплуатацию уязвимости и влияние эксплуатации на физическую безопасность людей. Существенно изменились и формулы: влияние компонентов на числовую оценку угрозы переосмыслили на основе огромной базы уязвимостей и данных об их реальной эксплуатации.
Как CVSS 4.0 повлияла на оценку критичности уязвимостей
Для практиков ИБ CVSS 4.0 должна стать полезнее с учетом сложившихся реалий: уязвимостей десятки тысяч, слишком многие из них имеют высокий рейтинг CVSS, поэтому во многих организациях автоматически попадают в список на первоочередное устранение. Список постоянно растет, среднее время устранения уязвимости приближается к 7 месяцам.
При пересчете уязвимостей из CVSS 3.1 в CVSS 4.0 базовая оценка немного растет для дефектов c серьезностью от 4,0 до 9,0, но для уязвимостей, которые были совсем критическими в CVSS 3.1, зачастую оценка не меняется или даже снижается. Что еще важнее, раньше временные метрики мало влияли на числовой рейтинг уязвимости, а теперь влияние метрик threat и environmental более значительно. В Orange Cyberdefense изучили такой пример. Допустим, компания отслеживает 8000 уязвимостей и отделы ИТ и ИБ обязаны устранить в регламентный срок все дефекты с базовой оценкой CVSS выше 8. Какой процент таких дефектов будет среди 8000 реальных уязвимостей, если оценивать их с учетом публичности эксплойтов (поправка temporal/threat) или без него? Получилось, что CVSS 4.0 в базовой версии оценивает на 8 баллов и выше больший процент уязвимостей (33% против 18% в версии 3.1), но с поправкой на наличие эксплойтов число сильно падает и в приоритете остается меньше опасных ошибок (8% против 10%).
Critical, High и все-все-все
Что отличает «критическую» уязвимость от просто опасной? Текстовое описание серьезности является частью спецификации, но указывать эту текстовую часть в описании уязвимости необязательно:
- низкая серьезность (low severity): 0,1–3,9;
- средняя серьезность (medium severity): 4,0–6,9;
- высокая серьезность (high severity): 7,0–8,9;
- критические уязвимости (critical severity): 9,0–10,0.
На практике многие производители ПО применяют текстовое описание творчески, модифицируя названия, а также учитывая в текстовом описании какие-то свои оценки и факторы, не входящие в CVSS. Яркий пример — две уязвимости из июньского Microsoft Patch Tuesday, CVE-2025-33064 и CVE-2025-32710. Первая имеет текстовое описание важности Important, вторая — Critical, при этом рейтинг CVSS 3.1 у первой равен 8,8, а у второй — 8,1.
В следующем посте мы планируем рассказать, какие разночтения и проблемы могут возникнуть при подсчете CVSS, а также какие ошибки совершают при использовании CVSS практики ИБ в организациях и как вообще приоритизировать уязвимости правильно.
Бизнес — Блог Касперского
