Что содержит вектор уязвимости в cvss

Видео:Как тестировать сайт? | Уязвимости сайтов | XSS атака | 18+Скачать

Банк данных угроз безопасности информации

Федеральная служба по техническому и экспортному контролю

ФСТЭК России

Государственный научно-исследовательский испытательный институт проблем технической защиты информации

ФАУ «ГНИИИ ПТЗИ ФСТЭК России»

1. Главная
2. Калькулятор CVSS V2

Справочные сведения об общей системе оценки уязвимости

Общая система оценки уязвимостей (Common Vulnerability Scoring System – CVSS) – это система, которая позволяет осуществлять сравнение уязвимостей программного обеспечения с точки зрения их опасности.

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

Система оценки CVSS v2.0 состоит из трех групп метрик (критериев): базовых, временных и контекстных.

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

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

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

Для осуществления комбинированной оценки уязвимостей по различным группам метрик (критериев) используются базовый, временной и контекстный векторы уязвимости.

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

Базовый вектор уязвимости CVSS v2.0 представляет собой комбинированную информацию о базовых метриках (критериях), представляемую в виде текстовой формализованной записи (строки) и численного значения (оценки).

Базовый вектор уязвимости имеет следующий формат:

AV:X/AC:X/Au:X/C:X/I:X/A:X, где

• AV – метрика (критерий) способа получения доступа нарушителем;
• AC – метрика (критерий) сложности получения доступа нарушителем;
• Au – метрика (критерий) характеристики потребности нарушителя в аутентификации;
• С – метрика (критерий) влияния на конфиденциальность;
• I – метрика (критерий) влияния на целостность;
• A – метрика (критерий) влияния на доступность;
• значение метрики (критерия).

Каждая метрика (критерий) может принимать одно из трёх значений.

Метрика (критерий) AV может принимать следующие значения:

• L – получение физического (локального) доступа к объекту;
• A – получение доступа к объекту из локальной вычислительной сети;
• N – получение доступа к объекту из любой вычислительной сети, связанной с объектом атаки.

Метрика (критерий) AC может принимать следующие значения:

• H – для получения доступа требуется выполнение особых условий (например, повышение привилегий или получение дополнительной информации при помощи методов «социальной инженерии»);
• M – для получения доступа требуется выполнение специальных условий (например, прохождение нестандартной процедуры аутентификации или получение предварительной информации при действиях, приводящих к гарантированному результату);
• L – для получения доступа выполнение специальных условий не требуется (L).

Метрика (критерий) Au может принимать следующие значения:

• N – аутентификация не требуется;
• S – требуется однократная аутентификация;
• M – требуется многократная аутентификация.

Метрика (критерий) C может принимать следующие значения:

• N – не оказывает влияния на конфиденциальность данных;
• P – частичное нарушение конфиденциальности данных;
• C – полное нарушение конфиденциальности данных.

Метрика (критерий) I может принимать следующие значения:

• N – не оказывает влияния на целостность данных;
• P – частичное неправомерное уничтожение или модифицирование данных;
• C – полное неправомерное уничтожение или модифицирование данных.

Метрика (критерий) A может принимать следующие значения:

• N – не оказывает влияния на доступность данных;
• P – кратковременное неправомерное блокирование данных;
• C – долговременное неправомерное блокирование данных.

Численное значение базового вектора уязвимости (базовая оценка) изменяется от 0 до 10.

На основе численного значения базового вектора V уязвимости (базовой оценки) присваиваются один из четырех уровней опасности:

• низкий уровень опасности, если 0,0 ≤ V ≤ 3,9;
• средний уровень опасности, если 4,0 ≤ V ≤ 6,9;
• высокий уровень опасности, если 7,0 ≤ V ≤ 9,9;
• критический уровень опасности, если V = 10,0.

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

Полное руководство по общему стандарту оценки уязвимостей версии 2, Часть первая, Группы метрик

Общая система оценки уязвимостей (CVSS) – это открытая схема, которая позволяет обмениваться информацией об IT-уязвимостях.

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

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

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

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

Видео:CVSS: Measuring vulnerability severityСкачать

1. Введение

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

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

Видео:What is CVSS? | Common Vulnerability Scoring SystemСкачать

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

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

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

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

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

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

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

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].

Видео:Александр Леонов, Ведущий аналитик по ИБ Тинькофф Банк — Vulnerability Scanner как иллюзияСкачать

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

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

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

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

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

