? Это часть 12 серии “Управление уязвимостями для самых маленьких” - практического руководства по VM с нуля. Главы самостоятельны, но если хочется по порядку - оглавление и все части серии тут.

В этой главе расскажу, как принципы из предыдущих глав работают на практике - на примере того, как управление активами и уязвимостями может быть устроено в реальном проекте. Дальше - собирательная картина из практики, а не описание какой-то одной конкретной компании. Примеры даны на MaxPatrol VM и PDQL-запросах, потому что это инструмент, который я знаю изнутри. Но это не про “купите MaxPatrol”. Это разбор подхода: динамические группы, автоматический ввод активов, связь серверов с недопустимыми событиями, контроль состояния - все это переносится на любую зрелую VM-систему. Читайте не “какие кнопки нажать”, а “какую логику выстроить”. Конкретный синтаксис у вашего инструмента будет свой.

На начальном этапе большая часть усилий должна уходить на управление активами: именно в ходе этого процесса мы получаем данные, без которых отчеты об уязвимостях - просто красивые картинки. Аналогия с BI-системами: они собирают данные из разных источников и рисуют дашборды. Но если данные на входе недостоверны, дашборды покажут красивую ложь. С управлением уязвимостями ровно так же: неверные данные об инфраструктуре - бессмысленные отчеты об уязвимостях. Поэтому главная задача управления активами - достоверно и своевременно давать сведения об инфраструктуре.

Второй ключевой фактор успеха VM - возможности ИТ-подразделения. Обычно о нем вспоминают только в контексте установки обновлений, но ИТ влияет на эффективность VM гораздо шире. Перед стартом нужно понять, какие процессы есть в ИТ, на каком они уровне, способны ли обеспечить ваши потребности. И тут важная мысль: вы должны выступать не только заказчиком, но и партнером. Не хватает ИТ ресурсов? Лоббируйте их интересы перед руководством, обосновывайте: эти ресурсы нужны и для ваших задач тоже. Под ресурсами понимаем все - людей, ПО, консалтинг, обучение.

Принципы построения системы

Чтобы процессы заработали, нужна система организационных и технических решений, которые не противоречат друг другу. Строить ее лучше на принципах. Почему именно на принципах? Запомнить, как действовать в каждой конкретной ситуации, невозможно - ситуаций бесконечность. А принципов немного, их легко запомнить, и они отвечают на вопрос “почему сделано именно так”. В нашем примере система построена на восьми принципах:

• Минимизация зависимости от человека. Сотрудник может заболеть, уйти в отпуск, сменить работу. Если процесс держится на нем одном, система неустойчива. Лекарство - документирование знаний, минимизация влияния ошибок, автоматизация.

• Точно вовремя. Знать об изменениях ровно тогда, когда они происходят или планируются. Для сервера важен момент ввода в эксплуатацию, а для информационной системы - стадия, когда ее внедрение только планируется.

• Максимальная достоверность. Нужны решения, которые позволяют точно сказать, есть ли актив в инфраструктуре. Без достоверности цель VM недостижима.

• Управление по отклонениям. Процессы проектируются так, чтобы человеку не нужно было вмешиваться в нормальный ход работ - только в нештатные ситуации. Стремитесь к тому, чтобы операционка занимала не более 50% времени специалистов. Остальное - на развитие.

• Самоконтроль. Нужны средства, позволяющие легко проверять правильность собственных действий. Если процесс не дает самоконтроля, придется строить дополнительные контуры и нанимать людей - дорого и неэффективно.

• Явный обмен информацией. Телепатов нет. Доносите коллегам из ИТ, DevOps и других подразделений информацию о своих действиях и их причинах в понятном виде.

• Встраивание в существующие процессы. Не множьте сущности. У каждого подразделения есть главная задача, и дополнительные процессы со временем забываются. Изучите процессы коллег и встройтесь в их точки, чтобы получать информацию об изменениях.

• Комбинация подходящих инструментов. Не внедряйте новые системы там, где можно использовать существующие (если это конечно же не снизит ваши трудозатраты существенным образом). Работаете с ИТ - задействуйте их инструменты и обогащайте их данные своими.

Обмен данными между компонентами

Немного технических деталей о том, как может быть организован обмен данными между компонентами - на примере одного из проектов.

Для учета активов в этом проекте используются две CMDB: NetBox (серверная и сетевая инфраструктура, подсети, IP-адреса, сервисы периметра) и “1С:ERP Управление предприятием” (клиентское оборудование: ноутбуки, системные блоки, мониторы). Две системы - потому что у разных типов активов разные требования к учету, и объединять все в одном инструменте смысла нет. Из “1С:ERP” загружается только связка “сотрудник - ноутбук” (по серийному номеру), чтобы понимать, кому какое устройство принадлежит. Данными NetBox пользуются ИБ и SOC.

Данные поступают в NetBox двумя путями: вручную (то, что нельзя внести автоматически) и автоматической загрузкой из систем виртуализации и облаков. Логика проста: если виртуальная машина есть в системе управления виртуализацией (неважно, включена она или нет), значит, она есть в инфраструктуре.

На сервере интеграции происходит обмен данными между системами, работают приложения по расписанию и микросервисы, к которым обращается NetBox по событиям. Преобразованные данные попадают либо в MaxPatrol VM, либо в таск-менеджер для постановки задач ИТ, либо в базу знаний для отчетности.

Ввод актива в эксплуатацию

Важное предварительное условие: все вводимые активы должны быть настроены под требования ИБ. Здесь на них нужно: настроить сбор журналов в MaxPatrol SIEM, установить агент MaxPatrol EDR и настроить учетные записи для сканирования в режиме Audit через MaxPatrol VM.

Сигнал для запуска процесса - создание актива в NetBox. Используется механизм webhook: при создании актива webhook обращается к микросервису на сервере интеграции, тот запускает автоматизированные процессы и уведомляет ответственного безопасника. Процесс может инициировать и отчет из “1С:ERP” о новом сотруднике - тогда специалист проверяет, какое устройство выдано новичку. Затем проводится категоризация актива по отношению к недопустимым событиям (если ее нельзя сделать автоматически).

Автоматизация сканирования работает так: по событию создания актива в NetBox срабатывает webhook → микросервис запускает сканирование в MaxPatrol VM через API. Сотрудник контролирует только результат. Нет ошибок - человек не нужен. Есть ошибки - вступает принцип управления по отклонениям.

Дополнительно проверку активов инициируют:

• суточный отчет об изменении активов (штатная функция MaxPatrol VM)

• создание учетных записей в определенных OU в Active Directory (контроль аутсорсеров)

• закупка новых каналов связи, IP-адресов, облачных ресурсов

Отдельно ИБ здесь встроилась в процесс заключения договоров с телеком и облачными провайдерами. Интересен не момент, когда ИТ начали пользоваться услугой, а момент, когда только собрались. Информация о новых контрагентах поступает в ИБ, где проверяется, не связан ли договор с покупкой новых IP-адресов, каналов или облачных ресурсов. Так о планируемых изменениях инфраструктуры узнают на самой ранней стадии.

Автоматизированное сканирование

Алгоритм, который описан ниже, применим и для сканирования с нуля, и для ежедневной работы.

В идеальном мире все настроено правильно и происходит само. В реальности люди ошибаются, забывают, делают не так - поэтому нужен самоконтроль. После появления нового актива его нужно просканировать. Целевое состояние - “знаем об активе все”, которое для внутренней инфраструктуры достигается сканированием в режиме Audit. Поэтому для внутренней сети профиль Audit основной, а Host Discovery и Service Discovery вспомогательные. Для внешнего периметра наоборот: основные - Host Discovery и Service Discovery (черный ящик).

Сканирование начинаем с ключевых элементов:

• Сетевые устройства (коммутаторы ядра, маршрутизаторы, межсетевые экраны): на них настроены реально существующие подсети. Нет подсети на устройстве - нет смысла ее сканировать.

• Узлы управления виртуализацией: достоверно показывают, какие виртуальные машины есть.

• Контроллеры домена и системы управления конфигурацией (SCCM, сервер управления антивирусом): содержат достоверные данные для старта.

Перечень этих систем формируется опросом ИТ. Заранее договариваемся, чтобы ИТ настроили оборудование под сканирование в режиме Audit (один раз вручную).

Дальше алгоритм: сканируем известные подсети в Service Discovery и Host Discovery → активы делятся на “с известной ОС” и “с неизвестной”. Вторые попадают в динамическую группу и прогоняются через профиль OS Detection. Если ОС все еще не определена - сканируем “грубой силой”, одновременно профилями Audit для Linux и Windows (нам важно различить эти ОС, потому что для них разные профили и учетки). Если и это не помогло - разбираем вручную. До этого момента все автоматически.

Структурирование групп в MaxPatrol VM

Главная задача - создать такую комбинацию групп, фильтров и задач, чтобы активы автоматически перемещались из группы в группу. Здесь группы делятся на две категории: для сканирования (указываются как цели в задачах) и для контроля состояния (с ними через сохраненные PDQL-запросы работают люди).

