Оценка уязвимостей CVSS 3.010.09.2015 16:33

Мы используем систему оценок CVSS с момента возникновения нашей базы уязвимостей и первого нашего продукта — XSpider (надеюсь, кто-то его еще помнит). Для нас очень важно поддерживать базу знаний, которую мы используем в своих продуктах и услугах, в актуальном состоянии. Поскольку рекомендации по работе с CVSS-метриками не покрывают все возможные варианты уязвимостей, иногда приходится задаваться вопросом: «Как лучше проставить метрики, чтобы итоговая оценка отражала реальную опасность уязвимости?».

Мы постоянно следим за развитием стандарта, поэтому давно ждали окончательной версии CVSSv3. Открывая спецификацию, я прежде всего хотел ответить на вопросы: «Что стало лучше?», «Что именно изменилось?», «Сможем ли мы использовать новый стандарт в наших продуктах?» и — поскольку к ведению базы часто подключаются молодые специалисты — «Как быстро можно овладеть методикой оценки?», «Насколько четкими являются критерии?».

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

Стандарт Common Vulnerability Scoring System был разработан группой экспертов по безопасности National Infrastructure Advisory Council. В эту группу вошли эксперты из различных организаций, таких как CERT/CC, Cisco, DHS/MITRE, eBay, IBM Internet Security Systems, Microsoft, Qualys, Symantec.

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

Далее стандарт стал поддерживаться рабочей группой Common Vulnerability Scoring System-Special Interest Group (CVSS-SIG) в рамках проекта Forum of Incident Response and Security Teams (FIRST). Членство в группе не накладывает на ее участников каких-либо ограничений по поддержке и распространению стандарта.

В 2007 году была опубликована вторая версия стандарта: были внесены правки в перечень показателей и изменена формула расчета итоговой метрики для более точной оценки опасности уязвимостей.

В 2014 году рекомендации по использованию CVSSv2 выпускают такие авторитетные организации, как NIST и ITU, занимающиеся разработкой руководств и стандартов в области телекоммуникации и информационных систем.

Использование метрик CVSS для оценки уязвимостей закреплено в стандартах PCI DSS и СТО БР ИББС.

В июне 2015 года FIRST опубликовал финальную версию стандарта CVSSv3, о котором и пойдет речь в данной статье.

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

В стандарт входят три группы метрик:

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

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

Значение метрики принято публиковать в виде пары из вектора (конкретные значения отдельных показателей) и числового значения, рассчитанного на основе всех показателей при помощи формулы, определенной в стандарте.

Далее по тексту мы не будем подробно рассматривать CVSSv2, на эту тему есть достаточно хорошая документация [6, 9], остановимся более детально на изменениях, вносимых новым стандартом.

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

Компоненты системы, для которых рассчитываются метрики

В рамках стандарта вводятся следующие понятия:

• уязвимый компонент (vulnerable component) — тот компонент информационной системы, который содержит уязвимость и подвержен эксплуатации;
• атакуемый компонент (impacted component) — тот, конфиденциальность, целостность и доступность которого могут пострадать при успешной реализации атаки.

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

• выход за пределы песочницы приложения;
• получение доступа к пользовательским данным, сохраненным в браузере, через уязвимость в веб-приложении (XSS);
• выход за пределы гостевой виртуальной машины.

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

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

Вектор атаки

Степень удаленности потенциального атакующего от уязвимого объекта.

CVSSv2	CVSSv3
Название метрики
Access Vector (AV)	Attack Vector (AV)
Возможные значения метрики
Network (N)	Network (N)
Adjacent Network (A)	Adjacent Network (A)
Local (L)	Local (L)
	Physical (P)

Примечание: здесь и далее в скобках даются буквенные мнемоники, используемые при описании CVSS-вектора.

Изменения коснулись понятия «Local», которое в прошлых версиях стандарта описывало любые действия, не затрагивающие сеть. В новой версии вводится такое деление:

• Local — для эксплуатации атакующему требуется локальная сессия или определенные действия со стороны легитимного пользователя
• Physical — атакующему требуется физический доступ к уязвимой подсистеме.

Рассмотрим две уязвимости, имеющие одинаковую оценку с точки зрения CVSSv2: 7.2 (AV: L/AC: L/Au: N/C: C/I: C/A: C).

• CVE-2015–2363 — Драйвер win32k.sys операционной системы Windows некорректно обрабатывает ряд объектов в памяти, что позволяет злоумышленнику, имеющему локальный доступ к системе, получить административные привилегии и выполнить произвольный код в режиме ядра.
• CVE-2015–3007 — Сетевые шлюзы Juniper серии SRX некорректно реализуют функцию отключения восстановления пароля непривилегированным пользователем через консольный порт (set system ports console insecure). Уязвимость позволяет злоумышленнику, имеющему физический доступ к консольному порту, получить административные привилегии на устройстве.

Метрики для тех же уязвимостей по новому стандарту CVSSv3 различаются:
Видно, что в CVSSv3 степень опасности уязвимости оценивается более точно, без усреднения, имевшего место в CVSSv2.

Сложность эксплуатации уязвимости

Качественная оценка сложности проведения атаки. Чем больше условий должно быть соблюдено для эксплуатации уязвимости — тем выше сложность.

CVSSv2	CVSSv3
Название метрики
Access Complexity (AC)	Attack Complexity (AC)
Возможные значения метрики
Low (L)	Low (L)
Medium (M)
High (H)	High (H)

«Сложность» сама по себе — понятие субъективное, поэтому данная метрика, всегда трактовалась экспертами по-разному. К примеру, для уязвимостей, позволяющих реализовать атаку «Человек посередине», в базе NVD можно встретить различные варианты оценки Access Complexity.

• CVE-2014–2993 — Уязвимость в функции проверки SSL-сертификата приложения Birebin.com для операционной системы Android позволяет злоумышленнику осуществить атаку «Человек посередине» и получить доступ к конфиденциальным данным. [Access Complexity — Low]
• CVE-2014–3908 — Уязвимость в функции проверки SSL-сертификата приложения Amazon.com Kindle для операционной системы Android позволяет злоумышленнику осуществить атаку «Человек посередине» и получить доступ к конфиденциальным данным. [Access Complexity — Medium]
• CVE-2014–5239 — Уязвимость в функции проверки SSL-сертификата приложения Microsoft Outlook.com для операционной системы Android позволяет злоумышленнику осуществить атаку «Человек посередине» и получить доступ к конфиденциальным данным. [Access Complexity — High]

Для облегчения толкования данной метрики в новом стандарте предлагаются только две ступени сложности и более четко прописаны критерии отнесения уязвимости к той или иной. В частности, уязвимости, позволяющие атаку «Человек посередине», предписано относить к категории High.

Факторы, учитываемые в CVSSv2 метрикой Access Complexity, в новом стандарте учитываются двумя метриками — Attack Complexity и User Interaction.

Аутентификация / требуемый уровень привилегий

Требуется ли аутентификация для проведения атаки, и если требуется, то какая именно.

CVSSv2	CVSSv3
Название метрики
Authentication (Au)	Privileges Required (PR)
Возможные значения метрики
Multiple (M)
Single (S)
	High (H)
	Low (L)
None (N)	None (N)

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

Значение Multiple в базе NVD встречается достаточно редко и в основном используется для уязвимостей, информация о которых недостаточно детализирована.

CVE-2015–0501 — Неизвестная уязвимость в Oracle MySQL Server позволяет удаленным аутентифицированным пользователям нарушить доступность СУБД, используя неизвестный вектор, связанный с «Server: Compiling».

Значение Single не позволяет определить, требуется ли для эксплуатации доступ уровня привилегированного пользователя или достаточно аутентификации стандартного пользователя.

Рассмотрим две уязвимости, имеющие одинаковую оценку с точки зрения CVSSv2: 9.0 (AV: N/AC: L/Au: S/C: C/I: C/A: C)

• CVE-2014–0649 — Cisco Secure Access Control System (ACS) некорректно выполняет авторизацию при доступе к интерфейсу Remote Method Invocation (RMI), что позволяет удаленным аутентифицированным злоумышленникам получить административные привилегии.
• CVE-2014–9193 — Innominate mGuard некорректно обрабатывает настройки Point-to-Point Protocol (PPP), что позволяет удаленным злоумышленникам, имеющим ограниченные административные права, получить привилегии суперпользователя.

Метрики для тех же уязвимостей по CVSSv3:
Как видно из таблицы, CVSSv3 занижает опасность уязвимостей, требующих для эксплуатации привилегированного доступа.

Необходимость взаимодействия с пользователем

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

CVSSv2	CVSSv3
Название метрики
	User Interaction (UI)
Возможные значения метрики
	None (N)
	Required (R)

В CVSSv2 этот фактор учитывался в рамках метрики Access Complexity, в новом стандарте представлен в виде самостоятельной.

Рассмотрим две уязвимости, имеющие одинаковую оценку с точки зрения CVSSv2: 9.3 (AV: N/AC: M/Au: N/C: C/I: C/A: C).

