CVSS

CVSS (Common Vulnerability Scoring System) — это открытый стандарт для оценки степени критичности уязвимостей в компьютерных системах, разработанный для обеспечения единообразного подхода к ранжированию угроз информационной безопасности. Система позволяет присвоить каждой уязвимости числовой балл от 0 до 10, где 10 соответствует максимальной критичности, а также предоставляет векторную строку, описывающую характеристики уязвимости. CVSS поддерживается некоммерческой организацией Forum of Incident Response and Security Teams (FIRST) и широко применяется в базах данных уязвимостей, таких как Национальная база уязвимостей США (NVD), а также в системах управления уязвимостями коммерческих и государственных организаций.

История

Первая версия CVSS (v1) была разработана в 2004 году Национальным институтом стандартов и технологий США (NIST) при участии специалистов по кибербезопасности. Основной целью стало создание универсальной метрики, которая заменила бы разрозненные и часто субъективные методы оценки уязвимостей, используемые разными вендорами. В 2005 году управление стандартом перешло к FIRST — международной организации, объединяющей команды реагирования на инциденты информационной безопасности (CSIRT). В 2007 году вышла версия CVSS v2, которая стала де-факто стандартом для оценки уязвимостей на протяжении почти десяти лет. В 2015 году была опубликована CVSS v3, значительно переработанная с учётом критики предшественницы: в неё добавили новые метрики, такие как «Требования к привилегиям» (Privileges Required) и «Взаимодействие с пользователем» (User Interaction), а также изменили шкалу оценки. В 2019 году вышла версия CVSS v3.1, которая уточнила формулировки и правила расчёта, но не изменила базовую логику. В 2023 году FIRST анонсировала работу над CVSS v4.0, которая была опубликована в ноябре 2023 года и включает расширенные метрики для оценки уязвимостей в контексте конкретных сред, а также улучшенную поддержку для Интернета вещей (IoT) и промышленных систем управления (ICS).

Структура и метрики

CVSS основана на трёх группах метрик: Базовые (Base), Временные (Temporal) и Контекстные (Environmental). Каждая группа содержит набор параметров, которые в совокупности формируют итоговый балл.

Базовые метрики

Базовые метрики являются обязательными и описывают неотъемлемые свойства уязвимости, которые не зависят от времени или конкретной среды эксплуатации. Они делятся на две подгруппы: метрики доступности для атаки (Exploitability) и метрики воздействия (Impact).

Метрики доступности для атаки:

• Вектор атаки (Attack Vector, AV): описывает, как злоумышленник может получить доступ к уязвимости. Возможные значения: «Сеть» (Network, N) — атака возможна удалённо через сеть; «Смежная сеть» (Adjacent Network, A) — требуется доступ к той же локальной сети; «Локальный доступ» (Local, L) — требуется физический или логический доступ к системе; «Физический доступ» (Physical, P) — требуется непосредственный контакт с устройством.
• Сложность атаки (Attack Complexity, AC): оценивает условия, необходимые для эксплуатации уязвимости. Значения: «Низкая» (Low, L) — атака не требует специальных условий; «Высокая» (High, H) — требуются дополнительные шаги, например, манипуляции с памятью или наличие определённой конфигурации.
• Требуемые привилегии (Privileges Required, PR): указывает, какой уровень доступа нужен злоумышленнику. Значения: «Нет» (None, N) — привилегии не требуются; «Низкие» (Low, L) — требуется базовый пользовательский доступ; «Высокие» (High, H) — требуется административный доступ.
• Взаимодействие с пользователем (User Interaction, UI): определяет, требуется ли участие другого человека (например, жертвы). Значения: «Нет» (None, N) — атака возможна без действий пользователя; «Требуется» (Required, R) — пользователь должен выполнить действие, например, перейти по ссылке или открыть файл.
• Область действия (Scope, S): оценивает, может ли уязвимость повлиять на компоненты, выходящие за пределы изначально скомпрометированной зоны безопасности. Значения: «Неизменная» (Unchanged, U) — воздействие ограничено тем же компонентом; «Изменённая» (Changed, C) — уязвимость может затронуть другие компоненты системы.

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

