Банк данных угроз безопасности информации, включающий базу данных уязвимостей программного обеспечения. Международный подход к выявлению и анализу уязвимостей: CVE и CVSS

8.4. Общая система оценки уязвимостей CVSS

The Common Vulnerability Scoring System (CVSS) - это открытый отраслевой стандарт, используемый для оценки уязвимостей. В 2005 году состоялась публикация первой версии стандарта, в разработке которой участвовали эксперты различных организаций (CERT/CC, Cisco, DHS/MITRE, eBay, IBM Internet Security Systems, Microsoft, Qualys, Symantec). Далее стандарт стал поддерживаться в рамках проекта FIRST (Forum of Incident Response and Security Teams). В 2007 году вышла вторая версия стандарта, в июне 2015 года - третья CVSSv3 - текущая версия.

Использование CVSS для оценки уязвимостей закреплено в различных стандартах, в том числе в PCI DSS.

Для оценки уязвимости CVSS использует три группы метрик ( рис. 8.9):

1. Базовые метрики - это характеристики уязвимости, которые не зависят от среды и не меняются со временем.
2. Временные метрики - это характеристики уязвимости, которые могут измениться со временем.
3. Контекстные метрики - это характеристики уязвимости, которые зависят от среды.

Каждой метрике присваивается значение (например, "высокое"), которое затем соотносится с числовым значением (оценкой) в соответствии с таблицей.

увеличить изображение
Рис. 8.9. Группы метрик CVSS v.3.0

8.4.1. Группа базовых метрик

Вектор атаки (Attack Vector (AV)) - отражает удаленность злоумышленника для использования уязвимости. Числовое значение метрики будет тем больше, чем дальше может находиться злоумышленник, так как в этом случае количество потенциальных злоумышленников возрастает. Метрика может принимать значения: сетевой (можно использовать уязвимость удаленно), соседняя сеть (то есть сеть, которая имеет общую среду передачи с атакуемой сетью), локальный (для эксплуатации злоумышленнику требуется локальная сессия или определенные действия со стороны легитимного пользователя), физический (злоумышленнику требуется физический доступ к уязвимой подсистеме).

Сложность доступа (Access Complexity (AC)) - отражает сложность реализации атаки. Чем легче эксплуатировать уязвимость, тем выше оценка. Значение метрики - высокое, среднее, низкое. Например, уязвимость протокола SSL 3.0 имеет низкую сложность доступа, так как не зависит от конфигурации, используемого ПО и бдительности пользователя. Если для использования уязвимости злоумышленнику нужно собрать какую-то информацию, например, с помощью сниффера - метрика примет среднее значение. Если для использования уязвимости злоумышленнику нужны права администратора в атакуемой системе - метрика примет высокое значение.

Требуемые привилегии (Privileges Required (PR)) - отражает уровень привилегий, которыми должен обладать злоумышленник для использования уязвимости, то есть требуется ли аутентификация и с какими правами. Значение метрики - высокое, среднее, низкое. Чем ниже требуемые привилегии, тем выше будет оценка метрики. Например, для атаки, которая требует для злоумышленника административных прав на атакуемом компьютере, метрика примет высокое значение и низкую оценку.

Взаимодействие с пользователем (User Interaction (UI)) - отражает, может ли злоумышленник использовать уязвимость только по своему желанию или необходимы какие-то действия со стороны пользователя (скачивание программы, переход по ссылке, запуск процесса и т.п.). Метрика принимает значения "нет" и "требуется". Соответственно, если для реализации атаки не требуется участие пользователя, оценка метрики будет высокой.

Масштаб(Scope) - нововведение CVSS v3.0. Метрика показывает, могут ли отличаться уязвимый и атакуемый компоненты, то есть позволяет ли эксплуатация уязвимости нарушить конфиденциальность, целостность и доступность какого-либо другого компонента системы, кроме уязвимого.

Уязвимый компонент (vulnerable component) - тот компонент информационной системы, который содержит уязвимость и подвержен эксплуатации.

Атакуемый компонент (impacted component) - тот, конфиденциальность, целостность и доступность которого могут пострадать при успешной реализации атаки.

В большинстве случаев уязвимый и атакуемый компоненты совпадают, но есть и целые классы уязвимостей, для которых это не так[78].

