Разработчики: Peter Mell, Karen Scarfone, Национальный институт стандартов и технологий, Sasha Romanosky, университет Карнеги Мелон.

Благодарности: Авторы хотят поблагодарить всех членов группы CVSS Special Interest Group, включая Барри Брука, Сез Ханфорд, Става Равива, Гарин Рейд, Джорджа Тила и Тадаши Ямагиши, а также авторов стандарта CVSS v1.0 за их вклад в данную работу [1].

Перевод: ЗАО «Позитив Текнолоджиз», 2008

Общая система оценки уязвимостей (CVSS) – это открытая схема, которая позволяет обмениваться информацией об IT-уязвимостях. Система оценки CVSS состоит из 3 метрик: базовая метрика, временная метрика и контекстная метрика. Каждая метрика представляет собой число (оценку) в интервале от 0 до 10 и вектор – краткое текстовое описание со значениями, которые используются для вывода оценки. Базовая метрика отображает основные характеристики уязвимости. Временная метрика соответствует таким характеристикам уязвимости, которые изменяются со временем, а контекстная метрика – характеристикам, которые уникальны для среды пользователя. CVSS является понятным, прозрачным и общепринятым способом оценки IT-уязвимостей для руководителей, производителей приложений и средств поддержания информационной безопасности, исследователей и др. 

1. Введение

В настоящее время IT-персонал вынужден выявлять и обрабатывать уязвимости различных программных и аппаратных платформ. Существует необходимость расставить приоритеты для этих уязвимостей, чтобы в первую очередь исправлять те из них, которые представляют наибольшую опасность. Но так как уязвимостей, подлежащих исправлению много, и они были оценены по разным шкалам [2][3][4], то свести эти данные воедино для общего анализа не представляется возможным. Общая система оценки уязвимостей (CVSS) – это открытая схема, которая предназначена для решения этой проблемы. Использование CVSS предоставляет следующие выгоды:

• Стандартизованная оценка уязвимостей. После нормализации оценок уязвимостей для всех программных и аппаратных платформ компании может использоваться единая политика управления уязвимостями. Эта политика сходна с договором о предоставлении услуг (SLA, Service Level Agreement), который определяет, как быстро конкретная проблема должна быть решена.
• Открытость системы. Пользователи часто не понимают, каким образом была получена оценка уязвимости. Часто задаются такие вопросы: «Из-за каких свойств уязвимость получила именно эту оценку? Чем она отличается от той, о которой стало известно вчера?» Использование CVSS позволяет каждому увидеть индивидуальные особенности уязвимости, которые привели к указанной оценке.
• Приоритезация рисков: Как только для уязвимости вычислена контекстная метрика, оценка этой уязвимости становится зависимой от среды. Это означает, что полученная оценка отражает реальный риск от наличия этой уязвимости, который существует в данной организации с учетом других уязвимостей.

1.1. Что такое CVSS?

CVSS состоит из трех основных метрик: базовая метрика, временная метрика и контекстная метрика. Каждая из них, в свою очередь, состоит из набора метрик, как показано на рис. 1.

Рис. 1. Группы метрик CVSS.

Эти группы метрик описываются следующим образом:

• Группа базовых метрик представляет основные существенные характеристики уязвимости, которые не изменяются со временем и не зависят от среды. Базовые метрики описаны в главе 2.1.
• Группа временных метрик представляет такие характеристики уязвимости, которые могут измениться со временем, но не зависят от среды. Временные метрики описаны в главе 2.2.
• Группа контекстных метрик представляет такие характеристики уязвимости, которые зависят от среды. Эти метрики описаны в главе 2.3.

Базовые CVSS-метрики составляются для того, чтобы определить и отобразить основные характеристики уязвимости. Эта попытка объективно охарактеризовать уязвимость дает пользователям ясное и интуитивно понятное представление об уязвимости. Затем пользователи могут использовать временные и контекстные группы метрик, чтобы получить более подробную информацию об уязвимости с учетом своей среды. Это позволяет принимать обоснованные решения при выборе способа минимизации риска от наличия уязвимости.