Создание структуры - итеративный процесс: создали, поработали, скорректировали. Сразу идеально не выйдет. Принципы:

• Динамические группы Статические при тысячах активов обрекают на провал: не уследишь за достоверностью, растет операционка. Концентрируйтесь на структуре динамических групп, фильтрах и PDQL-запросах, но не в пользую их разбеения по два узла, а только с понятной целью большими группами.

• Статические группы - в особых случаях: для редко меняющихся активов (коммутаторы ядра, маршрутизаторы, системы виртуализации) и контроллеров домена в режиме LDAP (информация реплицируется, нет смысла сканировать все, но в режиме Windows Audit нужно сканировать каждый контроллер).

Контроль состояния

Контроль состояния - это сравнение того, что есть, с тем, что должно быть. “Должно быть” - регламенты, договоренности, данные в CMDB. “Есть” - результаты сканирования.

Проверка подсетей. В первую очередь интересует сетевое оборудование и настроенные подсети. Контроль возможен только после сканирования сетевых устройств с профилем Audit. Ключевая точка сбора - коммутаторы ядра, маршрутизаторы, межсетевые экраны. PDQL-запрос дает список подсетей на оборудовании, который сравнивается со списком в NetBox:

select(NetworkDeviceHost.RoutingTables.Routes.Destination.NetworkID as NetID,
       NetworkDeviceHost.RoutingTables.Routes.Destination.Prefix as NetPrefix)
| filter(NetID in 10.0.0.0/8 and NetID != 10.39.0.0/16 and NetPrefix not in [0,8,32])
| sort(NetID ASC) | unique() | group(COUNT(NetID))

Тут это автоматизировано: специалисты получают отчет только о расхождениях.

Проверка актуальности информации об активах. Актуальность определяется политикой сроков. Например, данные младше 7 дней - актуальны, старше 14 - устарели. Активу присваивается один из статусов: NotDefined (еще не сканировался), UpToDate (свежий), NeedUpdate (7-14 дней), Obsolete (старше 14 дней). Стремимся к тому, чтобы большинство активов были UpToDate.

Важно настроить автоматическое удаление активов из MaxPatrol VM при их удалении из NetBox или системы виртуализации. Иначе выведенный из эксплуатации актив останется в отчетах, давая ложноположительную информацию об уязвимостях на несуществующем узле.

Категоризация активов по недопустимым событиям

В таком варианте в NetBox введена сущность application systems - прикладные системы или группы серверов схожего назначения. Зачем? При анализе недопустимых событий мы оперируем приложениями и сервисами, а при управлении уязвимостями - конкретными серверами и виртуальными машинами. Связи между ними нет, и безопасник никогда достоверно не знает, к какой системе относится узел. Поэтому связь нужно хранить явно. Ее вносит ИТ-специалист при развертывании сервера, потому что только он достоверно знает назначение.

Для каждой прикладной системы один раз вручную выполняется привязка к недопустимому событию. Систем три категории: целевая, ключевая, нейтральная. Дальше скрипты NetBox автоматически устанавливают связь конкретной виртуальной машины с недопустимыми событиями на основе ее принадлежности к прикладной системе.

Признаки актива в MaxPatrol VM бывают техническими (определяются сканированием) и нетехническими (продукт работы людей): SLA на обновления, договоренности о сканировании. Нетехнические признаки переводятся в технические через дополнительные пользовательские поля в карточке актива, которые загружаются через сервер интеграции по API.

Устранение уязвимостей

Устранение делится на плановое и внеплановое. Внеплановое связано с трендовыми и особо опасными уязвимостями, плановое идет по согласованному расписанию. В этой схеме плановые обновления проводятся раз в месяц: для Windows старт привязан к Patch Tuesday, для Linux ставятся все патчи с момента прошлого обновления, в то же окно.

Обновить всю инфраструктуру одновременно невозможно, поэтому ее структурируют по уровням и обновляют поэтапно. Можно воспользоваться методикой ФСТЭК (руководство по управлению уязвимостями 2025 года) или нашим подходом - по сути, об одном и том же разными словами. Задача - перевести критерии (нахождение на периметре, наличие средств удаленного доступа, связь с недопустимыми событиями) в числа и привести к единому показателю приоритета.

Плановую установку обновлений Windows можно контролировать не по конкретной уязвимости, а по номерам обновлений (KB), а для проверки использовать легкий профиль Windows Update (быстрее и менее нагрузочный, чем Windows Audit):

select(@WindowsHost, WindowsHost.Updates.UpdateId as UpdateId, WindowsHost.@AuditTime as AuditTime)
| filter(UpdateId in ['KB5022346', 'KB5022352', ...])

Для внеплановых обновлений и трендовых уязвимостей применяется алгоритм определения приоритета актива: прогоняем каждый актив через критерии, получаем числовые значения и понимаем, что обновлять в первую, вторую и третью очередь.

Харденинг и компенсирующие меры

Компенсирующие меры - альтернатива патчу, когда обновление невозможно или нежелательно (например, патч ломает совместимость с другими системами). Приоритет всегда за патч-менеджментом, но если патч применить нельзя, снижаем риск компенсирующими мерами. Если уязвимость критична и не устраняется ни патчем, ни мерами - остается вывод ПО из эксплуатации.

Компенсирующие меры бывают двух типов:

• Организационные - временное ограничение доступа к системе.

• Технические - средства защиты или отключение уязвимых компонентов.

Пример 1. В механизме двухфакторной аутентификации найдена уязвимость, патча нет. Решение - интегрировать систему с Active Directory по LDAP и использовать второй фактор от контроллера домена, в обход уязвимого ПО.

Пример 2. В DMZ firewall с уязвимой функцией VPN. Варианты: отключить уязвимый компонент, использовать правила фильтрации, применить сегментацию для блокировки доступа уязвимой системы к части сети. Такие меры упоминаются и в документах регуляторов.

Применение компенсирующих мер:

• усложняет атаку (а при наличии SIEM позволяет вовремя ее обнаружить)

• увеличивает стоимость атаки (если расходы превысят прибыль, нападение бессмысленно)

• увеличивает продолжительность атаки (дает время изолировать сегмент или обновить компонент)

Главная цель - предотвратить или максимально усложнить атаку, заставив злоумышленника потратить больше сил, денег и времени.

Патч-менеджмент

Патч-менеджмент - это не процесс ИБ-департамента. Это базовый процесс управления ИТ-активами, который должен жить у ИТ-специалистов. Но безопасник обязан знать его нюансы и риски, потому что патч-менеджмент идет в рамках SLA, согласованного совместно ИТ и ИБ.

Этапы процесса:

1. Идентификация патча - какой патч закрывает конкретную уязвимость.

2. Оценка и приоритизация - по согласованному SLA. Для супер-критичных и трендовых уязвимостей стандартный SLA не применяется: их устраняют здесь и сейчас.

3. Тестирование. Перед патчингом проверяем, не ломает ли исправление работоспособность систем. ПО вполне может отказаться работать с новой версией. Поэтому критичны тестовая среда, максимально имитирующая боевую, и регрессионное тестирование (иначе придется откатываться, а безопасность пострадает).

4. Установка. План с временем и порядком обновления для минимизации простоев (используем технологические окна), начиная с менее критичных систем.

5. Мониторинг и верификация. Проверяем, что система работает корректно и уязвимость действительно закрыта - повторным сканированием.

Установка обновлений делится на три категории с разными приоритетами и SLA: операционные системы (Windows, Linux), софт (браузеры, архиваторы), сетевое оборудование (Cisco, Check Point).

Установка может быть ручной (Далее → Далее → Перезагрузить) или автоматизированной. На рынке есть и VM-решения, позволяющие патчить прямо из системы управления уязвимостями, правда вопрос кто готов этим пользоваться. Тут важнейший момент - разграничение ролей. Представьте, что у безопасника есть кнопка “Пропатчить все”. Как в меме “сейчас я установлю все игры”, так и тут: “сейчас я установлю все патчи” без тестирования и понимания влияния на бизнес-процессы.

Это путь к катастрофе. Патч-менеджмент проводит ИТ-специалист, а не безопасник - роли должны быть четко разделены даже внутри VM-системы.

Методика тестирования обновлений от ФСТЭК

ФСТЭК выпустила методику тестирования обновлений программных и программно-аппаратных средств. Тестирование делится на шесть проверок:

• Т001 - сверка идентичности обновлений;

• Т002 - проверка подлинности обновлений;

• Т003 - антивирусный контроль;

• Т004 - поиск опасных конструкций;

• Т005 - мониторинг активности обновлений в среде тестирования;

• Т006 - ручной анализ.

Важно: на ресурсе ФСТЭК (БДУ) есть раздел с результатами тестирования обновлений ПО (bdu.fstec.ru). Перед установкой можно проверить, тестировалось ли обновление, нет ли в нем закладок, рекомендуется ли оно к установке. После 2022 года, когда обновление само стало вектором риска, это особенно ценно.

Примерный план патч-менеджмента