Видео:Применение Сканер-ВС 6 | Поиск уязвимостейСкачать

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

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

Видео:29 Оценка и анализ уязвимостей Часть 2Скачать

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

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

Видео:CVE-2021-40444: почему это важноСкачать

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

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

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

Видео:Иван Румак — Эффективный поиск XSS-уязвимостейСкачать

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

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

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

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

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

Видео:Безопасная среда. Что такое уязвимости ПО и почему это касается каждого?Скачать

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

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

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

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

Для эксплуатации уязвимости злоумышленник должен иметь локальный доступ, т.е . физический доступ к системе или локальную учетную запись. Примерами таких уязвимостей могут служить атаки на внешние устройства, например, атаки Firewire/USB DMA , и локальное повышение привилегий (например, sudo).

Соседняя сеть (A)

Для эксплуатации уязвимости злоумышленник должен иметь доступ к соседней сети, т.е. такой сети, которая имеет общую среду передачи с сетью, где находится уязвимое ПО. Например, локальные IP subnet, Bluetooth, IEEE 802.11 и локальные Ethernet-сегменты.

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

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

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

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

Для эксплуатации уязвимости нужны особые условия. Например:

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

· Атаки, основанные на методах социальной инженерии, могут быть легко обнаружены хорошо осведомленными людьми. Например, жертва может выполнить некоторые нетипичные действия.

· Уязвимая конфигурация на практике встречается очень редко

· Окно при условиях race condition очень узкое.

Для эксплуатации уязвимости нужны до некоторой степени особые условия. Например:

· Злоумышленники ограничены группой систем или пользователей, которые имеют некоторый уровень авторизации, и, возможно, являются недоверенными

· Для успешной эксплуатации некоторую информацию необходимо собрать заранее

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

· Злоумышленнику нужно использовать методы социальной инженерии, чтобы получить некоторое количество информации для обмана осмотрительных пользователей (например, атаки фишинга, которые изменяют статусную строку web -браузера, чтобы показать некорректную ссылку, которая является знакомой и доверенной, до того, как отправить IM-эксплойт)

Для эксплуатации уязвимости не требуются специальные условия и особые обстоятельства. Например:

· Доступ к уязвимому продукту имеют большое количество систем и пользователей, причем доступ может быть анонимный или недоверенный (например, соединенный с Интернетом web или почтовый сервер)

· Уязвимая конфигурация является стандартной или повсеместно используемой

· Атаку можно провести вручную или обладая небольшим количеством навыков. Требуется немного дополнительной информации

· Условия race condition легко использовать

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

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

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

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

Для эксплуатации уязвимости необходимо войти в систему (через командную строку, интерактивную сессию или web -интерфейс)

Для эксплуатации уязвимости аутентификация не требуется.

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

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

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

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

Уязвимость не затрагивает конфиденциальность системы.

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

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

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

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

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

Эксплуатация уязвимости не оказывает влияние на целостность системы.

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

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

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

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

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

Эксплуатация уязвимости не влияет на доступность системы.

Происходят сбои в доступности ресурса или уменьшение производительности. Примером может служить сетевая flood -атака, которая позволяет установить ограниченное число соединений с Интернет-сервисом.

Происходит полное отключение системы. Злоумышленник может сделать ресурс полностью недоступным.

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

Видео:🔥Стоп- Хам. Мгновенная карма для нарушителей. Эвакуация с тротуара. Микрорайон Суворовский.🔥Скачать

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

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

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

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

Эксплойт не известен, или эксплуатация возможна теоретически.

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

Эксплойт доступен и может быть применен в большинстве ситуаций.

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

Не определено (ND)

Метрика не влияет на оценку и будет пропущена в формуле.

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

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

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

Официальное исправление (OF)

Доступно официальное обновление или исправление от производителя.

Временное исправление (TF)

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

Дополнительные действия (W)

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

Обновление или исправление недоступно или не может быть применено.

Не определен (ND)

Метрика не влияет на оценку и будет пропущена в формуле.

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

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

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

Не подтвержден (UC)

Существует одно неподтвержденное сообщение или несколько противоречивых сообщений. Достоверность этих сообщений мала. Примером может служить слух из хакерских кругов.

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

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

Не определен (ND)

Метрика не влияет на оценку и будет пропущена в формуле.

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

Видео:СТОРОНА ЗАЩИТА ПРОДОЛЖИЛА ВЫСТУПЛЕНИЯ В ПРЕНИЯХ СТОРОНСкачать

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

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

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

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