1.2. Другие системы оценки уязвимостей

Существует ряд других систем оценки уязвимостей, которые созданы коммерческими и некоммерческими организациями. Каждая из них имеет свои преимущества, но все они отличаются по тому, какой признак измеряется. Например, CERT/CC использует значения оценок от 0 до 180 и учитывает такие факторы, как например, подвержена ли Интернет-инфраструктура риску и какой тип предусловий нужен для эксплуатации уязвимости [3]. Система анализа уязвимостей SANS учитывает, в какой конфигурации найдена уязвимость – стандартной или нет, или является ли система клиентом или сервером [4]. Система оценки от Microsoft пытается отразить сложность эксплуатации и общее воздействие от эксплуатации уязвимости [2]. Эти системы оценки являются полезными, но они представляют подход, при котором считается, что последствия эксплуатации уязвимости одинаковы для частного лица и для компании.

CVSS можно также описать «от противного». CVSS не является:

• системой оценки угроз, как например, системы, используемые Министерством безопасности США и центром Sans Internet Storm Center [1]. Эти службы предоставляют систему предупреждений об опасностях критически важным IT-сетям в США и в мире соответственно
• базой данных уязвимостей, как National Vulnerability Database (NVD), Open Source Vulnerability Database (OSVDB) или Bugtraq. Эти базы данных представляют собой каталог известных уязвимостей с подробной дополнительной информацией.
• системой идентификации уязвимостей, как, например стандарт Common Vulnerabilities and Exposures (CVE) или словарь уязвимостей Common Weakness Enumeration (CWE). Эти системы используются для того, чтобы однозначно идентифицировать и классифицировать уязвимости в соответствии с тем, где они обнаружены – в коде, при разработке или в архитектуре. [2].

1.3. Как функционирует CVSS?

Когда базовые метрики определены, с помощью базовой формулы вычисляется оценка от 0 до 10 и создается вектор, как показано на рисунке 2. Вектор олицетворяет собой открытую архитектуру системы. Вектор – это текстовая строка, которая содержит значения, связанные с каждой метрикой. Вектор используется для того, чтобы точно отобразить, как была получена оценка. Поэтому необходимо, чтобы вектор всегда публиковался вместе с оценкой. Более подробная информация о векторах представлена в главе 2.4.

Рис 2. Метрики и уравнения.

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

Если требуется временная метрика, то временная формула сочетает временные метрики с базовыми, чтобы получить временную оценку в диапазоне от 0 до 10. Также в случае необходимости вычислить контекстную оценку, контекстная формула сочетает контекстные метрики с временной оценкой, чтобы получить контекстную оценку в диапазоне от 0 до 10. Базовая, временная и контекстная формулы полностью описаны в главе 3.2.

1.4. Кто вычисляет оценку?

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

1.5. Кому принадлежит CVSS?

CVSS разрабатывается Forum of Incident Response and Security Teams (FIRST). [3]. Но, тем не менее, это свободный и открытый стандарт. Ни одна из организаций не является владельцем CVSS, и членство в FIRST не влечет за собой обязанности использовать или внедрять CVSS. Единственной просьбой от FIRST к тем организациям, которые публикуют оценки, является то, чтобы они согласовывали оценки с правилами, описанными в этой статье, и публиковали одновременно оценки и вектор (описанный ниже), чтобы пользователи понимали, как полученная конкретная оценка.

1.6. Кто использует CVSS?

CVSS используют разные организации, и каждая получает оценки своим способом. Вот некоторые примеры:

• Издатели бюллетеней безопасности: коммерческие и некоммерческие организации публикуют базовую и временную оценки и векторы CVSS в свободно распространяемых бюллетенях безопасности. Эти документы содержат много различной информации, включая дату обнаружения уязвимости, системы, которые ей подвержены, и ссылки на производителей для поиска информации об исправлении.
• Производители приложений: производители приложений предоставляются базовые оценки CVSS и векторы своим клиентам. Это помогает давать пользователям объективную информацию о продуктах, а пользователям позволяет эффективно управлять IT-рисками. 
• Пользовательские организации: многие частные организации используют CVSS для внутренних целей при управлении уязвимостями. Они используют сканеры или технологии мониторинга, чтобы определить наличие уязвимости в сетевом или локальном приложении. Затем эти данные объединяют с базовой, временной и контекстной оценками CVSS, чтобы получить информацию, наиболее полно отражающую риск в данном контексте, и исправить именно те уязвимости, которые представляют наибольшую опасность для их систем.
• Сканирование на уязвимости и управление уязвимостями: организации управления уязвимостями сканируют сети для поиска IT-уязвимостей. Они предоставляют базовую оценку CVSS для каждой уязвимости на каждом хосте. Пользовательские организации используют потоки критических данных для более эффективного управления IT-инфраструктурой, уменьшая простои и защищаясь от случайных и намеренных IT-угроз.
• Управление безопасностью(рисками): компании, занимающиеся управлением рисками, используют CVSS-оценки как исходные данные при вычислении уровня рисков и угроз, которым подвержена организация. Эти компании используют сложные приложения, которые часто интегрируются с сетевой топологией компании, данными об уязвимостях и базами данных ресурсов, чтобы предоставить своим клиентам наиболее полную и обоснованную информацию об уровне риска в их системах.
• Исследователи: открытая система CVSS позволяет исследователям проводить статистический анализ уязвимостей и свойств этих уязвимостей.   

1.7. Понятия и определения

В этом документе используются следующие понятия:

• Уязвимость: это тот или иной недостаток в приложении, системе, устройстве или сервисе, которая ведет к нарушению конфиденциальности, целостности и доступности.
• Угроза: это вероятность или частота появления опасных событий
• Риск: это относительное воздействие, которое может возникнуть при эксплуатации уязвимости в контексте пользователя.

2. Группы метрик

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

Группа базовых метрик отображает характеристики уязвимости, которые не меняются со временем и не зависят от контекста. Метрики Access Vector (Вектор доступа), Access Complexity (Сложность доступа) и Authentication (Аутентификация) оценивают, как получить доступ к уязвимости и нужны ли для эксплуатации уязвимости дополнительные условия. Три метрики воздействия - Confidentiality Impact (Влияние на конфиденциальность), Integrity Impact (Влияние на целостность) иAvailability Impack (Влияние на доступность) - описывают возможное прямое влияние на IT-систему в случае эксплуатации уязвимости. Это влияние определяется независимо с точки зрения конфиденциальности, целостности и доступности. Это означает, например, что эксплуатация уязвимости может вызвать частичную потерю целостности и доступности, но не влиять на конфиденциальность.

2.1.1. Access Vector (AV) - Вектор доступа

Эта метрика отображает, как эксплуатируется уязвимость. Возможные варианты значений этой метрики приведены в таблице 1. Чем более удаленным от хоста может быть злоумышленник при эксплуатации уязвимости, тем большее значение имеет оценка уязвимости.

Значение метрики	Описание
Локальный (L)	Для эксплуатации уязвимости злоумышленник должен иметь локальный доступ, т.е. физический доступ к системе или локальную учетную запись. Примерами таких уязвимостей могут служить атаки на внешние устройства, например, атаки Firewire/USB DMA, и локальное повышение привилегий (например, sudo).
Соседняя сеть (A)	Для эксплуатации уязвимости злоумышленник должен иметь доступ к соседней сети, т.е. такой  сети, которая имеет общую среду передачи с сетью, где находится уязвимое ПО. Например, локальные IP subnet, Bluetooth, IEEE 802.11 и локальные Ethernet-сегменты.
Сетевой (N)	Для эксплуатации уязвимости злоумышленник должен обладать доступом к уязвимому ПО, причем этот доступ ограничен только величиной сетевого стека. Локального доступа или доступа из соседней сети не требуется. Такие уязвимости часто называют эксплуатируемыми удаленно. Примером такой сетевой атаки служит переполнение буфера RPC.