1. Подготовка и планирование: назначить ответственных (часто разделение на Windows- и Linux-специалистов), провести инвентаризацию устройств и ПО (база!), разработать политику (частота обновлений, SLA, процедура экстренного патчинга).

2. Идентификация и приоритизация: мониторинг источников (подписки на уведомления вендоров, инструменты вроде SCCM/WSUS), классификация по критичности.

3. Тестирование: тестовая среда, имитирующая боевую, регрессионное тестирование.

4. План развертывания: сегментация устройств, расписание с минимизацией простоев, обязательный план отката (план Б на случай сбоя).

5. Развертывание: сначала пилот на небольшой группе, затем постепенное полное развертывание.

6. Мониторинг и контроль: отслеживание состояния после обновлений, документация и отчетность.

7. Обратная связь: анализ успехов и неудач, обучение команды.

Инструменты автоматизации: Microsoft SCCM и WSUS (Windows), Red Hat Satellite (Linux), системы обновления виртуальной инфраструктуры, инструменты для сторонних приложений, системы мониторинга (Zabbix, Grafana).

Когда патч-менеджмент налажен, инфраструктура становится безопаснее и предсказуемее: пропадает “зоопарк” версий (тестировать сразу проще), а статус исправлений в любой момент виден как на ладони.

Виртуальный патч-менеджмент

Виртуальный патч-менеджмент (Virtual Patching) - защита приложений правилами на уровне сети или приложения, без изменения кода. Используется для быстрого закрытия уязвимости до выхода официального патча. Реализуется в межсетевых экранах уровня веб-приложений (WAF).

Преимущества: мгновенная защита (правило применяется немедленно), отсутствие простоя (не нужно останавливать приложение), удобство для legacy-систем (где обновление кода невозможно), защита до выхода официального патча.

Пример: найдена уязвимость в популярной CMS, официальный патч будет через несколько дней. WAF создает правило, блокирующее запросы, связанные с уязвимостью, мониторит попытки эксплуатации и обновляет сигнатуры. И это особенно ценно на фоне тренда последних лет: по данным Mandiant M-Trends 2025, среднее время до эксплойта (time-to-exploit) ушло в отрицательную зону - атакующие все чаще начинают эксплуатировать уязвимость еще до выхода официального патча. При таком раскладе виртуальный патч - едва ли не единственное, что закрывает окно, пока настоящего патча физически не существует.

Legacy-системы и вывод из эксплуатации

Legacy-система - устаревшая, но все еще используемая система, которую вендор больше не поддерживает. Держат ее обычно из-за стоимости замены, критичности для бизнеса или сложности миграции.

Классический пример - Windows XP (вышла в 2001, не поддерживается с 2014). Некоторые организации, особенно с критичными АСУ ТП, продолжают ее использовать из-за приложений или оборудования, работающих только на ней. Главный риск - отсутствие обновлений безопасности. В больнице медицинское оборудование может управляться софтом под Windows XP, и обновление ОС потребует полной замены оборудования - дорого и сложно без остановки медицинских процессов.

От legacy-систем в идеале нужно отказываться, поскольку они держат безопасность всей инфраструктуры под угрозой. Пошаговый процесс работы с ними:

1. Инвентаризация и оценка (база): точный список legacy-систем, оценка критичности и рисков (включая возможные zero-day), определение кандидатов на замену.

2. Стратегия: долгосрочный план поэтапного отказа, приоритетное управление рисками для систем, которые нельзя заменить быстро.

3. Защита и изоляция: сегментация сети (изолировать legacy в отдельных сегментах), ограничение доступа, многофакторная аутентификация, шифрование.

4. Мониторинг: постоянное отслеживание состояния, IDS для подозрительной активности, актуализация совместимых защитных средств.

5. Стратегия на случай инцидентов: план реагирования, регулярное резервное копирование, протестированные планы восстановления.

С legacy-системами так и приходится жить: оценивать риски, изолировать, не спускать глаз и параллельно готовить замену. И помните: каждая legacy-система - это технический долг, который рано или поздно придется отдавать, причем с процентами.

А как у вас?

Какие из восьми принципов у вас уже работают, а какие звучат как “хорошо бы, но руки не дошли”? И покажите свои любимые PDQL-запросы (или аналоги в вашем инструменте) - соберем в комментариях полезную копилку.

Навигация по серии: ⬅️ Предыдущая: Гл. 11. Что случилось с NVD и почему опираться на один источник уязвимостей больше нельзя · ? Оглавление серии · Следующая: Гл. 13. VM в нетипичных средах ➡️

Если у вас в инфраструктуре что-то устроено иначе - расскажите в комментариях. Зашло - подписывайтесь, чтобы не пропустить следующую часть.