Общий обзор систем оценки уязвимостей (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 группы метрик определяются следующим образом:
- Базовая группа метрик отражает «неотъемлемые и фундаментальные характеристики уязвимости, которые являются постоянными с течением времени и пользовательскими средами».
- Временная группа метрик отражает «характеристики уязвимости, которые меняются со временем, но не среди пользовательских сред».
- Контекстная группа метрик отражает «характеристики уязвимости, которые являются релевантными и уникальными для конкретной среды пользователя».
- Способ получения доступа может быть локальным (Local) и удаленным через смежную (Adjacent) или глобальную (Network) сеть, при этом чем более удаленным от атакуемой цели может быть злоумышленник, тем выше будет базовая оценка.
- Сложность атаки может быть высокой (High), средней (Mid) и низкой (Low). Предполагается, что у атакующего уже есть готовый эксплойт, и под «сложностью» подразумевается сложность его использования. Если для успешной эксплуатации требуется лишь запустить программу, то очевидно, что сложность будет низкая. Однако иногда злоумышленнику приходится прибегать к дополнительным действиям. Например, если он намерен провести фишинг-атаку (атаку, при которой жертва переходит по ложной ссылке и самостоятельно вводит конфиденциальную информацию на ресурсе злоумышленника, визуально похожем на основной ресурс), то он может использовать метод социальной инженерии, и в таком случае сложность эксплуатации считается средней. Однако социальная инженерия не всегда приводит к успеху, поэтому злоумышленник может прибегнуть к перехвату DNS, атаковав DNS-сервер. Тогда сложность эксплуатации будет высокой. Чем ниже сложность, тем выше числовая оценка базовой группы.
- Показатель аутентификации отражает сложности для атаки, связанные с необходимостью предоставления злоумышленником учетных данных. В модели CVSS аутентификация может вовсе не требоваться (None), требоваться один (Single) или множество (Multiple) раз. При этом, если уязвимость обнаружена в самой системе аутентификации, то считается, что аутентификация не требуется. Если требуется аутентификация для доступа в локальную сеть, из которой доступно уязвимое приложение, а в самом приложении аутентификация не требуется, то считается, что для эксплуатации уязвимости аутентификация не требуется.
- Возможность использования (Exploitability) уязвимости отражает состояние методов эксплуатации и доступность кода. Различают стадию теоретического существования эксплойта (Unproven), стадию существования концепции эксплуатации (Proof Of Concept) – когда можно провести демонстрацию, но на большинстве реальных приложений она не сработает, стадию существования сценария (Functional) – когда доступен код эксплойта и он работает в большинстве случаев без изменений, и стадию высокой (High) опасности, если эксплойт доступен и работает автономно на множестве устройств. Итоговая числовая оценка временной группы тем выше, чем проще использовать уязвимость.
- Уровень исправления (Remediation Level) отражает состояние обработки уязвимости. При этом различают стадию, когда никакое решение недоступно (Unavailable), а также стадии существования рекомендаций (Workaround), временного решения (Temporary) и официального исправления (Official Fix).
- Степень достоверности источника (Report Confidence), сообщившего об уязвимости – она может быть не подтверждена (Unconfirmed), не доказана (Uncorroborated) и подтверждена (Confirmed) вендором ПО.
- Вероятность нанесения косвенного ущерба (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 начали использовать свои более информативные оценки или выставлять числовую оценку не в соответствии со стандартом;
- отсутствие качественной шкалы оценки и, как следствие, разная трактовка числовой оценки разными пользователями.
- Добавлен физический уровень доступа, подразумевающий доступ к аппаратному обеспечению системы.
- Исключен средний уровень сложности эксплуатации – если для эксплуатации требуется выполнение специальных условий, неподконтрольных атакующему, или для выполнения которых потребуются проводить дополнительные атаки, то сложность эксплуатации считается высокой. В остальных случаях – низкой. Отдельным показателем вынесено взаимодействие с пользователем (User Interaction: None/Required).
- Аутентификация заменена на оценку уровня привилегий (показатель Privileges Required) – этот уровень может быть высоким, низким или отсутствовать. Последнее значение эквивалентно отсутствию аутентификации, низкий уровень соответствует аутентификации с правами обычного пользователя, а высокий – с правами администратора. Данное изменение обусловлено тем, что число аутентификаций отражает сложность эксплуатации менее выразительно, чем качественная сложность каждой аутентификации (получить права администратора сложно, аутентифицироваться десять раз с правами обычного пользователя обычно не сложнее, чем сделать это один раз).
- Скорректированы коэффициенты в уравнениях – оценка стала меньше зависеть от сложности эксплуатации и больше от причиняемого воздействия.
- Введено понятие цепочки уязвимостей. Иногда эксплуатация нескольких уязвимостей единовременно несет гораздо большую опасность, чем каждая из уязвимостей отдельно.
- Метрики воздействия из количественных перешли в качественные. Вместо частичного и полного влияния на конфиденциальность, целостность и доступность оценивается еше и критичность той части системы, на которую было проведено воздействие, в терминах среднего (Medium) и сильного (High) воздействия.
- Введены понятия атакуемого и уязвимого компонента, границ эксплуатации. Иногда уязвимость, найденная в одной системе, влияет на другую, не связанную с ней. В CVSS 3.0 предлагается учитывать максимальное воздействие в каждом показателе и дополнительно повышать оценку опасности, если область действия атаки была изменена. Для этого добавлен показатель смены границы эксплуатации (Scope: Changed/Unchanged).
Выводы
Идеальную систему оценки уязвимостей создать скорее всего невозможно. Даже в актуальной версии стандарта CVSS 3.0 могут быть неоднозначные трактовки, например, при определении важности приватной информации. Однако, использование любой версии CVSS в большинстве случаев позволяет правильно расставить приоритеты в обработке уязвимостей и оценить возможные риски. Самую детальную оценку позволяет проводить последняя версия стандарта. Но если в организации уже существует большая база с оценками, выполненными по предыдущей версии CVSS, то переход на более современную версию может оказаться слишком трудозатратным и не принести нужного результата.Авторы:
Павел Ханин, разработчик систем безопасности ООО "СолидСофт",
Денис Гамаюнов, к.ф.-м.н., с.н.с. кафедры Информационной безопасности факультета ВМК МГУ.
Интернет-портал «Безопасность пользователей в сети Интернет»
admin@safe-surf.ru
https://safe-surf.ru