ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 45
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Практическая работа: «Оценка опасности угроз НСД».
Изучить теорию:
Системы оценки уязвимостей (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 баллов и короткое текстовое описание, содержащее всю необходимую информацию для вывода этой оценки.
Рисунок 1: Общая система оценки уязвимостей CVSS
В стандарте CVSS группы метрик определяются следующим образом:
Базовая группа метрик отражает «неотъемлемые и фундаментальные характеристики уязвимости, которые являются постоянными с течением времени и пользовательскими средами».
Временная группа метрик отражает «характеристики уязвимости, которые меняются со временем, но не среди пользовательских сред».
Контекстная группа метрик отражает «характеристики уязвимости, которые являются релевантными и уникальными для конкретной среды пользователя».
Базовая группа метрик включает в себя шесть метрик. Первые три – способ получения доступа (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) - могут быть низкими, средними или высокими. Это определяется требованиями, предъявляемыми к уязвимой системе.
Рисунок 2: Оценка по CVSS
CVSS 3.0
К сожалению, версия CVSS 2.0 тоже оказалась не идеальной, в ней осталась проблема недостаточной информативности оценки, в данном стандарте также появлялись уязвимости с одинаковыми векторами, но с разной оценкой опасности. В FIRST (организацию, поддерживающую стандарт) было отправлено открытое письмо из Open Security Foundation, в котором дополнительно отмечались следующие проблемы:
некоторые показатели CVSS трактуются неоднозначно – на разных ресурсах в базах уязвимостей, предоставляющих оценки CVSS 2.0, можно найти идентичные уязвимости, для которых указаны различные сложности эксплуатации;
многие компании (Oracle, IBM, HP, Cisco) вместе с оценкой CVSS 2.0 начали использовать свои более информативные оценки или выставлять числовую оценку не в соответствии со стандартом;
отсутствие качественной шкалы оценки и, как следствие, разная трактовка числовой оценки разными пользователями.
Рабочая группа CVSS-SIG начала работу над третьей версией стандарта, и в июне 2015 года она была опубликована. В нее были внесены следующие изменения:
Добавлен физический уровень доступа, подразумевающий доступ к аппаратному обеспечению системы.