Не существует потенциальной опасности повреждения или утраты оборудования, производительности или дохода.

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

Средний, пониженный (LM)

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

Средний, повышенный (MH)

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

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

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

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

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

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

Целевых систем нет, или цели слишком специализированы и существуют только в лабораторных условиях. 0% риска для систем среды.

В указанном контексте существуют цели, но в небольшом количестве. Риску подвержены от 1% до 25% систем среды.

В указанном контексте существуют цели, но в среднем количестве. Риску подвержены от 26% до 75% систем среды.

В указанном контексте существуют цели, и их много. Риску подвержены от 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.

Потеря [конфиденциальности | целостности | доступности], вероятно, имеет ограниченное неблагоприятное воздействие на организацию или частное лицо, связанное с организацией (например, сотрудники, клиенты).

Потеря [конфиденциальности | целостности | доступности], вероятно, имеет серьезное ограниченное воздействие на организацию или частное лицо, связанное с организацией (например, сотрудники, клиенты).

Потеря [конфиденциальности | целостности | доступности], вероятно, имеет очень серьезное воздействие на организацию или частное лицо, связанное с организацией (например, сотрудники, клиенты).

Не определен (ND)

Метрика не влияет на оценку и будет пропущена в формуле.

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

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

Видео:CVSS Scores – Which Vulnerabilities to Prioritize? | AT&T ThreatTraqСкачать

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

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

Видео:01 Виды уязвимостей сайтаСкачать

Статьи по теме: «Информационная безопасность»

Видео:CVE-2020-1350 Sigred опасная уязвимость в DNS Windows ServerСкачать

Общий обзор систем оценки уязвимостей (CVSS 2.0/3.0)

Видео:Не получилось понтанутьсяСкачать

Содержание:

Видео:Где найти уязвимости - как найти уязвимости - поиск информации в интернетеСкачать

Введение

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

Актив – это все, что имеет ценность для организации, то есть все, что нужно защитить – люди, информация, материальные ресурсы.

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

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

Например, для приложения, оперирующего банковскими переводами пользователей, активом (защищаемой информацией) будет список транзакций, угрозой – возможность чтения этого списка другими пользователями, а уязвимостью может стать отсутствие проверки привилегий и возможность увидеть список транзакций другого пользователя, изменив URL. При этом эксплуатация уязвимостей может иметь разные последствия – тяжелые и не очень. Один из подходов ранжирования и приоритезации обработки уязвимостей – это оценка их опасности. Существует несколько систем такой оценки, у каждой есть свои плюсы и минусы, и на текущий момент индустриальным стандартом является Common Vulnerability Scoring System (CVSS), поддержкой которого занимается международная группа Forum of Incident Response and Security (FIRST), в которую входят более 400 членов.

23 февраля 2005 года был опубликован отчет исследовательской группы NIAC и обнародована первая версия CVSS — общей системы оценки уязвимостей. Эта рейтинговая система должна была обеспечить открытые и универсальные стандартизированные оценки опасности уязвимостей программного обеспечения. Развитию этого стандарта способствовали крупные ИТ-компании, однако, поскольку первая версия изначально не подвергалась тщательному анализу со стороны множества организаций из разных отраслей, в ней были обнаружены значительные недостатки. Основным недостатком CVSS было признано малое число оценочных критериев – существовало много уязвимостей с одинаковой оценкой. Поэтому была собрана международная открытая группа CVSS-SIG, задачей которой было выявить и исправить все подобные недостатки.

1 июня 2007 года была опубликована вторая версия CVSS, получившая широкое распространение. Уже в сентябре эта версия была закреплена в стандарте безопасности данных платежных карт PCI DSS. Чтобы соответствовать требованиям PCI DSS, операторы платежных систем, обрабатывающие кредитные карты, должны продемонстрировать, что ни одна из их вычислительных систем не имеет уязвимости с общей оценкой CVSS, большей или равной 4.0. В 2007 году Национальный институт стандартов и технологий США (NIST) включил CVSS v2.0 в свой протокол автоматизации безопасности SCAP. В апреле 2011 года CVSS 2.0 был официально принят в качестве международного стандарта для оценки уязвимостей (ITU-T X.1521)

Видео:КиберДуршлаг. Принципы управления уязвимостями с Александром ЛеоновымСкачать

CVSS 2.0

Оценка уязвимостей по системе CVSS 2.0 производится на основе трех метрик: базовой, временной и контекстной. Каждая метрика представляет из себя оценку от 0 до 10 баллов и короткое текстовое описание, содержащее всю необходимую информацию для вывода этой оценки.

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

1. Базовая группа метрик отражает «неотъемлемые и фундаментальные характеристики уязвимости, которые являются постоянными с течением времени и пользовательскими средами».
2. Временная группа метрик отражает «характеристики уязвимости, которые меняются со временем, но не среди пользовательских сред».
3. Контекстная группа метрик отражает «характеристики уязвимости, которые являются релевантными и уникальными для конкретной среды пользователя».

Базовая группа метрик включает в себя шесть метрик. Первые три – способ получения доступа (Access Vector), сложность получения доступа (Access Complexity), показатель аутентификации (Authentication) – призваны помочь получить представление о трудностях, связанных с атакой.

• Способ получения доступа может быть локальным (Local) и удаленным через смежную (Adjacent) или глобальную (Network) сеть, при этом чем более удаленным от атакуемой цели может быть злоумышленник, тем выше будет базовая оценка.
• Сложность атаки может быть высокой (High), средней (Mid) и низкой (Low). Предполагается, что у атакующего уже есть готовый эксплойт, и под «сложностью» подразумевается сложность его использования. Если для успешной эксплуатации требуется лишь запустить программу, то очевидно, что сложность будет низкая. Однако иногда злоумышленнику приходится прибегать к дополнительным действиям. Например, если он намерен провести фишинг-атаку (атаку, при которой жертва переходит по ложной ссылке и самостоятельно вводит конфиденциальную информацию на ресурсе злоумышленника, визуально похожем на основной ресурс), то он может использовать метод социальной инженерии, и в таком случае сложность эксплуатации считается средней. Однако социальная инженерия не всегда приводит к успеху, поэтому злоумышленник может прибегнуть к перехвату DNS, атаковав DNS-сервер. Тогда сложность эксплуатации будет высокой. Чем ниже сложность, тем выше числовая оценка базовой группы.
• Показатель аутентификации отражает сложности для атаки, связанные с необходимостью предоставления злоумышленником учетных данных. В модели CVSS аутентификация может вовсе не требоваться (None), требоваться один (Single) или множество (Multiple) раз. При этом, если уязвимость обнаружена в самой системе аутентификации, то считается, что аутентификация не требуется. Если требуется аутентификация для доступа в локальную сеть, из которой доступно уязвимое приложение, а в самом приложении аутентификация не требуется, то считается, что для эксплуатации уязвимости аутентификация не требуется.

Следующие три метрики базовой группы – влияние на конфиденциальность, влияние на целостность и влияние на доступность – определяют возможные последствия эксплуатации уязвимости. В каждой из этих метрик влияние может не оказываться (None), оказываться частично (Partial) и быть полным (Complete). Влияние на актив считается частичным, если оно может быть ограничено (например, нарушена конфиденциальность/целостность только определенной части файлов или прерывается доступность лишь некоторых компонент системы). Если к системе есть физический доступ или доступ с root-правами, то она считается полностью скомпрометированной.

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

На примере уязвимости Heartbleed (CVE-2014-0160) проведем оценку базовой группы метрик. Эта уязвимость является следствием ошибки в пакете OpenSSL (ошибка чтения за пределы аллоцированной памяти) и позволяет извлечь произвольные данные из оперативной памяти сервера. Для проведения атаки злоумышленнику нужно отправить специальным образом сформированный запрос на атакуемый сервер. То есть, злоумышленнику достаточно доступа из глобальной сети (Access Vector: Network). Сложность атаки сводится к запуску готового эксплойта (Access Complexity: Low). Аутентификация при этом не требуется (Authentication: None). Получение приватного ключа сервера означает частичную потерю конфиденциальности (Confidentiality Impact: Partial). Так как прочитать не загруженные в оперативную память данные не получится, на целостности и доступности потеря конфиденциальности никак не скажется (Integrity Impact: None, Availability Impact: None). Такой результат публикуется в виде сокращенного вектора (AV: N/AC: L/Au: N/C: P/I: N/A: N). Подставив значения из этого вектора в базовое уравнение, получаем числовую оценку 5.0 для исследуемой уязвимости.

Второй пример – уязвимость Shellshock, позволяющая удаленно производить выполнение команд при определенных значения переменных окружения вопреки задекларированным возможностям. В данном случае доступ также возможен по сети и для эксплуатации требуется лишь запуск эксплойта без аутентификации. Однако выполнение команд дает возможность нарушить не только конфиденциальность данных (прочитать файлы), но и их целостность (перезаписать файлы) и доступность (например, выключить сервер). Тогда мы получим итоговый вектор (AV: N/AC: L/Au: N/C: P/I: C/A: C) и оценку 10.0, ведь все показатели принимают наихудшие значения. Очевидно, что если в системе существуют обе уязвимости, то важнее сначала исправить вторую уязвимость, и базовая оценка позволяет это понять.

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

Временная группа включает три метрики:

• Возможность использования (Exploitability) уязвимости отражает состояние методов эксплуатации и доступность кода. Различают стадию теоретического существования эксплойта (Unproven), стадию существования концепции эксплуатации (Proof Of Concept) – когда можно провести демонстрацию, но на большинстве реальных приложений она не сработает, стадию существования сценария (Functional) – когда доступен код эксплойта и он работает в большинстве случаев без изменений, и стадию высокой (High) опасности, если эксплойт доступен и работает автономно на множестве устройств. Итоговая числовая оценка временной группы тем выше, чем проще использовать уязвимость.
• Уровень исправления (Remediation Level) отражает состояние обработки уязвимости. При этом различают стадию, когда никакое решение недоступно (Unavailable), а также стадии существования рекомендаций (Workaround), временного решения (Temporary) и официального исправления (Official Fix).
• Степень достоверности источника (Report Confidence), сообщившего об уязвимости – она может быть не подтверждена (Unconfirmed), не доказана (Uncorroborated) и подтверждена (Confirmed) вендором ПО.

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

В качестве примера проведем оценку временной группы для Heartbleed: на текущий момент доступны соответствующий эксплойт и официальный патч для уязвимой библиотеки, также известно, что уязвимость подтверждена. Тогда получаем вектор (E: H/RL: OF/RC: C) и оценку 4.4. Отметим, что оценка отлична от нуля даже после выпуска официального исправления, поскольку многие пользователи могли не применить его.

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

• Вероятность нанесения косвенного ущерба (Collateral Damage Potential) отражает насколько сильно могут пострадать активы, не связанные с уязвимым приложением. Эта вероятность может быть низкой (Low), средне-низкой (Low-Medium), средне-высокой (Medium-High) и высокой (High).
• Плотность целей (Target Distribution) отражает насколько сильно пострадает система в целом от эксплуатации уязвимости. Плотность целей может быть низкой, средней или высокой.
• Требования к конфиденциальности (Confidentiality requirements), требования к целостности (Integrity requirements) и требования к доступности (Availability requirements) — могут быть низкими, средними или высокими. Это определяется требованиями, предъявляемыми к уязвимой системе.

CVSS 3.0

К сожалению, версия CVSS 2.0 тоже оказалась не идеальной, в ней осталась проблема недостаточной информативности оценки, в данном стандарте также появлялись уязвимости с одинаковыми векторами, но с разной оценкой опасности. В FIRST (организацию, поддерживающую стандарт) было отправлено открытое письмо из Open Security Foundation, в котором дополнительно отмечались следующие проблемы:

• некоторые показатели CVSS трактуются неоднозначно – на разных ресурсах в базах уязвимостей, предоставляющих оценки CVSS 2.0, можно найти идентичные уязвимости, для которых указаны различные сложности эксплуатации;
• многие компании (Oracle, IBM, HP, Cisco) вместе с оценкой CVSS 2.0 начали использовать свои более информативные оценки или выставлять числовую оценку не в соответствии со стандартом;
• отсутствие качественной шкалы оценки и, как следствие, разная трактовка числовой оценки разными пользователями.

Рабочая группа CVSS-SIG начала работу над третьей версией стандарта, и в июне 2015 года она была опубликована. В нее были внесены следующие изменения:

