Посмотрел подкаст двух Александров Герасимовых про Vul­ner­a­bil­i­ty Man­age­ment. Больше контента по VM‑у хорошего и разного! 👍 Сгруппировал для себя некоторые тезисы в части VM‑а для инфраструктуры. По VM для приложений там тоже было, но мне это не так близко и я отметил, только то, что необходимо интегрировать SAST/DAST/SCA в процессы разработки и деплоя. И чтобы были secu­ri­ty approver‑ы. Не поспоришь.

По инфраструктуре:

1. Пока не выстроены базовые процессы, такие как инвентаризация активов, сегментация сети, patch man­age­ment (регулярные обновления), заниматься Vul­ner­a­bil­i­ty Man­age­ment-ом рановато. Нужно понимать какие есть активы, кто эти активы сопровождает, что эти активы из себя представляют (на уровне операционной системы и на уровне ПО), какие активы являются для организации критичными (Mis­sion Crit­i­cal, Busi­ness Crit­i­cal, Office Pro­duc­tiv­i­ty). В зависимости от этого настроить риски, недопустимые события, SLA по исправлению для типов активов и критичности уязвимостей, модель угроз ИБ.

2. Сканирования инфраструктуры недостаточно для VM-процесса. Безопасники должны выступать контролерами над уязвимостями: реагировать на критичные 0day уязвимости, отслеживать выполнение циклов регулярно патчинга со стороны IT. У актива должен быть функциональный администратор, бизнес-владелец и технический администратор. Накатывает патч технический администратор, через него идёт взаимодействие и он ответственен за патчинг. ИБ выступает как контроль и руками ничего не делает. Перед установкой патчи должны тестироваться, чтобы работа не нарушалась. При невозможности обновления используем компенсирующие меры (в т.ч. виртуальный патчинг).

3. VM на основе open source, какие могут быть проблемы? Сканеры имеют ограниченную пропускную способность, необходимо масштабировать сканеры и опредялять скоуп серверов, которые можно покрыть одним решением. Должен быть единый центр управления для разбора отчётов. Нужно понимать какие активы есть в организации и есть ли у нас средства детектирования под все типы активов (например, Ora­cle, российские ОС или сетевые устройства). От меня: основная часть VM‑а это средства детектирования уязвимостей. Если вы уверены, что можете покрыть всю инфраструктуру адекватными детектами уязвимостей с помощью бесплатного средства — замечательно. Но постарайтесь это проверить, скорее всего обнаружите активы для анализа которых вам понадобится коммерческое решение.

4. Важно, чтобы VM-продукты имели возможности по интеграции. Для снижения риска утечек паролей из VM-решения, лучше организовывать доступ к кредам для безагентного сканирования через системы а‑ля Cyber­Ark. Для отслеживания выполнения заявок на исправление уязвимостей можно использовать интеграцию с SOAR и IRP системами.

Awillix делают периметровый сервис Con­tin­u­ous vul­ner­a­bil­i­ty mon­i­tor­ing (CVM), считают это очень востребованной темой. От меня: периметровые сервисы это очень конкурентная область. Со стороны клиента важно оценивать качество детектирования, хоть делать это, как правило, непросто.