Таблица 1. Оценка  Access Vector

2.1.2. Access Complexity (AC) - Сложность доступа

Эта метрика отображает сложность эксплуатации атаки, если злоумышленник получил доступ к целевой системе. Например, представьте переполнение буфера в Интернет-службе: как только целевая система обнаружена, злоумышленник может эксплуатировать уязвимость. Другие уязвимости могут требовать дополнительных действий для эксплуатации. Например, уязвимость в почтовом клиенте может эксплуатироваться только после того, как пользователь скачает и откроет вредоносное приложение. Возможные варианты значений этой метрики приведены в таблице 2. Чем легче эксплуатировать уязвимость, тем выше значение оценки.

Значение метрики	Описание
Высокое (H)	Для эксплуатации уязвимости нужны особые условия. Например: ·          В большинстве конфигураций злоумышленник должен иметь повышенные привилегии или эксплуатировать уязвимости одновременно и в других системах (например, захват DNS) ·          Атаки, основанные на методах социальной инженерии, могут быть легко обнаружены хорошо осведомленными людьми. Например, жертва может выполнить некоторые нетипичные действия. ·          Уязвимая конфигурация на практике встречается очень редко ·          Окно при условиях race condition очень узкое.
Среднее (M)	Для эксплуатации уязвимости нужны до некоторой степени особые условия. Например: ·          Злоумышленники ограничены группой систем или пользователей, которые имеют некоторый уровень авторизации, и, возможно, являются недоверенными ·          Для успешной эксплуатации некоторую информацию необходимо собрать заранее  ·          Уязвимая конфигурация не является стандартной и обычно не используется (например, уязвимость существует, когда сервер проводит аутентификацию учетной записи пользователя по специальной схеме, но не существует при использовании другой схемы) ·          Злоумышленнику нужно использовать методы социальной инженерии, чтобы получить некоторое количество информации для обмана осмотрительных пользователей (например, атаки фишинга, которые изменяют статусную строку web-браузера, чтобы показать некорректную ссылку, которая является знакомой и доверенной, до того, как отправить IM-эксплойт)
Низкое (L)	Для эксплуатации уязвимости не требуются специальные условия и особые обстоятельства. Например: ·          Доступ к уязвимому продукту имеют большое количество систем и пользователей, причем доступ может быть анонимный или недоверенный (например, соединенный с Интернетом web или почтовый сервер) ·          Уязвимая конфигурация является стандартной или повсеместно используемой ·          Атаку можно провести вручную или обладая небольшим количеством навыков. Требуется немного дополнительной информации ·          Условия race condition легко использовать

Таблица 2: Оценка Access Complexity

2.1.3. Authentication (Au) - Аутентификация

Эта метрика отображает количество этапов аутентификации, которые злоумышленник должен пройти в целевой системе, чтобы эксплуатировать уязвимость. Эта метрика не относится к сложности или защищенности самого процесса аутентификации, а касается только необходимости предъявить учетные данные перед тем, как уязвимость можно будет эксплуатировать. Возможные варианты значений этой метрики приведены в таблице 3. Чем меньше нужно учетной информации, тем больше значение оценки.

Значение метрики	Описание
Множественный (M)	Для эксплуатации уязвимости злоумышленник должен аутентифицироваться два и более раз, даже если одни и те же учетные данные используются несколько раз. Примером может служить аутентификация в операционной системе, а затем – для доступа к приложению в данной системе.
Одиночный (S)	Для эксплуатации уязвимости необходимо войти в систему (через командную строку, интерактивную сессию или web-интерфейс)
Отсутствует (N)	Для эксплуатации уязвимости аутентификация не требуется.

Таблица 3: Оценка Authentication

Эта метрика должна применяться к аутентификации, которую проходит злоумышленник до того, как будет эксплуатировать уязвимость. Например, если почтовый сервер уязвим с помощью команд, которые можно исполнять без аутентификации, то эта метрика имеет значение N, т.к. злоумышленник может провести атаку до того, как потребуются учетные данные. Если выполнение такой команды возможно только после успешной аутентификации, то оценка должна иметь значение S или M, в зависимости от того, какое количество процедур авторизации должен пройти злоумышленник до того, как сможет выполнить эту команду.

2.1.4. Confidentiality Impact (C) - Влияние на конфиденциальность

Эта метрика отображает влияние успешной эксплуатации уязвимости на сохранение конфиденциальности в системе. Понятие «конфиденциальность» относится к ограничению доступа к информации и отображению некоторых данных только для авторизованных пользователей, а также к предотвращению доступа или разглашения информации неавторизованным пользователям. Возможные варианты значений этой метрики приведены в таблице 4. Чем больше воздействие на конфиденциальность, тем больше значение оценки.

Значение метрики	Описание
Отсутствует (N)	Уязвимость не затрагивает конфиденциальность системы.
Частичное (P)	Имеется существенное разглашение данных. Возможен доступ к некоторым системным файлам, но злоумышленник не получает контроля над этой информацией, или масштабы потерь невелики. Примером может служить уязвимость, которая вызывает разглашение некоторых таблиц в базе данных.
Полное (C)	Происходит полное разглашение данных, что приводит к раскрытию всех системных файлов. Злоумышленник может читать все системные данные (память, файлы и пр.).

Таблица 4: оценка  Confidentiality Impact

2.1.5. Integrity Impact (I) - Влияние на целостность

Эта метрика отображает влияние успешной эксплуатации уязвимости на целостность системы. Понятие «целостность» связана с достоверностью и точностью информации. Возможные варианты значений этой метрики приведены в таблице 5. Чем больше влияние на целостность системы, тем больше значение оценки.

Значение метрики	Описание
Отсутствует (N)	Эксплуатация уязвимости не оказывает влияние на целостность системы.
Частичное (P)	Возможно изменение некоторых системных файлов или информации, но злоумышленник не получает контроль над изменяемыми данными, или область его влияния ограничена. Например, системные файлы или файлы приложений могут быть перезаписаны или изменены, но злоумышленник не может выбрать файлы, которые будут изменены, или может изменять файлы в ограниченном контексте или области.
Полное (C)	Эксплуатация уязвимости позволяет полностью нарушить целостность системы. Защита системы полностью потеряна, система скомпрометирована. Злоумышленник может изменять любые файлы целевой системы.

Таблица 5: Оценка Integrity Impact

2.1.6. Availability Impack (A) - Влияние на доступность

Эта метрика отображает влияние успешной эксплуатации уязвимости на доступность системы, т.е. на доступность информационных ресурсов. Атаки, потребляющие пропускную способность сети, циклы процессора или дисковое пространство, влияют на доступность системы. Возможные варианты значений этой метрики приведены в таблице 6. Чем больше влияние на доступность системы, тем больше значение оценки.

Значение метрики	Описание
Отсутствует (N)	Эксплуатация уязвимости не влияет на доступность системы.
Частичное (P)	Происходят сбои в доступности ресурса или уменьшение производительности. Примером может служить сетевая flood-атака, которая позволяет установить ограниченное число соединений с Интернет-сервисом.
Полное (С)	Происходит полное отключение системы. Злоумышленник может сделать ресурс полностью недоступным.

Таблица 6: Оценка Availability Impact

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

Угроза, которую несет уязвимость, может изменяться со временем. Если три фактора, которые изменяются со временем и учитываются в CVSS: подтверждение технических деталей уязвимости, статус исправления уязвимости и доступность кода эксплуатации или технологии эксплуатации. Так как временные метрики являются необязательными, они не влияют на базовую оценку. Эти метрики применяются только в тех случаях, когда пользователь хочет уточнить базовую оценку.

2.2.1. Exploitability (E) - Возможность использования