• CVE-2014–0329 — Маршрутизаторы ZTE ZXV10 W300 имеют встроенную учетную запись администратора с фиксированным паролем формата «XXXXairocon', где XXXX — последние четыре символа MAC-адреса устройства. Удаленный атакующий может получить пароль администратора и использовать его для доступа к устройству через сервис Telnet.
• CVE-2015–1752 — Microsoft Internet Explorer некорректно обрабатывает объекты в памяти, что позволяет атакующему выполнить произвольный код на системе при переходе пользователя по ссылке, содержащей вредоносный код.

Метрики для CVSSv3:
Из этого примера видно, что в CVSSv3 степень опасности уязвимости оценивается более корректно.

Границы эксплуатации

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

CVSSv2	CVSSv3
Название метрики
	Scope (S)
Возможные значения метрики
	Unchanged (U)
	Changed ©

Рассмотрим две уязвимости, имеющие одинаковую оценку CVSSv2: 10.0 (AV: N/AC: L/Au: N/C: C/I: C/A: C).

• CVE-2014–0568 — Уязвимость в обработчике системного вызова NtSetInformationFile в Adobe Reader и Adobe Acrobat на операционной системе Windows позволяет атакующему обойти ограничения «песочницы» и выполнить произвольный код в привилегированном контексте.
• CVE-2015–3048 — Уязвимость в Adobe Reader и Adobe Acrobat на операционных системах Windows и MacOS X позволяет атакующему вызвать переполнение буфера и выполнить произвольный код на системе.

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

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

Оценка степени влияния на конфиденциальность, целостность и доступность атакуемого компонента.

CVSSv2	CVSSv3
Название метрики
Confidentiality Impact ©, Integrity Impact (I), Availability Impact (A)
Возможные значения метрики
None (N)	None (N)
Partial (P)
Complete ©
	Medium (M)
	High (H)

В данной метрике принципиально изменен подход к расчету веса: от количественного (Partial—Complete) к качественному (Medium—High).

Рассмотрим две уязвимости, имеющие одинаковую оценку CVSSv2: 5.0 (AV: N/AC: L/Au: N/C: P/I: N/A: N).

• CVE-2014–0160 — Уязвимость существует в реализации TLS и DTLS для OpenSSL из-за некорректной обработки пакетов расширения Heartbeat. Эксплуатация данной уязвимости позволяет злоумышленникам, действующим удаленно, получить доступ к конфиденциальной информации из памяти процесса при помощи специально сформированных пакетов, которые вызывают чтение за пределами буфера.
• CVE-2015–4202 — Реализация Cable Modem Termination Systems (CMTS) в маршрутизаторах Cisco uBR10000 не дает возможность ограничить доступ к сервису IP Detail Record (IPDR), что позволяет удаленному атакующему получить доступ к конфиденциальной информации путем отсылки специально сформированных IPDR-пакетов.

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

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

Временные метрики не претерпели никаких принципиальных изменений.

Степень зрелости доступных средств эксплуатации

Доступен ли публично код или другие средства, с помощью которых можно провести атаку, или, напротив, существует только теоретическая возможность эксплуатации.

CVSSv2	CVSSv3
Название метрики
Exploitability (E)	Exploit Code Maturity (E)
Возможные значения метрики
Not Defined (ND/X)
High (H)
Functional (F)
Proof-of-Concept (POC/P)
Unproven (U)

В этой метрике изменилось только название: теперь оно точнее отражает назначение.

Доступные средства устранения уязвимости

Существуют ли официальные или неофициальные средства устранения уязвимости.

CVSSv2	CVSSv3
Название метрики
Remediation Level (RL)
Возможные значения метрики
Not Defined (ND/X)
Unavailable (U)
Workaround (W)
Temporary Fix (TF/T)
Official Fix (OF/O)

В данную метрику изменения не вносились.

Степень доверия к информации об уязвимости

Степень детализации доступных отчетов об уязвимости

CVSSv2	CVSSv3
Название метрики
Report Confidence (RC)
Возможные значения метрики
Not Defined (ND)	Not Defined (X)
Unconfirmed (UC)
Uncorroborated (UR)
	Unknown (U)
	Reasonable (R)
Confirmed ©	Confirmed ©

В новом стандарте более четко описаны критерии для отнесения отчета об уязвимости к той или иной категории:

• Unknown — в существующих отчетах отсутствует описание причины уязвимости или различные исследователи расходятся относительно причин и возможных последствий эксплуатации;
• Reasonable — существуют отчеты об уязвимости, позволяющие судить о причинах уязвимости с достаточной степенью уверенности (например, в отчете приводится пример эксплуатирующего кода);
• Confirmed — уязвимость подтверждена производителем продукта или в свободном доступе находится полнофункциональный эксплойт.

Степень влияния временных метрик

Рассмотрим уязвимость:

CVE-2015–2373 — Уязвимость в сервисе Remote Desktop Protocol (RDP) операционной системы Windows позволяет удаленному атакующему выполнить произвольный код на системе путем отправки специально сформированных RDP-пакетов.

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

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

