Все специалисты по кибербезопасности, использующие сканеры уязвимостей, сталкиваются с проблемой при сканировании узлов своей инфраструктуры - количество уязвимостей стремится к бесконечности.
Эксперт по кибербезопасности компании InnoSTage – Александр Борисов, поделился своим use-case опытом, который поможет администраторам безопасности в их ежедневной работе.
Было придумано множество полезных способов обходить эти проблемы: мониторинг неустановленных обновлений, устранение уязвимостей только с метрикой CVSS (Common Vulnerability Scoring System)>9 и т.д. Однако, эти подходы имеют определённые недостатки, поскольку не отражают значимость уязвимости с точки зрения злоумышленника. Безусловно, существуют готовые решения, позволяющие выстраивать векторы атак злоумышленников на результатах работы тех или иных сканеров. Такие системы помогают сводить список уязвимостей к минимуму, но имеют два существенных «недостатка»: требуют существенных финансовых вложений и высокой квалификации персонала.
Предлагаю четыре шага, которые позволят сократить количество приоритетных уязвимостей с астрономических высот до адекватных чисел без высоких финансовых вложений.
Шаг 1 – формируем критерии для уязвимостей, которые считаем самими важными.
Как понять, что является самым важным? Тут в голову приходит абстрактная модель злоумышленника: есть сетевой доступ к объекту, есть навыки по эксплуатации хотя бы частично описанных уязвимостей. Возьмем данную модель за основу и переходим к следующему шагу.
Шаг 2 – определение базовых метрик уязвимости.
Базовые метрики - используются для описания основополагающих сведений об уязвимости — возможности эксплуатации уязвимости и воздействии уязвимости на систему.
У каждой известной уязвимости программного обеспечения имеется базовая метрика CVSS, в которой есть стандартизированное описание этой самой уязвимости.
Рассматривать описание всех базовых и временных метрик CVSSv2 и CVSSv3 не будем, об этом уже достаточно написано. Для любознательных, оставлю ссылки на первоисточник CVSSv2 (ссылка) и CVSSv3 (ссылка). Давайте остановимся на самых интересных метриках CVSS.
1. Метрика AV (Access Vector) – описывает возможный способ эксплуатации (сетевой, смежная сеть, локальный, физический).
Network/Adjacent Network (AV:N, AV:A) интересует нас в первую очередь т.к. предполагает сетевую доступность для злоумышленника. Локальную и физическую доступность рассматривать не будем. Если злоумышленник получил физический доступ к оборудованию, тут уже только чудо поможет. Если же получил локальный доступ, вариантов действий у злоумышленника так же довольно много, и они могут не предполагать дальнейшего повышения привилегий и локальной эксплуатации уязвимости.
2. Метрика Access Complexity (AC) – описывает сложность эксплуатации уязвимости (низкая, средняя, высокая). На мой взгляд, весьма полезная, но субъективная метрика.
Предлагаю рассматривать AC:L и AC:M, т.к в случае AC:H участвует довольно большое количество факторов, которые могут препятствовать успешной эксплуатации уязвимости.
3. Метрика Authentication (Au) – в CVSSv2 Authentication (Au) описывает требования к аутентификации (однократная, несколько раз, аутентификация не нужна). В CVSSv3 Privileges Required (PR) метрика претерпела изменения и показывает необходимые привилегии для эксплуатации уязвимости (высокие, средние и без привилегии).
Нам интересен следующий случай:
CVSSv2 Au:N – для эксплуатации аутентификация не нужна.
CVSSv3 Pr:N – для эксплуатации привилегии не нужны в системе.
Уязвимости, которые требуют аутентификации или привилегий в том или ином варианте предлагаю исключить т.к. они предполагают, что злоумышленник уже повысил себе привилегии или скомпрометировал УЗ.
4. Метрика User Interaction (UI) – появилась в CVSSv3 и описывает необходимость взаимодействия с пользователем (с взаимодействием, без взаимодействия).
Нам интересно только UI:N – уязвимость не требующая взаимодействия с пользователем. Уязвимости UI:R требуют элемента социальной инженерии. Данную категорию предлагаю исключить т.к. социальная инженерия всегда дает исключительные возможности для злоумышленника и без использования уязвимостей.
Итого по базовым метрикам:
Внимание должны привлекать уязвимости, попадающие под следующие критерии:
CVSSv2 AV:[NA]; AC:LM; Au:N
CVSSv3 AV:[NA]; AC:LM; Pr:N; UI:N
Какую итоговую метрику получаем? Посчитаем метрику при помощи калькулятора: https://bdu.fstec.ru/calc . Получаем детектирование потенциально опасной уязвимости от уровня 5.7 для CVSSv2:
Шаг 3 – оценка временных метрик уязвимостей.
Временные метрики - при их оценке учитываются параметры, которые изменяются со временем, например, опасность уязвимости снижается с выходом официального обновления безопасности.
Из всех временных метрик нас будет интересовать только exploitability - возможности эксплуатации.
E:H – существует эксплойт (публично описан метод эксплуатации / общедоступны детали работы эксплойта) позволяющий эксплуатировать уязвимость в автоматизированном виде. №1 в списке на устранение т.к. может быть эксплуатирован в том числе и ВПО (компьютерные черви и вирусы).
E:F – Функциональный эксплойт существует, работает не всегда. Успешность зависит от окружения.
E:POC – стабильная эксплуатация эксплойта невозможна, уязвимость эксплуатируется в лабораторных условиях. Необходима доработка эксплойта для попыток реализовать атаку в боевой инфраструктуре. Несмотря на то, что в CVSSv2 предполагается что доработку эксплоитов может производить только злоумышленник обладающей серьезной компетенцией, такое исключать не стоит.
ND/X – тот случай, который нас не интересует, такие можно сразу исключать.
Итого по временным метрикам:
E:[H, F,POC] – наличие такой метрики явный сигнал к устранению уязвимости.
Шаг 4 – проверка метрик по базе MITRE ATT&CK
MITRE ATT&CK – общедоступная база знаний о тактиках поведения киберпреступников, основанная на реальных наблюдениях.
База MITRE ATT&CK содержит указание на некоторые используемые уязвимости. Наличие уязвимости в матрице – достаточное условие для ее устранения, несмотря на возможное отклонение от подхода, описанного выше.
Уязвимости, вошедшие в MITRE ATT&CK, попадают туда в результате их использования в различных фреймворках, ВПО, известными хакерскими группировками, что дополнительно увеличивает интерес к данным уязвимостям злоумышленников и, как следствие, должно вызвать наше повышенное внимание.
Например, один из описанных методов - https://attack.mitre.org/techniques/T1068/ - повышение привилегий. В примере мы видим, что уязвимость CVE-2014-4076 была использована группировкой APT28. И хотя она имеет CVSSv2: (AV:L/AC:L/Au:N/C:C/I:C/A:C), что не подходит по метрике AV:L, использование данной уязвимости хакерами является основанием для включения ее в список на устранение.
Ниже мои рекомендации для CVSSv2 и для CVSSv3, что выбирать и с чем работать – вопрос личных предпочтений, уже имеющихся скриптов, настроенных интеграций и т.д.
1. Первая очередь
CVSS = 9-10
Временная метрика для CVSSv2 E:[H,F,POC]
Временная метрика для CVSSv3 E:[H,F,P]
2. Вторая очередь
Базовая метрика:
Для CVSSv2 AV:[N,A]/AC:[LM]/AU:N
Для CVSSv3 AV:[N,A]/AC:L/Pr:N/UI:N
Временная метрика для CVSSv2 E:[H,F,POC]
Временная метрика для CVSSv3 E:[H,F,P]
3. Уязвимости упомянуты в MITRE ATT&CK
Ниже представим реализацию такого подхода на примере одной инфраструктуры.
Исходные данные: результаты сканирования инфраструктуры с учетной записью и без учетной записи. Для нашего примера рассмотрим только CVSSv2.
Выявленные уязвимости:
Разложим уязвимости по полочкам:
После удаления дублей количество уязвимостей из MITRE в этой инфраструктуре оказалось 0. Эти уязвимости попадали либо в первую группу, либо во вторую.
На выходе мы получаем:
уязвимостей первой очереди на устранение 9,
второй очереди на устранение 25.
Это дает нам 1,23% от общего количества уязвимостей и 3,51% от уязвимостей высокого уровня.
Итог
Экономит ли это нам время на понимание, куда бежать и что делать? Да, безусловно. Приносит ли это некоторую ясность в процесс управления уязвимостей? Да.
Использование такого подхода позволяет оперативно выделить уязвимости, которые должны были быть закрыты уже «вчера». При этом, надо понимать, что уязвимости, которые не попали в данную выборку – все так же представляют угрозу для информационной безопасности исследуемого объекта, и устранять их тоже надо.
Ссылки на дополнительные материалы: