При построении надежных и защищенных систем одна из главных задач — максимально увеличить стоимость атаки для злоумышленников. Одной из составляющих этого процесса и является выстраивание системы Управления уязвимостями.
Каждый день появляются новые уязвимости, на создание эксплойтов уходит примерно сутки, а патчи на критичные баги накатываются месяцами. Если посмотреть на успешные атаки в 2025 году, то можно увидеть, что точкой входа были сервисы, для которых уже были выпущены обновления.
Уязвимостью можно считать не только ошибку в коде, но и неправильно сконфигурированное ПО, наличие избыточных привилегий на учетной записи, использование устаревших версий ОС, словарные пароли и многое другое.
Самый главный вывод здесь — это не техническая проблема, а про процессы внутри компаний. Совместная работа ИТ и ИБ — главный фактор успеха любого процесса управления уязвимостями.
За словами Vulnerability Management кроется не просто модное название, а целый ряд процессов, действий и систем, которые в конечном итоге сделают вашу инфраструктуру защищеннее. Управление уязвимостями — это не только про инструменты, но и про культуру, коммуникации и знания. Без этого даже лучшие решения останутся просто красивой оберткой.
Прежде всего, как ИТ так и ИБ должны осознавать, что Управление уязвимостями это не про формальные отчеты сколько нашли и закрыли, а про реальный контроль защищенности внешних и внутренних систем. Не все уязвимости одинаково опасны и зачастую грамотная приоритезация помогает гораздо быстрее закрыть то, что эксплуатируется прямо сейчас.
Начать хотелось бы с общих терминов и того, что вообще из себя представляет Vulnerability Management. Я не буду сильно углубляться в понятия, просто чтобы были понятны основные шаги.
VM — это не просто название продукта одного из вендоров или файл, который вы получили в результате работы nmap. За этой аббревиатурой стоит целый конвейер действий как систем, так и людей, которые в конечном итоге сливаются в единый поток. Управление уязвимостями — это непрерывный процесс и даже если вы закрыли все, что могли на данный момент, завтра выйдут новые CVE и обнаружат очередные 0day и все начнется сначала.
Из каких шагов состоит сам процесс VM?
Инвентаризация активов. Фундаментом построения VM является asset management или управление активами — вы должны планировать, учитывать и отслеживать все элементы ИТ-инфраструктуры. Для чего нужна инвентаризация активов? Во-первых, это помогает нам распределять их по группам, что делает процесс сканирования удобнее. Во-вторых, помогает понять общую топологию сети и сравнить ИБ карту с аналогичной от коллег из ИТ. Если пропустить хотя бы один тестовый сервер, именно он и станет той точкой входа, через которую взломают компанию. Как и уязвимости, активы необходимо приоритезировать, так как при согласовании SLA вы будете учитывать критичность актива, требование по его доступности, технологическое окно и т.д.
Выявление уязвимостей. После того как вы составили список всех активов своей сети, как внешних, так и внутренних, в том числе в облаках (при сканировании активов в сети облачного провайдера могут быть свои нюансы), необходимо просканировать их и понять, какие сервисы уязвимы и к чему.
Источники могут быть абсолютно разные, например БДУ ФСТЭК России или MITRE CVE. Если у вас решение класса VM, то дополнительно будут доступны сведения от вендора. На примере MaxPatrol VM — очень выручают и полезны Трендовые уязвимости. Перед проведением сканирования вы должны определить какие активы сканировать, выбрать для них профили и расписание (сетевые устройства и AD лучше сканировать ночью, когда нет большой нагрузки, а компьютеры пользователей днем, когда они включены, в идеале на обеде, чтобы никому не мешать).
Согласуйте с коллегами из ИТ, в случае если ваше VM решение позволяет это сделать, проведение сканирования не только в режиме белого ящика, когда у нас есть выделенная учетная запись и заранее известный профиль, но и в режиме пентест (черный ящик), когда сканер будет имитировать действия злоумышленника. Это позволит получить наиболее полную картину об уязвимостях инфраструктуры.
Если у вас есть (а где их нет?)) legacy или те активы, какие по каким-то причинам не получается сканировать, здесь тоже есть выход. Во-первых они в принципе должны быть на особом контроле, во-вторых здесь нужен ручной режим — берем всю доступную информацию по таким устройствам и системам от вендоров, с форумов и иных источников уязвимостей. Если что-то нельзя исправить и в тоже время убрать из продакшена, нужно хотя бы понимать, перед чем оно уязвимо.
Приоритезация уязвимостей. После того, как все уязвимости были выявлены на этапе сканирования, необходимо определить, какие уязвимости требуют немедленного устранения. Логично предположить, что исправление critical и high уязвимостей, гораздо важнее, нежели потратить все внимание коллег из ИТ на low или info. На примере MaxPatrol VM — Трендовые уязвимости — это то, что нужно закрывать в первую очередь.
Нельзя однозначно ответить именно по вашей инфраструктуре, что считать наиболее важным, но можно начать с того, чтобы закрыть все критические уязвимости на периметре и любых потенциальных точках проникновения (простыми словами, все что смотрит в интернет, там где есть доступ у подрядчиков и т.д.). Решите, какие активы для вас являются ключевыми и начните с них. Дополнительно, можно принимать во внимание фактор наличия готового эксплойта или PoC на GitHub. Такие активы, особенно если они доступны потенциальному злоумышленнику на внешнем периметре, лучше закрывать первыми.
Устранение уязвимостей. Теперь необходимо принять меры по нейтрализации того, что обнаружили. Не всегда уязвимости могут быть устранены патчами и обновлениями, иногда требуется изменить конфигурацию системы или отключить старые службы и протоколы.
В этот же пункт можно включить комплаенс-контроль и соответствие стандартам. Есть различные бенчмарки, какие позволяют это сделать, например CIS Benchmarks. Я приведу на примере продуктов от Positive Technologies так как знаком с ними лучше всего. В MaxPatrol VM есть стандарты, разработанные Positive Technologies, которые позволяют проверить различное оборудование на предмет соответствия базовым требованиям безопасности. На основе этих стандартов вы можете создать политику, которую примените к найденным ранее активам. Это можно сделать и с помощью других инструментов, в данном случае мы просто берем экспертизу и лучшие практики от вендора. Самое главное, что нужно запомнить — вы должны проверять ваше оборудование не только на известные уязвимости, но и на ошибки в конфигурациях. Ваш условный роутер может быть полностью обновлен, но неправильно настроен, что и вызовет за собой потенциальное недопустимое событие в сети.
Что касается самих уязвимостей, то устранять их можно различными способами. Во-первых плановой установкой обновлений. Здесь важно договориться с коллегами из ИТ об SLA, учитывая то, что регулярные обновления нужно еще протестировать и устанавливать только в технологические окна. Исключением из правил можно считать трендовые уязвимости, которые требуют установки внеочередных обновлений.
Если для актива больше не выпускают обновлений или он скоро будет выведен из эксплуатации, его можно поставить на расширенный мониторинг, отключить (при возможности) тот функционал, в которым были найдены уязвимости, попробовать изменить конфигурацию (если дело в ней) или по возможности рассмотреть переход на новую версию ПО или той системы, которую нет возможности обновлять.
На этом этапе вы должны решить, в какую систему будут выгружаться найденные уязвимости и где будет происходить процесс контроля и взаимодействия с коллегами из ИТ. Чем больше вы сможете автоматизировать этот процесс, тем эффективнее выстроите его. Любое ручное действие вызывает неприятие. Важно проверить, чтобы при повторной выгрузке в отчет не попадала устаревшая информация по тем уязвимостям, какие коллеги из ИТ успели исправить.
Контроль устранения. Этот этап является заключительным и обеспечивает проверку эффективности принятых мер.
Данный процесс также требует максимальной автоматизации, отдельное внимание стоит обратить на контроль устранения трендовых уязвимостей. Здесь важно посмотреть насколько эффективен и выполним SLA, который согласовали ИБ и ИТ, посмотреть на те места, которые вызывают трудности (какое-то обновление даже после тестирования не установилось так, как надо), по возможности рассматривать каждый случай в индивидуальном порядке. После первых итогов, вы сможете настроить расписание сканирования и совместно с коллегами из ИТ поставить данный процесс на конвейер.
Картина выше, почти идеальный пример того, как можно построить VM процесс в компании. На деле, те кто хоть раз занимался выявлением и исправлением уязвимостей знают, что все гладко только на бумаге. С какими трудностями чаще всего сталкивается специалист по VM?
Самое главное — научиться не просто договариваться с коллегами из ИТ про SLA и другие умные аббревиатуры, важно включить их в сам процесс Vulnerability Management.
Давайте встанем на их сторону. Что главное для ИТ? Фокус на бесперебойной работе систем и сервисов и внедрение новых технологий. Мы как специалисты по информационной безопасности заняты минимизацией рисков и защитой данных. Как найти золотую середину? Здесь конечно же все зависит от конкретных людей с обеих сторон.
К примеру, возьмем сканирование сетевого сегмента. Для уменьшения нагрузки, мы можем предложить сетевикам запретить на TACACS выполнение самых ресурсоемких команд и договориться о полном сканировании в определенное время. Получаем win/win.
Нельзя игнорировать проблему shadow IT. Все новые сервера должны пройти проверку на уязвимости, внесены на карту и только тогда вводиться в эксплуатацию. Такой процесс может показаться долгим, но на деле 95% действий здесь автоматизируются. Соответственно, если договориться с коллегами из ИТ, этот процесс может протекать безболезненно, в противном случае, специалисту по VM придется настраивать autodiscovery и другие инструменты для выявления теневых активов.
С чем еще можно столкнуться?
Покупка сканера не равна решению всех проблем, VM софт всего лишь инструмент, а Vulnerability Management — это процесс, который в том числе и с помощью данного ПО вам предстоит выстроить совместно с коллегами. Обнаружить уязвимость еще не значит защититься от нее. Важно не попасть в ситуацию, когда руководство думает, что выделили средства и на этом все, ИТ считает, что все остальное проблема безопасников, а коллеги из ИБ живут с мыслью — наша работа завершается на этапе сканирования. Процесс Управления уязвимостями — общий для всех.
При выстраивании VM вы можете столкнуться с неприятием новых инструментов и услышать знакомое — “мы всегда так работали”. Это может касаться процесса передачи результатов сканирования, когда раньше это делали на флешке или нежелание встраиваться в новый SLA, когда обновления придется ставить быстрее. Если договориться не получается, помогают директивы со стороны руководства. В тоже время важно вовлекать коллег из ИТ с самого начала и попытаться не навязывать решения сверху, а совместными усилиями сделать инфраструктуру безопаснее. Иногда достаточно продемонстрировать не лист с CVE, а результат реализации недопустимого события, само собой на тестовом сервере. Начать можно не с 50000 уязвимостей, а с 50 наиболее критичных. Вы исправите самое важное, а коллеги из ИТ получат доказательство того, что вы на одной стороне. И помним — всю рутину автоматизируем по максимуму.
Важно понимать, что построение VM требует определенных усилий, как финансовых так и человеческих. Это не та задача, какую специалист может решить “в свободное время”. Nmap и Excel конечно могут быть задействованы, но лучше использовать профессиональные решения от вендоров.
Теперь про SLA. При его согласовании важно помнить одну простую вещь. Если на веб-сервере компании нашли RCE с оценкой 9+ для которого есть готовый эксплойт, согласование устранения такой уязвимости не должности занимать неделю. Есть плановое устранение, есть экстренное реагирование.
Последнее о чем хотелось бы сказать это сами специалисты, которые будут заниматься как сканированием, так и построение самого процесса. Если в штате нет человека, которые понимает, что он делает, как строить VM, как работает сканер — в первую очередь его нужно обучить. Курсы от вендора или просто дать время, но сотрудник должен понимать как теоретическую часть, так и то, как работать с конкретным решением. В противном случае можно попасть в ситуацию, когда половина доступного функционала просто не будет использоваться и сам VM будет построен по системе “главное отчитаться”. Так делать нельзя.
Самое главное запомнить одну простую истину, VM — это не проект с дедлайном, а непрерывный процесс, который при всей автоматизации не живет сам по себе и время от времени нуждается в обновлении. Vulnerability Management ломается не потому, что инструменты плохие, а потому что организация и сотрудники в ней? не готовы его поддерживать, отсутствует коммуникация между ИТ и ИБ, нет автоматизации, контроля, ресурсов и понимания в целом. Исправьте это и из бумажного процесса VM превратится в реальную защиту вашей инфраструктуры.
В конце хочу привести интересную ссылку на Спецпроект от Инфосистемы Джет.
Результаты тестирования решений для управления уязвимостями