Контекстные метрики изменены для упрощения оценки влияния среды на итоговую оценку.

Требования к безопасности

Позволяет задекларировать, какая характеристика данных атакуемого компонента (конфиденциальность, целостность или доступность) наиболее влияет на функциональность бизнес-системы или в целом на бизнес-процессы.

CVSSv2	CVSSv3
Название метрики
Confidentiality Requirement (CR), Integrity Requirement (IR), Availability Requirement (AR)
Возможные значения метрики
Not Defined (ND/X)
High (H)
Medium (M)
Low (L)

В данную метрику изменения не вносились.

Скорректированные базовые метрики

Эксплуатируемость и потенциальный ущерб в условиях IТ-инфраструктуры конкретной компании.

CVSSv3
Название метрики
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)
Возможные значения метрики
Значения, описанные в секции «Базовые метрики», или Not Defined (X)

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

Упраздненные метрики

Из стандарта исключены следующие метрики:

• Вероятность нанесения побочного ущерба (Collateral Damage Potential, CDP) — оценка по качественной шкале None/Low/Medium/High потенциального ущерба для оборудования или иных активов от эксплуатации уязвимости. Эта метрика также могла учитывать экономический ущерб от простоя производства или недополученной выручки.
• Плотность целей (Target Distribution, TD) — процент систем в информационной среде компании, на которые может влиять эксплуатация уязвимости.

Иные нововведения в стандарте

Цепочки уязвимостей

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

Рассмотрим абстрактный пример.

• Уязвимость 1 — Локальное повышение привилегий, не требующее взаимодействия с пользователем.
• Уязвимость 2 — Уязвимость, позволяющая удаленному неаутентифицированному атакующему модифицировать файлы уязвимого компонента. Уязвимость требует от пользователя выполнения каких-либо действий для успешной эксплуатации, например перехода по ссылке.

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

Качественная шкала оценки опасности

За годы использования CVSSv2 в разных компаниях сложились разные подходы к выставлению качественного уровня опасности на базе метрики CVSS:

• Nvd.nist.gov: 0—3.9 Low; 4.0—6.9 Medium; 7.0—10.0 High;
• Tenable: 0—3.9 Low; 4.0—6.9 Medium; 7.0—9.9 High; 10.0 Critical;
• Rapid 7: 0—3.9 Moderate; 4.0—7.9 Severe; 8.0—10.0 Critical.

Стандарт CVSSv3 рекомендует использовать следующую шкалу качественных оценок:

Количественная оценка	Качественная оценка
0	None
0.1—3.9	Low
4.0—6.9	Medium
7.0—8.9	High
9.0—10.0	Critical

Коротко подведу итоги и перечислю самые важные новшества CVSSv3:

• Введены понятия «уязвимый компонент» и «атакуемый компонент». Метрики эксплуатируемости рассчитываются для уязвимого компонента, а метрики воздействия — для атакуемого.
• Добавлена новая ступень требуемого для эксплуатации доступа — «физический доступ».
• Введена новая метрика «Необходимость взаимодействия с пользователем».
• Переработана метрика, учитывающая необходимость аутентификации. Появилась возможность учесть необходимость привилегированного доступа к системе.
• Из количественной в качественную переработана шкала метрик воздействия.
• Контекстные метрики «Вероятность нанесения побочного ущерба» и «Плотность целей» заменены более показательными «Скорректированными базовыми метриками».
• Даны рекомендации для оценки цепочек уязвимостей по методике CVSS.
• Стандартизована качественная шкала оценки опасности.

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

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

Тем, кто хочет глубже освоить методику оценки уязвимостей по CVSS, рекомендую помимо спецификации [1] ознакомится с примерами расчетов [3] и рекомендациями FIRST [2], где на типовых примерах разъясняется, как правильно использовать стандарт для оценки уязвимостей.

Ряд зарубежных компаний, среди которых IBM X-Force и Security Database, уже внедрили оценки по CVSSv3 в своих продуктах и сервисах. Мы в компании Positive Technologies закладываем возможность оценки уязвимостей по стандарту CVSSv3 в корпоративной базе знаний и линейке продуктов MaxPatrol.

1. Спецификация CVSSv3
2. Рекомендации по использованию CVSSv3
3. Примеры расчета метрик по методике CVSSv3
4. Калькулятор CVSSv3
5. База уязвимостей National Vulnerability Database
6. Спецификация CVSSv2
7. Калькулятор CVSSv2
8. Открытое письмо в FIRST о слабых сторонах CVSSv2
9. CVSS Implementation Guide от NIST
10. Рекомендации ITU по использованию CVSS

© Habrahabr.ru