Например, уязвимость на виртуальной машине, которая позволяет злоумышленнику удалять файлы на ОС хоста (возможно, даже на собственную виртуальную машину). Эта уязвимость затрагивает две области полномочий - одна определяет привилегии для виртуальной машины и ее пользователей, вторая область делает то же самое для хоста. Уязвимость виртуальной машины дает злоумышленнику возможность управлять обеими областями. Метрика принимает значения "неизменяемый" и "изменяемый". Соответственно, для рассмотренного примера она примет значение изменяемый, так как масштаб уязвимости расширяется.

8.4.2. Группа метрик влияния (влияние на конфиденциальность, доступность и целостность)

Каждая из трех метрик может принимать значения "отсутствует", "среднее", "высокое" в зависимости от того, насколько сильно в случае успешного использования уязвимости пострадает конфиденциальность, доступность и целостность атакуемого объекта.

• Зрелость эксплойта (Exploit Code Maturity (E)) - метрика отражает вероятность атаки с использованием уязвимости на основании наличия и возможности использования эксплойтов. Если эксплойт является общедоступным, то число потенциальных атак резко возрастает. В некоторых случаях эксплойт может послужить основой для создания вирусов и сетевых червей.
• Уровень исправления (Remediation Level (RL)) - метрика отражает наличие временного или официального исправления для уязвимости. В случае наличия официального исправления метрика принимает минимальное значение, в случае отсутствия каких-либо исправлений - максимальное.
• Степень достоверности отчета (Report Confidence (RC)) - метрика отражает степень конфиденциальности информации о существовании уязвимости и достоверность известных технических деталей. Риск выше, если о существовании уязвимости достоверно известно. Эта метрика отражает необходимый уровень подготовки потенциальных злоумышленников. Чем подробнее информация об уязвимости, предоставленная производителем или другим источником, тем выше оценка.

8.4.3. Группа контекстных меток

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

Требования к безопасности (требования к конфиденциальности/доступности/целостности) - метрики позволяют "настраивать" оценку CVSS в зависимости от важности ИТ-ресурса, который затрагивает уязвимость, с точки зрения нарушения его конфиденциальности, доступности или целостности. То есть, если ИТ-объект поддерживает бизнес-функцию, для которой доступность является наиболее важной, аналитик может присвоить большую ценность доступности по отношению к конфиденциальности и целостности. Каждое требование безопасности имеет три возможных значения: низкий, средний или высокий. Контекстные метрики требования к безопасности влияют на базовые метрики влияния (влияние на конфиденциальность/целостность/доступность). Например, значение метрики "влияние на конфиденциальность" увеличивается, если значение "требование к конфиденциальности" высокое. Соответственно, значение метрики "влияние на конфиденциальность" уменьшается, если значение метрики "требование к конфиденциальности" низкое. По сути аналитик может создавать измененные базовые метрики в зависимости от конкретного контекста. Например, конфигурация по умолчанию для уязвимого компонента может заключаться в том, чтобы запустить службу прослушивания с правами администратора. При этом в базовых метриках влияние на доступность, конфиденциальность и целостность обозначено как "высокое". Тем не менее, в среде аналитика такой же Интернет-сервис может работать со сниженными привилегиями. Тогда в этом конкретном случае модифицированные метрики влияния на конфиденциальность, доступность и целостность примут значение "низкое".

После того, как базовые метрики определены, с помощью базовой формулы вычисляется оценка угрозы - от 0 до 10 и создается вектор как показано на рис. 8.10:

увеличить изображение
Рис. 8.10. Формирование вектора уязвимости

Вектор - это текстовая строка, отражающая значения каждой метрики для уязвимости. Векторная строка v3.0 начинается с метки "CVSS:" и числового представления текущей версии "3.0". Метрическая информация следует в виде набора показателей, каждой метрике предшествует косая черта "/", действующая как разделитель. Каждая метрика - это метрическое имя в сокращенной форме, двоеточие ":" и связанное с ним значение показателя в сокращенной форме. Все базовые метрики обязательно включаются в вектор ( рис. 8.8).

Например, вектор уязвимости с базовыми метрическими значениями "Attack Vector: Network, Attack Complexity: Low, Privileges Required: High, User Interaction: None, Scope: Unchanged, Confidentiality: Low, Integrity: Low, Availability: None" и отсутствующими временными и контекстными метриками:

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

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

После создания вектора итоговая оценка уязвимости складывается из оценок каждой метрики. Соответствие значений метрик и их оценок можно посмотреть в таблице по ссылке: https://www.first.org/cvss/specification-document