Привет, Хабр! В этой статье поделюсь опытом и знаниями построения менеджмента уязвимостей в компании, ведь этот процесс, на мой взгляд, — базис информационной безопасности.
Предисловие. Почему VM важен?
Первый грейд (уровень) хакера начинается со Script Kiddy, то есть освоения навыка эксплуатации публичных уязвимостей с помощью эксплойтов, опубликованных как в открытом доступе (Metasploit, Github etc), так и написанных самостоятельно.
Если вы спросите опытного пентестера (понятие «хакер» больше относится к незаконной деятельности), какие первые шаги он совершает в исследовании инфраструктуры на проникновение, то большая часть скажет, что проверяет объект на наличие публичных уязвимостей и возможность их проэксплуатировать. Это касается и внешней (опубликованной в интернете, например SMTP-сервера), и внутренней инфраструктуры (Active Directory). В среде пентестеров есть понятие «низко висящие фрукты» — это когда задачу по «пролому» цели можно выполнить очень быстро благодаря исследованным ранее уязвимостям и готовым эксплойтам. Как говорится, увидел PrintNightmare (CVE-2021-1675 и CVE-2021-34527) в инфраструктуре и захватил ее всю.
И тут вывод напрашивается сам. Безопасность инфраструктуры должна начинаться с менеджмента уязвимостей, а уж всякая проактивная защита (антивирусы, IDSы, файрволлы и прочее) идти в дополнение.
Что представляет собой VM?
Если максимально просто, то этот процесс можно разделить на три этапа:
Инвентаризация активов (хостов) компании и установленного ПО (в том числе версии) на них.
-
Поиск по базам уязвимостей уязвимостей в ПО из п. 2.
Например:
Патч-менеджмент (устранение уязвимостей обновлением или выработка компенсирующих мер, таких как ограничение доступа к ПО или применение средств защиты в крайнем случае).
И так по кругу на регулярной основе.
Чем VM отличается от пентеста? Что приоритетнее для компании?
В отличие от пентеста, у процесса VM мягче «правила игры». Пентест подразумевает действия, в целом имитирующие злоумышленника (хакера), а это динамический подход к поиску уязвимостей инфраструктуры (мануальный и автоматизированный).
Подробно об этом подходе я уже писал:
Импортозамещение сканеров WEB уязвимостей: обзор актуальных DAST решений
Защита внешнего сетевого периметра компании через регулярный пентест
VM же — это статичный процесс. То есть ваша основная задача — выявить уже известные уязвимости в ПО компании (версиях и его конфигурации) и предоставить рекомендации отделу ИТ по их устранению. При этом у вас привилегированный доступ к инфраструктуре и нет каких-либо препятствий в виде средств защиты.
Кажется, что VM проще и эффективней пентеста, ведь мы не тратим ресурс компании на квалифицированных пентестеров, да и по затрате времени VM выглядит привлекательней. Возникает вопрос: а не заменить ли пентестеров на менеджеров уязвимостей?
Вот это - заблуждение бизнеса в выстраивании информационной безопасности компании.
Дело в том, что VM строится «изнутри» инфраструктуры. Нельзя с помощью VM понять, насколько опасно сконфигурирован внешний периметр. VM не решает задачи эксплуатирования мисконфигураций, злоупотребления функционалом и вообще формируется на поиске уязвимостей, которые были ранее обнаружены и описаны пентестерами! То есть надеясь только на VM, бизнес всегда будет на шаг позади даже по наличию уязвимостей в ПО, не говоря о других векторах атаки (тех самых web-уязвимостях, мисконфигурациях и эксплуатациях функционала).
Таким образом VM — это относительно недорогой, но крайне важный процесс, далеко не единственный в выстраивании ИБ в компании. Он позволяет защититься от Script Kiddy и даже APT-группировок (хакерских сообществ), которые при нетаргетированных атаках используют все те же «низко висящие фрукты».
Как сформировать VM?
На мой взгляд, есть 3 пути для организации менеджмента уязвимостей.
Первый путь. Когда нет бюджета на покупку ПО для ИБ
Инвентаризация.
Делаем с помощью open-source-инструментов и ручного труда. Для обнаружения активов (хостов) можно использовать сетевой сканер Nmap. Однако инвентаризацию ПО придется проводить вручную, собирая информацию с хостов. Облегчить сбор установленных пакетов можно с помощью утилит.
Далее нужно сформировать таблицу с обнаруженным ПО и постоянно ее актуализировать. Работа посильная для небольших инфраструктур.
-
Поиск CVE, как вы понимаете, — занятие не менее трудозатратное. Нужно взять базы и смотреть в них уязвимости по обнаруженным нами в 1-й стадии ПО. Нюанс в том, что часто в новых уязвимостях вообще не заполнены характеристики (CVSS, CWE). Поэтому не будет понятно, насколько опасна уязвимость, как эксплуатируется и на что воздействует, а есть лишь описание, которое придется читать.
Вот пример новой незаполненной CVE, где кроме описания ничего нет. А с учетом того, что каждый день таких вот CVE приходит с десяток, работа эта времязатратная, но есть в ней неоспоримый плюс. Исследуя базы CVE вручную, самые новые известные уязвимости вы сможете выявить раньше, чем сканер, из-за лага обновления баз.
Патч-менеджмент здесь будет представлять как направление поручений ИТ-отделу после мануальной экспертизы, в ходе которой мы находим патч или другие рекомендации по устранению от вендора (если рекомендаций нет, то закрываем средством защиты до их появления). Или решаем, что уязвимость не применима к нашей инфраструктуре. Контроль исправлений же — это по сути повторение 1 и 2 этапов. Будет не лишним вести таблицу с поручениями и кратким описанием.
Второй путь. Когда мы используем ПО для автоматизации поиска уязвимостей
Инвентаризация.
Производится уже с помощью ПО — сканеров уязвимостей.
О крупных Отечественных решениях писал тут:
В целом ситуация не поменялась, разве что Positive Technologies ушли в сторону создания ПО для VM полного цикла, о котором расскажу позже.
Автоматизация инвентаризации проходит таким образом, что вы сначала сканируете внутреннюю инфраструктуру режимом «пентест» или встроенным сетевым сканером Nmap. А затем добавляете обнаруженные активы в скоуп покрытия, группируя по основному функционалу (почтовые серверы, серверы БД, Active Directory и т.д.). Инвентаризация самого ПО, установленного в активах - задача сканера уязвимостей.
-
Этап поиска уязвимостей здесь самый комфортный — все делает сканер. Вам лишь нужно добавить учетные данные для доступа в актив (сервер) и создать задание на сканирование (об этом подробно в статье из п. 1). Результатом сканирования будет отчет, в котором мы увидим уязвимости в ПО (CVE, BDU), их критичность, описание и даже рекомендации по патчингу со ссылками на патчи вендоров или описанием, как исправить без таковых.
Пример карточки уязвимостей из Max Patrol VM Патч-менеджмент тут получится ручным. Точнее, не патч-менеджмент как таковой, а контроль исправлений. Желательно вести дашборд с поручениями ИТ-отделу и пересканировать активы для контроля исправления (благо, и RedCheck, и Max Patrol могут сделать диференцированный отчет, который покажет состояние ДО и ПОСЛЕ). В общем, даже со сканером уязвимостей без мануальной работы никак.
Третий путь. Когда мы используем ПО менеджмента уязвимостей полного цикла
Именно такое решение предлагает компания Positive Technologies https://www.ptsecurity.com/ru-ru/products/mp-vm/ в своем продукте Max Patrol VM.
Казалось бы, вот он: Грааль для VM, который решит все проблемы. Так ли это? Проверим.
MP VM — готовое решение по менеджменту уязвимостей. За счет продвинутого дашборда мы видим текущее состояние инфраструктуры (что выявлено в ходе сканирований и что уже пофикшено). Можно дать доступ к дашборду руководству или системным администраторам, ответственным за инфраструктуру, чтобы они сами могли реагировать на состояние уязвимостей в ПО. Поскольку решение работает через web, достаточно поделиться DNS-адресом и создать учетку с минимально необходимыми правами, например только на просмотр.
Для работы с активами и уязвимостями в MP VM реализован гибкий язык запросов к БД.
Можно здесь же построить и карту сети, просканировав все наши внутренние ресурсы по диапазонам IP.
Резюмируя увиденное, отмечу, что продукт MP VM оправдывает свое название: это готовый процесс VM в одном ПО. Но мы-то здесь не для рекламы продукта собрались ;)
Эффективность MP VM в решении задач VM
Если взять основного конкурента Positive Technologies — решение от Altex-Soft Red Check Expert, то в их эффективности полный паритет. Оба сканера находят одинаковое количество уязвимостей на момент исследования (мы тестировали как на Win-, так и на Linux-хостах), а значит, базы уязвимостей актуализируются у обоих сканеров оперативно и с одинаковой задержкой.
В свою очередь у MP VM есть, на наш взгляд, одна неточность, а именно — масштабирование уязвимостей. VM считает количество уязвимостей не так, например, как RedCheck (1 CVE — 1 хост, ну и в самой CVE указываются ПО, в которых она обнаружена, что логично). PT VM же считает одну CVE столько раз, сколько она упоминается в ПО на хосте, что для статистики страшнее, но для реального понимания дел излишне:
Отображение аналогичной CVE в RedCheck — одна CVE и список пакетов, в которых она присутствует.
Кроме как «для маркетинга» сложно понять, зачем такой подход у Positive Technologies в MP VM.
Идем далее — отчеты.
По какой-то непонятной причине в продукте MP VM отказались от отчетов в формате PDF по хостам. С одной стороны понятно, что отчеты в PDF имеют ограничения в размере, да и продукт сам по себе про интеграцию с другими системами и работу с управлением уязвимостями в самом приложении, но сценарии в разных компаниях могут отличаться. В общем, пока отчетов в PDF нет, только XLSX. PDF-отчеты вендор обещал сделать.
Конечно, выглядит как придирки, тут спорить не буду. Однако у MP VM все же есть серьезный недостаток: цена. Даже в сравнении с прямым конкурентом RedCheck Expert цена за актив (а эти продукты тарифицируются именно по активам) может отличаться в 15 раз. Да-да, именно в 15, то есть за стоимость покрытия одного актива MP VM можно покрыть 15 активов с помощью RedCheck Expert! Продукты предлагают разную автоматизацию процесса VM, но по эффективности поиска уязвимостей на хостах они одинаково хороши.
Так какой путь в выстраивании менеджмента уязвимостей в компании выбрать?
Нет ничего плохого в том, чтобы начинать выстраивать VM по первому пути, особенно если компания небольшая. В любом случае отказываться от него совсем нельзя, тем более в части поиска свежих уязвимостей, ведь в базы сканеров они добавляются с некоторой задержкой. Да и принцип «доверяй, но проверяй» в VM работает как никогда — бывали случаи, когда сканеры всех вендоров не видели критической уязвимости из-за багов. К тому же, этот путь частично можно автоматизировать и сделать подписку на новые CVE по софту, благо большинство баз это предлагают сделать бесплатно. Можно, в конце концов, написать скрипт, который по API будет собирать новые CVE из баз данных прямиком в какой-нибудь ваш дашборд, да хоть в графану. В любом случае отслеживать новые трендовые уязвимости вручную — хорошая практика.
Второй путь — самый распространенный. Здесь и процессы можно выстроить под себя, и отчеты. Это идеальное сочетание максимальной эффективности и небольшого бюджета: разница в эффективности поиска уязвимостей между дешевым RedCheck и дорогим MP VM ровным счетом никакая.
Третий путь — для корпораций с большими бюджетами на ИБ, особенно тех, кто строит ИБ на основе продуктов Positive Technologies (тут стоит сказать, что у других вендоров VM полного цикла я не видел, поэтому пока в СНГ PT монополисты). Продукты PT построены на принципе взаимоинтеграции, весь класс их решений безопасности можно интегрировать в одно окно как для работы, так и для контроля состояния инфраструктуры. Это позволяет экономить на человеческом ресурсе, однако цена неоправданно высока.