Эта метрика отображает наличие или отсутствие кода или техники эксплуатации. Если легкий в использовании код эксплуатации является общедоступным, то число потенциальных злоумышленников резко возрастает, что увеличивает серьезность уязвимости. Изначально реальная эксплуатация уязвимости может допускаться только теоретически. Публикация технических деталей увеличивает вероятность эксплуатации уязвимости. Эксплойт может позволить злоумышленника постоянно эксплуатировать уязвимость. В некоторых особо опасных случаях это может служить основой для сетевых червей или вирусов. Возможные варианты значений этой метрики приведены в таблице 7. Чем легче эксплуатировать уязвимость, тем выше значение оценки.

Значение метрики	Описание
Непроверенный (U)	Эксплойт не известен, или эксплуатация возможна теоретически.
Proof-of-Concept (POC)	Доступен эксплойт, описывающий концепцию эксплуататции, или существует демонстрация атаки, которая не применима в большинстве систем. Код или технология не действуют в большинстве ситуаций или требуют существенных изменений квалифицированным злоумышленником для использования.
Функциональный (F)	Эксплойт доступен и может быть применен в большинстве ситуаций.
Высокий (H)	Уязвимость можно эксплуатировать с помощью легко переносимого, автономного кода, или эксплойт не нужен (эксплуатация вручную) и детали широко известны. Код эксплуатации работает в любой ситуации или активизируется мобильным автономным агентом (например, червь или вирус).
Не определено (ND)	Метрика не влияет на оценку и будет пропущена в формуле.

Таблица 7: Оценка Exploitability

2.2.2. Remediation Level (RL) - Уровень исправления

Remediation Level – важный фактор для приоритезации. Типичная уязвимость обычно не имеет исправления, когда информация о ней публикуется впервые. Текущие исправления и дополнительные действия предлагаются для временного исправления уязвимости до того момента, когда будет выпущено официальное исправление или обновление. Наличие исправления (временного или постоянного) уменьшается временную оценку, что влияет на уменьшение срочности проблемы, когда появляется официальное исправление. Возможные значения этой метрики представлены в Таблице 8. Чем менее официальный характер носит исправление или чем более оно временное, тем выше оценка.

Значение метрики	Описание
Официальное исправление (OF)	Доступно официальное обновление или исправление от производителя.
Временное исправление (TF)	Доступно официальное временное обновление. Например, производитель выпустил временное исправление или опубликовал список дополнительных действий.
Дополнительные действия (W)	Доступно неофициальное решение, которое предоставлено третьей стороной. В некоторых случаях пользователи уязвимой технологии могут сами создать исправление или разработать дополнительные действия или каким-либо другим способом уменьшить влияние уязвимости.
Не доступен (U)	Обновление или исправление недоступно или не может быть применено.
Не определен (ND)	Метрика не влияет на оценку и будет пропущена в формуле.

Таблица 8: Оценка Remediation Level

2.2.3. Report Confidence (RC) - Степень достоверности отчета

Эта метрика отображает степень конфиденциальности информации о существовании уязвимости и достоверность известных технических деталей. Иногда публикуется только информации о существовании уязвимости, а детали не указываются. Позже уязвимость может быть дополнена информацией о технологии эксплуатации от автора или от производителя. Риск от наличия уязвимости выше, если ее существование достоверно известно. Эта метрика отражает необходимый уровень подготовки потенциальных злоумышленников. Возможные значения этой метрики представлены в Таблице 9. Чем подробнее информация об уязвимости, предоставленная производителем или другим надежным источником, тем выше оценка.

Значение метрики	Описание
Не подтвержден (UC)	Существует одно неподтвержденное сообщение или несколько противоречивых сообщений. Достоверность этих сообщений мала. Примером может служить слух из хакерских кругов.
Не доказан (UR)	Существует сообщения от множества неофициальных источников, возможно, независимых компаний в области безопасности или исследовательских организаций. Возможно, что некоторые технические детали противоречивы или существует другая неоднозначность.
Подтвержден (C)	Уязвимость подтверждена производителем или автором технологии эксплуатации уязвимости. Этот статус также может быть присвоен уязвимости, если ее существование подтверждено каким-то внешним событием, например, публикацией эксплойта или концепции эксплойта или широко распространенной эксплуатацией.
Не определен (ND)	Метрика не влияет на оценку и будет пропущена в формуле.

Таблица 9: Оценка Report Confidence

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

Различные среды могут иметь огромное влияние на риск, который оказывает наличие уязвимости, для организации и заинтересованных лиц. Группа контекстных метрик CVSS отражает характеристики уязвимости, которые связаны со средой пользователя. Так как контекстные метрики являются необязательными, они не влияют на базовую оценку. Эти метрики применяются только в тех случаях, когда пользователь хочет уточнить базовую оценку.

2.3.1. Collateral Damage Potential (CDP) - Вероятность нанесения косвенного ущерба

Эта метрика отображает потенциальную возможность повреждения или утраты собственности или оборудования, а также может оценивать экономические потери, связанные с производительностью или доходом. Возможные значения этой метрики представлены в Таблице 10. Чем выше потенциальная опасность, тем выше оценка.

Значение метрики	Описание
Отсутствует (N)	Не существует потенциальной опасности повреждения или утраты оборудования, производительности или дохода.
Низкий (L)	Удачная эксплуатация уязвимости может привести к небольшому повреждению устройства или собственности ил небольшой потере производительности или дохода в организации.
Средний, пониженный (LM)	Удачная эксплуатация уязвимости может привести к среднему повреждению устройства или собственности или средней потере производительности или дохода в организации.
Средний, повышенный (MH)	Удачная эксплуатация уязвимости может привести к значительному повреждению устройства или собственности или значительной потере производительности или дохода в организации.
Высокий (H)	Удачная эксплуатация уязвимости может привести к катастрофическому повреждению устройства или собственности или катастрофической потере производительности или дохода в организации.

Таблица 10: Оценка Collateral Damage Potential

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

2.3.2. Target Distribution (TD) - Плотность целей

Эта метрика отображает процент уязвимых систем от всех имеющихся систем. Она используется как особый индикатор среды, чтобы приблизительно определить процент систем, на которые может влиять данная уязвимость. Возможные значения этой метрики представлены в таблице 11. Чем больше процент уязвимых систем, тем больше оценка.

Значение метрики	Описание
Отсутствует (N)	Целевых систем нет, или цели слишком специализированы и существуют только в лабораторных условиях. 0% риска для систем среды.
Низкий (L)	В указанном контексте существуют цели, но в небольшом количестве. Риску подвержены от 1% до 25% систем среды.
Средний (M)	В указанном контексте существуют цели, но в среднем количестве. Риску подвержены от 26% до 75% систем среды.
Высокий (H)	В указанном контексте существуют цели, и их много. Риску подвержены от 76% до 100% систем среды.

Таблица 11: Оценка Target Distribution

2.3.3. Security Requirements (CR, IR, AR) - Требования к безопасности

Эти метрики позволяют аналитику определить CVSS-оценку в зависимости от важности уязвимого устройства или программного обеспечения для организации, измеренной в терминах конфиденциальности, целостности и доступности. Это означает, что если уязвимость обнаружена в программном или аппаратном обеспечении, которое отвечает за бизнес-функцию, для которой наиболее важна доступность, аналитик может приписать большее значение доступности, относительно конфиденциальности и целостности. Каждое требование безопасности имеет три возможных значения: “low” (низкий), “medium” (средний) или “high” (высокий).

Влияние на контекстную метрику определяется связанными базовыми Impact-метриками (заметьте, что базовые метрики confidentiality impact, integrity impact и availability impact не изменяются). Эти три метрики изменяют контекстную оценку, т.к. происходит переоценка (базовых) метрик confidentiality impact, integrity impact и availability impact. Например, значение метрики confidentiality impact (C) увеличивается, если значение confidentiality requirement (CR) равно “high” (высокий). Соответственно, значение метрики confidentiality impact уменьшается, если значение confidentiality requirementравно “low” (низкий). Значение метрики confidentiality impact является нейтральным, если значение confidentiality requirementравно “medium” (средний). Такие же правила применяются метрик, связанных с целостностью и доступностью.