• Конфиденциальность (Confidentiality, C): степень утечки данных. Значения: «Нет» (None, N); «Низкая» (Low, L) — частичное раскрытие; «Высокая» (High, H) — полное раскрытие.
• Целостность (Integrity, I): степень возможности модификации данных. Значения: «Нет» (None, N); «Низкая» (Low, L) — частичная модификация; «Высокая» (High, H) — полная модификация.
• Доступность (Availability, A): степень нарушения работы системы. Значения: «Нет» (None, N); «Низкая» (Low, L) — частичная потеря производительности; «Высокая» (High, H) — полная потеря доступности.

Временные метрики

Временные метрики являются необязательными и отражают текущее состояние уязвимости в зависимости от времени. Они включают:

• Зрелость эксплойта (Exploit Code Maturity, E): насколько готов код для эксплуатации. Значения: «Не определён» (Not Defined, X); «Теоретический» (Unproven, U); «Доказательство концепции» (Proof-of-Concept, P); «Функциональный» (Functional, F); «Высокий» (High, H).
• Уровень исправления (Remediation Level, RL): наличие патча или обходного решения. Значения: «Не определён» (X); «Официальное исправление» (Official Fix, O); «Временное исправление» (Temporary Fix, T); «Обходное решение» (Workaround, W); «Недоступно» (Unavailable, U).
• Достоверность отчёта (Report Confidence, RC): степень подтверждения существования уязвимости. Значения: «Не определён» (X); «Неизвестный» (Unknown, U); «Разумный» (Reasonable, R); «Подтверждённый» (Confirmed, C).

Контекстные метрики

Контекстные метрики позволяют адаптировать оценку под конкретную среду эксплуатации. Они включают переопределение базовых метрик воздействия (например, если в организации конфиденциальность важнее доступности), а также метрики, связанные с требованиями безопасности (Security Requirements, CR, IR, AR) — пониженные, средние или высокие требования к конфиденциальности, целостности и доступности соответственно. Контекстные метрики применяются для пересчёта базового балла с учётом специфики организации.

Расчёт балла

Итоговый балл CVSS рассчитывается по математической формуле, которая варьируется в зависимости от версии. В CVSS v3.1 базовый балл вычисляется на основе подоценок доступности для атаки (Exploitability Subscore) и воздействия (Impact Subscore). Формула включает взвешивание метрик и применение корректирующих коэффициентов, таких как коэффициент области действия (Scope). Балл округляется до одного знака после запятой. Например, уязвимость с вектором атаки «Сеть», низкой сложностью, без привилегий и без взаимодействия с пользователем, с высоким воздействием на все три аспекта (конфиденциальность, целостность, доступность) и неизменной областью действия получит базовый балл 9.8 (критический). В CVSS v4.0 формула была изменена для более точного учёта сложных сценариев, включая атаки на цепочки поставок и системы с ограниченными ресурсами.

Шкала оценок

В CVSS v3.1 и v3.0 используется следующая шкала для базового балла:

• 0.0: Отсутствие уязвимости (None)
• 0.1–3.9: Низкая (Low)
• 4.0–6.9: Средняя (Medium)
• 7.0–8.9: Высокая (High)
• 9.0–10.0: Критическая (Critical)

В CVSS v4.0 шкала была расширена: добавлен диапазон 0.0–0.1 для «Нет» (None), а также введён новый уровень «Суперкритический» (Supercritical) для баллов 10.0, который присваивается только при определённых комбинациях метрик, например, при возможности удалённого выполнения кода без аутентификации с полным воздействием.

Применение

CVSS используется в следующих областях:

• Управление уязвимостями: организации ранжируют уязвимости по баллу CVSS для определения приоритетов исправления. Например, критические уязвимости (9.0–10.0) обычно требуют немедленного реагирования, в то время как низкие (0.1–3.9) могут быть отложены.
• Базы данных уязвимостей: Национальная база уязвимостей США (NVD) присваивает каждой зарегистрированной уязвимости базовый балл CVSS. Аналогичные базы, такие как российский Банк данных угроз безопасности информации ФСТЭК России, также используют CVSS, хотя могут применять собственные модификации.
• Отчётность: CVSS-вектор и балл включаются в отчёты об инцидентах, бюллетени безопасности вендоров (например, Microsoft, Cisco, Oracle) и в уведомления CERT.
• Страхование киберрисков: страховые компании могут использовать CVSS для оценки рисков и расчёта премий.
• Регуляторные требования: в некоторых отраслях (например, в финансовом секторе) регуляторы требуют использования CVSS для оценки уязвимостей в рамках стандартов безопасности, таких как PCI DSS.

Критика

CVSS подвергается критике по нескольким причинам:

• Субъективность: несмотря на формализацию, выбор значений метрик (например, сложности атаки) может зависеть от эксперта, что приводит к разным баллам для одной и той же уязвимости.
• Игнорирование контекста: базовый балл не учитывает специфику среды — например, уязвимость в системе управления критической инфраструктурой может иметь более высокий реальный риск, чем в изолированной тестовой среде. Контекстные метрики редко применяются на практике.
• Переоценка воздействия: в CVSS v3.1 высокое воздействие на конфиденциальность, целостность и доступность автоматически даёт высокий балл, даже если уязвимость трудно эксплуатировать. Это может приводить к ложноположительным срабатываниям.
• Недостаточная детализация: шкала из 4–5 уровней (от низкого до критического) считается грубой для точного ранжирования тысяч уязвимостей. В CVSS v4.0 предприняты попытки улучшить гранулярность.
• Игнорирование цепочек атак: CVSS оценивает каждую уязвимость изолированно, не учитывая возможность комбинирования нескольких уязвимостей в одной атаке.

Альтернативы

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

• OWASP Risk Rating Methodology: методология, ориентированная на веб-приложения, с более гибкой оценкой вероятности и воздействия.
• DREAD: модель от Microsoft, оценивающая ущерб, воспроизводимость, эксплуатируемость, затронутых пользователей и обнаруживаемость (в настоящее время редко используется).
• SSVC (Stakeholder-Specific Vulnerability Categorization): система, разработанная CERT/CC, которая учитывает интересы различных заинтересованных сторон (например, вендоров, операторов, конечных пользователей) и позволяет принимать решения о приоритетах на основе более широкого набора факторов, чем CVSS.

Интересные факты

• CVSS v2 до сих пор используется в некоторых старых базах данных и системах, несмотря на официальное прекращение поддержки FIRST в 2015 году.
• В CVSS v4.0 впервые введена метрика «Автоматизация» (Automation), которая оценивает, может ли атака быть полностью автоматизирована (например, с помощью червя).
• В России ФСТЭК рекомендует использовать CVSS v3.1 для оценки уязвимостей, но с учётом национальных особенностей, включая обязательную регистрацию уязвимостей в Банке данных угроз безопасности информации.

Источники

• Forum of Incident Response and Security Teams (FIRST). «Common Vulnerability Scoring System v3.1: Specification Document». 2019.
• Forum of Incident Response and Security Teams (FIRST). «Common Vulnerability Scoring System v4.0: Specification Document». 2023.
• National Institute of Standards and Technology (NIST). «Common Vulnerability Scoring System (CVSS)». NIST Interagency Report 7435. 2004.
• Mell, P., Scarfone, K., Romanosky, S. «A Complete Guide to the Common Vulnerability Scoring System (CVSS)». 2007.
• ФСТЭК России. «Методика оценки угроз безопасности информации». 2021.