1. Добавлен физический уровень доступа, подразумевающий доступ к аппаратному обеспечению системы.
2. Исключен средний уровень сложности эксплуатации – если для эксплуатации требуется выполнение специальных условий, неподконтрольных атакующему, или для выполнения которых потребуются проводить дополнительные атаки, то сложность эксплуатации считается высокой. В остальных случаях – низкой. Отдельным показателем вынесено взаимодействие с пользователем (User Interaction: None/Required).
3. Аутентификация заменена на оценку уровня привилегий (показатель Privileges Required) – этот уровень может быть высоким, низким или отсутствовать. Последнее значение эквивалентно отсутствию аутентификации, низкий уровень соответствует аутентификации с правами обычного пользователя, а высокий – с правами администратора. Данное изменение обусловлено тем, что число аутентификаций отражает сложность эксплуатации менее выразительно, чем качественная сложность каждой аутентификации (получить права администратора сложно, аутентифицироваться десять раз с правами обычного пользователя обычно не сложнее, чем сделать это один раз).
4. Скорректированы коэффициенты в уравнениях – оценка стала меньше зависеть от сложности эксплуатации и больше от причиняемого воздействия.
5. Введено понятие цепочки уязвимостей. Иногда эксплуатация нескольких уязвимостей единовременно несет гораздо большую опасность, чем каждая из уязвимостей отдельно.
6. Метрики воздействия из количественных перешли в качественные. Вместо частичного и полного влияния на конфиденциальность, целостность и доступность оценивается еше и критичность той части системы, на которую было проведено воздействие, в терминах среднего (Medium) и сильного (High) воздействия.
7. Введены понятия атакуемого и уязвимого компонента, границ эксплуатации. Иногда уязвимость, найденная в одной системе, влияет на другую, не связанную с ней. В CVSS 3.0 предлагается учитывать максимальное воздействие в каждом показателе и дополнительно повышать оценку опасности, если область действия атаки была изменена. Для этого добавлен показатель смены границы эксплуатации (Scope: Changed/Unchanged).

Два последних пункта из списка изменений заслуживают отдельного внимания. Чтобы продемонстрировать актуальность положений пункта 6, рассчитаем базовую метрику для уязвимости CVE-2018-4871. Уязвимость заключается в чтении за границами буфера в Adobe Flash Player и позволяет прочитать приватную информацию с ПК пользователя, доступную уязвимому приложению (по умолчанию – недоступно ничего). С позиций CVSS 2.0 эта уязвимость имеет точно такие же характеристики, как и Heartbleed. Однако утечка приватного ключа сервера позволяет расшифровать весь трафик, который когда-либо приходил на сервер от кого угодно. Поэтому сохранение конфиденциальности приватного ключа сервера гораздо важнее защиты информации на ПК. В CVSS 3.0 показатель конфиденциальности у Heartbleed признается высоким, а у только что описанной уязвимости – средним, итоговые оценки 7.3 и 5.3 соответственно.

Важность седьмого пункта можно продемонстрировать на примере CVE-2012-1516. Для эксплуатации этой уязвимости достаточно лишь запустить эксплойт (AC: L) на удаленной машине (AV: N), один раз авторизовавшись с правами обычного пользователя (AU: S – в CVSS v2.0 или PR: L в CVSS v3.0) в гостевой операционной системе. Взаимодействие с пользователем в процессе эксплуатации не требуется (UI: N). Уязвимым компонентом являются средства виртуализации, обеспечивающие работу гостевой операционной системы, однако эксплуатация данной уязвимости приводит к выполнению кода на основной, хостовой ОС, то есть, в итоге атакуется другой компонент (S: C). Выполнение кода на основной ОС потенциально открывает злоумышленнику намного больше возможностей, например, доступ к приложениям хостовой ОС, недоступным по сети. Возможность исполнения произвольного кода приводит к полной компрометации, потере целостности и доступности (C: C/I: C/A: C или C: H/I: H/A) основной ОС. Подставив CVSS 2.0 вектор (AV: N/AC: L/Au: S/C: C/I: C/A: C) в уравнение из стандарта получим оценку 9.0. В CVSS 3.0 вектор данной уязвимости (AV: N/AC: L/Pr: L/UI: N/S: C/C: H/I: H/A: H) и после подстановки получаем оценку 9.9. При этом похожий вектор уязвимости (AV: N/AC: L/Pr: L/UI: N/S: U/C: H/I: H/A: H) после подстановки получает оценку лишь 8.8. У этих векторов отличается лишь показатель смены границы эксплуатации – благодаря нему CVSS 3.0 позволяет адекватно отразить резкое увеличение опасности именно за счет атаки других компонентов.

Выводы

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

Авторы:
Павел Ханин, разработчик систем безопасности ООО «СолидСофт»,
Денис Гамаюнов, к.ф.-м.н., с.н.с. кафедры Информационной безопасности факультета ВМК МГУ.