Заметьте, что confidentiality requirementне влияет на контекстную оценку, если (базовая) confidentiality impact установлена как “none” (отсутствует). Также увеличение confidentiality requirementс “medium” (средний) до “high” (высокий) не изменит контекстную оценку, если (базовые) метрики impact установлены как “complete” (полное), т.к. в этом случае часть оценки, связанная с impact sub score (часть базовой оценки, которая соответствует impact), уже равна максимальному значению 10.

Возможные значения security requirementперечислены в таблице 12. Для краткости эта таблица используется для всех трех метрик. Чем больше security requirement, тем больше оценка (помните, что значение “medium” (средний) является стандартным). Эти метрики изменяют оценку на ± 2.5.

Значение метрики	Описание
Низкий (L)	Потеря  [конфиденциальности | целостности | доступности], вероятно, имеет ограниченное неблагоприятное воздействие на организацию или частное лицо, связанное с организацией (например, сотрудники, клиенты).
Средний (M)	Потеря [конфиденциальности | целостности | доступности], вероятно, имеет серьезное ограниченное воздействие на организацию или частное лицо, связанное с организацией (например, сотрудники, клиенты).
Высокий (H)	Потеря [конфиденциальности | целостности | доступности], вероятно, имеет очень серьезное воздействие на организацию или частное лицо, связанное с организацией (например, сотрудники, клиенты).
Не определен (ND)	Метрика не влияет на оценку и будет пропущена в формуле.

Таблица 12: Значения Security Requirements

Во многих организациях IT-ресурсы отмечены индексами критичности, основанными на положении в сети, бизнес-функции и потенциальной потерях при выходе их из строя. Например, правительство США относит каждый неклассифицированный IT‑ресурс к группе, называемой System. Каждый ресурс этой группы имеет три оценки «potential impact», которые отображают потенциальное влияние на организацию, если этот ресурс System будет скомпрометирован в соответствии с тремя целями: конфиденциальность, целостности и доступность. Таким образом, влияние каждого неклассифицированного IT-ресурса в правительстве США оценено как низкое, среднее или высокое в зависимости от реалий безопасности в конфиденциальности, целостности и доступности. Эта система оценок описана в Federal Information Processing Standards (FIPS) 199. CVSS соответствует этой общей модели FIPS 199 ноне требует, чтобы организации использовали какую-токонкретную систему для установления низких, средних или высоких оценок.

2.4. Базовый, временной и контекстный вектор

Каждая метрика в этой векторе представлена сокращенным именем метрики, за которым следует ":" (двоеточие), а затем – сокращенное значение метрики. Вектор содержит последовательность метрик в заранее заданном порядке, при этом символ "/" (слеш) используется для разделения метрик. Если временная или контекстная метрика не используется, то проставляется значение "ND" (не определено). Базовый, временной и контекстный вектор представлены ниже в таблице 13.

Значение мтерики	Опсиание
Базовый	AV:[L,A,N]/AC:[H,M,L]/Au:[M,S,N]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C]
Временной	E:[U,POC,F,H,ND]/RL:[OF,TF,W,U,ND]/RC:[UC,UR,C,ND]
Окружения	CDP:[N,L,LM,MH,H,ND]/TD:[N,L,M,H,ND]/CR:[L,M,H,ND]/ IR:[L,M,H,ND]/AR:[L,M,H,ND]

Таблица 13: Базовый, временной и контекстный вектор

Например, уязвимость со значениями базовых метрик "Access Vector: Low, Access Complexity: Medium, Authentication: None, Confidentiality Impact: None, Integrity Impact: Partial, Availability Impact: Complete" имеет следующий базовый вектор: "AV:L/AC:M/Au:N/C:N/I:P/A:C."