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

Когда я впервые описывал эту тему, все было просто: есть три метода сканирования, выбирайте под задачу. Host Discovery, чтобы найти живые узлы. Pentest, чтобы посмотреть на них снаружи. Audit, чтобы зайти внутрь с учетной записью. Три метода закрывали почти всю инфраструктуру.

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

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

В этой главе разберем:

• три классических метода: Host Discovery, Pentest, Audit;

• хостовое (агентное) сканирование - что оно дает и чего принципиально не умеет;

• безагентное сканирование облаков, пассивное выявление по трафику, контейнеры, SCA и SBOM, DAST;

• коннекторы к ИТ-системам и ручной ввод;

• интеграции с ИБ-системами;

• как выбрать метод под тип актива и как часто сканировать;

• работу с результатами: склейку данных и шесть шагов после сканирования.

Host Discovery: кто вообще жив

Host Discovery - это разведка: поиск живых узлов в сети. Применяется и на старте, когда мы еще ничего не знаем о сети, и перед аудитным сканированием, чтобы ускорить процесс и не долбиться в мертвые адреса. Для выявления активных узлов используют несколько методик:

• ICMP ping - классический пинг: отправляем echo request, по echo reply понимаем, что узел жив.

• UDP ping - отправка пустого UDP-пакета. Нет ответа - порт открыт или трафик фильтруется; ответ ICMP port unreachable - порт закрыт.

• ARP ping - ARP-запрос по локальной сети. Ответил узел - значит, активен. Самый надежный метод в пределах одного сегмента.

• TCP ping - попытка установить соединение с портом. Соединение есть - порт открыт.

Host Discovery собирает базовую информацию: жив ли узел, какие порты доступны, какая ОС. Точности режимов Audit и Pentest он не дает и дать не может. У него другая задача - очертить границы: вот столько адресов отвечает, вот с ними и работаем дальше.

Важная оговорка, о которую спотыкаются многие. Host Discovery находит только то, что отвечает в момент сканирования и находится в тех подсетях, которые вы ему скормили. Выключенный на ночь сервер, узел за фильтрующим маршрутизатором, сегмент, о котором вы не знали, - все это останется невидимым. Поэтому Host Discovery комбинируют с другими источниками: ARP-таблицами коммутаторов, данными гипервизоров, каталогами обновлений, антивирусами, SIEM, системами NTA, CMDB, EDR, контроллерами домена и ручным вводом. Чем больше источников, тем меньше белых пятен.

Pentest: сканирование методом черного ящика

Pentest - сканирование методом черного ящика. Позволяет определить сетевые сервисы и приложения на портах и обнаружить их уязвимости. Проверяется доступность узла, сканируются открытые TCP- и UDP-порты. Включает два типа проверок:

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

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

Ценность черного ящика не в точности. Он показывает то, чего не покажет ни агент, ни аудит: как узел выглядит со стороны злоумышленника. Какие порты реально торчат наружу, какой сервис отвечает на 8080, о котором никто из администраторов не помнит, и работает ли на самом деле то правило межсетевого экрана, которое написано в регламенте + подтверждает реальную эксплуатацию уязвимости без привилегированного доступа.

Audit: сканирование методом белого ящика

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

Примеры подключений: к Windows - через WMI или RPC, к Unix/Linux и сетевым устройствам - через SSH, к базам данных - через специфические протоколы (ODBC и т. п.).

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

Подготовка к аудиту

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

Узлы в DMZ требуют оперативного устранения уязвимостей, поэтому сканируйте их чаще. Перед запуском новой системы в эксплуатацию проведите ее полное сканирование, чтобы найти и закрыть уязвимости до того, как она окажется доступна злоумышленнику.

Хостовое сканирование: агент на узле

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

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

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

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

1. Это не критический узел и он не приведет к серьезным последствиям

2. Узел часто не меняется и расчет уязвимостей может происходит но основе предыдущего слепка

Что дает агент

Покрывает то, до чего сканер не дотягивается. Ноутбуки в разъездах, домашние рабочие места, изолированные сегменты. Агент выходит на связь сам.

Убирает привилегированную учетку из сети. Одна доменная учетная запись с админскими правами на половину парка - лакомая цель, к которой мы еще вернемся. У агента этой проблемы нет: он не аутентифицируется по сети на каждом узле.

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

Дает более свежие данные. Удаленный аудит - это срез на момент задачи. Агент может отчитываться сильно чаще, вплоть до передачи изменений по факту установки обновления.

Чего агент не умеет

А теперь холодный душ, потому что агента часто продают как замену всему остальному. Это не так, и вендоры это честно пишут в документации.

Агент видит систему изнутри и только изнутри. Он не сканирует сеть, не проверяет удаленные подключения к СУБД, не подбирает пароли к сервисам и не показывает, какие порты узла реально открыты для соседа по сегменту, в конце концов агент не поставишь на сетевое оборудование и софт с закрытой ОС. Tenable прямо указывает эти ограничения в документации к своим агентам и рекомендует сочетать агентное сканирование с сетевым. Qualys в базе знаний формулирует так же: агент не обнаруживает все уязвимости, дополняйте его сетевым сканированием.

Дальше - то, о чем в документации пишут реже.

Агент не найдет неизвестный актив. Он стоит там, куда его поставили. Забытый тестовый сервер, принесенный подрядчиком коммутатор, поднятая мимо процессов виртуалка - все это находит Host Discovery и сетевое сканирование, а не агент. Инфраструктура, где инвентаризация построена только на агентах, знает ровно то, что ей рассказали.

Агента некуда ставить на половине парка. Сетевое оборудование, принтеры, IP-камеры, СХД, гипервизоры, промышленные контроллеры, любые закрытые устройства - на них нельзя установить стороннее ПО. А это часто самая интересная для злоумышленника часть инфраструктуры.

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

Агенты надо обслуживать. Через год после внедрения обязательно находится группа узлов, где агент не обновлялся, не поднялся после обновления ОС или уехал вместе с перезалитым образом. Причем узел с мертвым агентом выглядит в отчетах как узел без уязвимостей. Это худший вид слепого пятна: не “мы не знаем”, а “мы уверены, что там все хорошо”.

Отсюда простое правило: покрытие агентами - это метрика, которую надо считать и сверять с данными ИТ, а не галочка “внедрили”.

Агент или удаленный аудит

Вывод, который всем нужно зафиксировать у себя в голове: это не выбор “или - или”. Агенты закрывают мобильные и изолированные узлы, удаленный аудит - все, куда агента не поставить, сетевое сканирование - взгляд снаружи и поиск того, о чем вы не знали. Инфраструктура среднего размера обычно живет на всех трех методах сразу, и это нормально.

Агент от смежной системы

Отдельный сюжет - использовать в качестве агента то, что уже стоит на узлах. Чаще всего речь про EDR: его агент и так собирает инвентаризационные данные, так пусть отдает их в VM-систему.

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

Безагентное сканирование облаков

В облаке появился третий вариант, которого нет в своей серверной. Ни агента, ни подключения к машине: платформа сама умеет делать снимок диска, а сканер читает этот снимок в стороне от рабочей нагрузки.

Схема простая. VM-система получает права на API облака, делает read-only копию тома, монтирует ее в своей изолированной среде и разбирает содержимое: ОС, пакеты, версии, конфигурации, иногда забытые ключи и пароли. Сама виртуалка при этом не знает, что ее проверили: ни процесса на ней, ни нагрузки, ни учетной записи.

Метод придумали не от хорошей жизни. В облаке ресурсы создаются автоматикой, живут недолго и часто вообще не проходят через процессы ИТ - ставить на каждый агент нереально. Первыми это сделали Orca Security (технология SideScanning) и Wiz, дальше подтянулись облачные платформы: у Amazon безагентное сканирование EC2 через снимки томов работает в общем доступе с апреля 2024 года, причем в гибридном режиме - есть на машине штатный агент платформы, используется он, нет - берется снимок. У Microsoft в Defender for Cloud устроено похоже: временный зашифрованный снимок анализируется отдельно от нагрузки.

Ограничения тоже понятные. Снимок - это состояние диска, а не работающей системы: что происходит в памяти, какие соединения установлены, что творится в контейнере прямо сейчас, по нему не увидеть. И метод намертво привязан к API конкретной платформы: своя серверная так не сканируется.

В российских облаках готового аналога такого масштаба пока нет: провайдеры предлагают контроль конфигураций облака (CSPM), а это про настройки, а не про уязвимости внутри дисков.

Пассивное выявление: слушать, а не стучать

Есть инфраструктура, где активное сканирование запрещено не регламентом, а здравым смыслом. Технологический сегмент, контроллеры, старые железки с сетевым стеком, написанным в прошлом веке. Тут работает другой подход: не опрашивать устройства, а слушать трафик.

Схема: на зеркало порта коммутатора (SPAN или TAP) ставится сенсор системы анализа трафика, он разбирает протоколы, в том числе промышленные, и по ним понимает, какие устройства есть в сети, какие у них адреса, версии прошивок, кто с кем разговаривает.

Плюс метода - нулевое воздействие на сеть. Ни одного лишнего пакета в сторону ПЛК.

Минус - он видит только то, что говорят. Устройство, которое молчит в момент наблюдения, для пассивного сенсора не существует. Версию ПО он определит по косвенным признакам, а не по списку установленных пакетов. Поэтому пассивное выявление - это способ узнать состав сегмента и заметить попытку эксплуатации, а не полноценная замена аудиту.

Контейнеры и образы

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

Поэтому проверяют не контейнер, а то, из чего он собран, и делают это раньше:

• образ в реестре - до того, как он поедет в прод

• сборку в конвейере - и тогда сборка с критичной уязвимостью просто не проходит дальше

• допуск в кластер (admission control) - образ из непроверенного реестра или с известной проблемой не запускается

• рантайм - что реально крутится в кластере прямо сейчас

Инструменты: из открытых - Trivy и Grype, из российских - PT Container Security (в версии 0.7, вышедшей в июне 2025 года, добавили управление несколькими кластерами Kubernetes из одной точки), Kaspersky Container Security, Luntry.

Состав ПО: SCA и SBOM

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

Отсюда два термина, которые пришли в VM из безопасной разработки.

SCA (software composition analysis) - анализ состава ПО: разбор проекта на компоненты и сопоставление каждого с базами уязвимостей.

SBOM (software bill of materials) - ведомость состава ПО, тот самый перечень компонентов с версиями и контрольными суммами. Два основных формата: CycloneDX (сообщество OWASP, изначально заточен под безопасность) и SPDX (Linux Foundation, международный стандарт ISO/IEC 5962).

Зачем это службе ИБ, которая ничего не разрабатывает? Затем, что при следующем Log4Shell вопрос “у нас это где-нибудь есть?” решается за минуты по ведомостям, а не за недели опроса подрядчиков. Разумная практика (хоть на практике пока не особо получается) - требовать SBOM у поставщиков ПО и хранить ведомости рядом с моделью активов.

Регулятор двинулся в ту же сторону. В мае 2026 года ФСТЭК утвердила новую методику выявления уязвимостей и недекларированных возможностей в программном обеспечении - она заменила закрытую методику 2020 года и впервые опубликована открыто. Там прямо требуется перечень заимствованных программных компонентов в машиночитаемом формате CycloneDX, с хеш-суммами (включая отечественный Стрибог), и вводится шкала из шести уровней доверия к ПО, где первый означает максимальное доверие, а шестой - недоверенное. Документ синхронизирован с ГОСТ Р 56939-2024 по безопасной разработке.

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

Веб-приложения: DAST

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

Этим занимается DAST - динамический анализ работающего приложения. Сканер ходит по страницам как пользователь, подставляет данные в формы и параметры, смотрит на реакцию. Главное отличие от сетевого пентест-режима: DAST умеет аутентифицироваться и работать за формой входа, сохраняя сессию. Все интересное в приложении обычно там, а не на публичных страницах.

С процессом VM это стыкуется двумя способами: результаты DAST сводятся в общую модель уязвимостей вместе с инфраструктурными, а веб-активы попадают в ту же инвентаризацию. Часть российских платформ (например, PT EASM, ScanFactory, Metascan и др) объединяет в одном продукте внешнюю разведку, инфраструктурное сканирование и DAST.

Коннекторы: данные без сканирования

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

Что обычно подключают:

• службы каталогов (Active Directory и аналоги) - список узлов и учетных записей

• системы управления обновлениями - что установлено и что не встало

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

• облачные API и API кластеров Kubernetes - ресурсы, которых нет ни в одной подсети

• CMDB и системы учета - владельцы, назначение, бизнес-критичность

• средства защиты: EDR, антивирусы, SIEM, NTA - и как источник инвентаризации, и как источник событий об изменениях

Одна оговорка: данные из коннектора - это чужие данные. Гипервизор честно расскажет про виртуалку, но не про то, какие пакеты внутри нее. CMDB расскажет то, что в нее внесли полгода назад. Коннекторы отлично отвечают на вопрос “что у нас есть” и плохо - на вопрос “что там уязвимого”. Комбинируйте: коннектор находит актив, сканер или агент дает по нему техническую глубину.

Ручное заведение активов

Ручная инвентаризация - занесение информации об активах руками - подходит малым организациям с небольшим числом активов. В остальных случаях рекомендуем автоматизированные системы.

Ручной метод чреват ошибками: неверные данные, пропущенные активы, дубли. Плюс это долго и дорого. И заводить руками придется не разово: каждое изменение в инфраструктуре тоже кто-то должен занести. Значит, данные устаревают, новые активы появляются незамеченными, а число уязвимостей растет.

То же касается и самих уязвимостей: если не получать информацию о них автоматически, на сбор и поддержку уйдут люди, время и силы. Без должной автоматизации добиться вменяемых SLA практически невозможно. А с учетом сроков из приказа ФСТЭК № 117 (24 часа на критические уязвимости) ручной подход - заведомый проигрыш.

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

Интеграции с ИБ-системами

Один из самых частых вопросов которые я слышу: “А с каким ПО у вас есть интеграции? Интегрируетесь ли с ИБ- и ИТ-системами?” А встречный вопрос всегда один: а какова цель интеграции?

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

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

SIEM. Прежде чем интегрироваться, спросите: зачем? Релевантный кейс - обогащение табличных списков SIEM информацией о наличии уязвимостей на активах, чтобы писать корреляционные правила. Кейс хороший, но сработает ли он в вашей инфраструктуре? Станут ли процессы лучше, начнете ли быстрее ловить хакера? Если нет - возможно, интеграция не нужна. И обратный, очень полезный кейс: SIEM из события сообщает, что установлено обновление безопасности, VM-система сопоставляет это со своей базой и понимает - уязвимости больше нет. Вот это стоит иметь на вооружении.

EDR. Про EDR как транспорт для хостового сбора мы говорили выше. Обратный вопрос - можно ли делать response силами EDR на основе наличия уязвимости? Чаще всего реагировать придется уже на попытку эксплуатации, а в идеале мы вообще не хотим, чтобы злоумышленник дошел до внутренней инфраструктуры через уязвимость.

Полезны интеграции с SOAR (автоматизация реагирования) - тут профит очевиден. Главный принцип: прежде чем строить интеграцию, поймите ее цель. Можно ли закрыть кейс иначе? Обычно интеграции делают, когда нужно подтянуть данные из одной системы в другую, потому что функционала одной не хватает (тикеты, аналитика в BI-системах). Если же это интеграция ради интеграции - лучше потратить силы на что-то полезное.

Какой метод под какой актив

Свести все вместе можно так.

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

Как часто сканировать

Частота - это всегда компромисс между свежестью данных и нагрузкой на инфраструктуру и людей. Ориентиры такие.

Регуляторный минимум. Приказ ФСТЭК № 117 для государственных информационных систем требует выявлять уязвимости не реже раза в месяц и устранять критические за 24 часа, высокие - за 7 дней. Международная практика примерно того же порядка: CIS Controls v8.1 в разделе про непрерывное управление уязвимостями предлагает сканировать внутренние активы не реже раза в квартал, а доступные извне - не реже раза в месяц.

Разумная практика. Минимум - он на то и минимум. Внешний периметр стоит проверять непрерывно или ежедневно: это то место, куда злоумышленник смотрит каждый день. Внутреннюю сеть - раз в неделю или чаще для значимых систем. Полное сканирование всех портов - реже, раз в месяц, потому что оно долгое и шумное.

Сканирование по событию. Самое полезное. Вышла трендовая уязвимость - вы не ждете планового окна, а запускаете проверку по всему парку сегодня. Появилась новая система - сканируете до ввода в эксплуатацию. Изменилась конфигурация периметра - перепроверяете периметр.

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

Когда сканирование ломает то, что сканирует

Pentest в режиме черного ящика несет риски: сканер не знает, что именно сканирует, и может случайно повредить систему. Опыт показывает, что деструктивный эффект могут давать сканирование сетевых принтеров (они любят печатать “кракозябру” километрами), brute-force-атаки и проверки специфического ПО и АСУ ТП. Поэтому набор проверок нужно подбирать осознанно, а критичные системы лучше проверять аудитом.

Это не байки ибэшников. Промышленные контроллеры действительно уходят в отказ от обычного сетевого сканирования: в исследованиях по инвентаризации АСУ ТП описан случай, когда сканирование Nmap с определенными флагами привело ПЛК в нерабочее состояние - помогло только полное обесточивание. CISA отдельно предупреждала о технике “пакета смерти”, останавливающей контроллеры до перезапуска и восстановления конфигурации. Где-то я слышал теорию, что “А разве так должно быть? Не является ли это уже уязвимостью? DoS например. Я же просто положил систему одним пакетом”, но это риторический вопрос, наверное.

Отсюда правила для чувствительных сегментов:

• в промышленных сетях по умолчанию пассивное выявление, активное - только по согласованию и в окно обслуживания

• проверки подбираются осознанно: brute-force и эксплуатационные проверки в АСУ ТП выключаем

• любое активное сканирование нового сегмента начинается с тестовой группы, а не со всего парка сразу

• профильные требования (IEC 62443, NIST SP 800-82 для АСУ ТП) читаются до, а не после инцидента

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

Не используйте одну учетную запись для всех узлов: если ее скомпрометируют, злоумышленник получит доступ ко всем машинам разом. Используйте разные учетки для разных подсистем и категорий узлов. Для доменных узлов Windows полезна технология LAPS (Local Administrator Password Solution) - управление локальными административными паролями. Сама по себе учетная запись сканирования с админскими правами на половину парка - это лакомый кусок, относитесь к ней соответственно. То же самое касается сервера управления агентами: кто им владеет, тот управляет всеми узлами, где стоят агенты или центральное ядро способное создавать задачи на сканирование.

Работа с результатами сканирования

Представим, что мы только что собрали данные всеми описанными способами. Что дальше?

Сначала склейка

Пока метод был один, вопроса не стояло. Как только их стало пять, появилась новая задача: свести данные из разных источников в одну картину. Иначе один сервер приезжает в систему трижды - как узел с IP от сетевого сканирования, как хост с именем от агента и как виртуальная машина от гипервизора. И все три “актива” честно тащат за собой свой список уязвимостей.

Что с этим делать.

Договоритесь об идентификаторе актива. Не IP - он меняется. Обычно связка из нескольких признаков: FQDN, MAC-адреса, серийный номер, идентификатор виртуальной машины или облачного ресурса, идентификатор агента. Хорошая VM-система склеивает такие записи сама; ваша задача - проверить, что она это делает правильно, и разобрать исключения.

Задайте приоритет источников. Данные конфликтуют постоянно: агент говорит одну версию пакета, аудит - другую, потому что сканировали в разное время. Решите заранее, кто главный по каждому типу данных. Обычно: состав ПО - от агента или аудита, открытые порты - от сетевого сканирования, владелец и назначение - от CMDB.

Следите за покрытием, а не за числом уязвимостей. Главный вопрос после сканирования - не “сколько нашли”, а “что осталось непросканированным”. Активы, по которым нет свежих данных ни от одного метода, - это и есть ваш реальный риск. В отчете их не видно: нет данных, нет уязвимостей, все прекрасно.

Только после склейки имеет смысл идти дальше. Шагов пять, а на самом деле шесть, и шестой стоит сделать первым.

Шаг 1. Оцените риск и критичность каждой уязвимости.

• Критические уязвимости с высоким воздействием - немедленное устранение.

• Уязвимости средней степени - своевременное устранение в зависимости от влияния на бизнес.

• Низкий уровень риска - плановое устранение по мере ресурсов.

При оценке критичности используйте не голый CVSS, а контекст: значимость актива, доступность эксплойта, доступность узла для нарушителя. Подробно методики приоритизации (CVSS 4.0, EPSS, KEV, методика ФСТЭК, трендовость) разбираем в следующей главе.

Шаг 2. Определите приоритет устранения на основе риска и критичности. Высокий риск и критические уязвимости - как можно скорее. Средний - планово. Низкий - своевременно, но без спешки. В идеале для стандартного набора критичности уязвимостей должен быть просто выстроен грамотный patch management и тогда будете подпрыгивать как только появляются критичные уязвимости.

Шаг 3. Немедленно действуйте по высокорисковым и трендовым уязвимостям. Ставьте патчи, как только они доступны. При необходимости применяйте временные (компенсирующие) меры, пока внедряется постоянное решение. Уведомляйте затронутые команды и работайте с ними сообща.

Шаг 4. Продолжайте мониторинг и повторные проверки. Регулярно актуализируйте информацию об уязвимостях, анализируйте тренды, повторно сканируйте, держите системы обновленными.

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

Шаг 6 (который стоит сделать первым). Разработайте политики и процедуры управления уязвимостями совместно с ИТ (при необходимости - с участием CISO, CIO, CEO): формальный процесс приоритизации и устранения, графики регулярных обновлений, периодические оценки безопасности.

Почему последний шаг может быть первым? Все зависит от того, есть ли в вашей организации хоть какие-то процессы, или вы пришли в стартап и строите ИБ с чистого листа. Если строите с нуля - начинайте именно с политик и процедур, а уже потом сканируйте. Если процессы есть - встраивайте результаты сканирования в них.

А как у вас?

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

? Источники и ссылки

Источники главы

1. Приказ ФСТЭК России от 11.04.2025 № 117 (вступил в силу 01.03.2026): периодичность выявления уязвимостей и сроки устранения.

2. CIS Controls v8.1, Control 7 “Continuous Vulnerability Management”: рекомендованная периодичность сканирования.

3. Tenable, документация по агентам: ограничения агентного сканирования (docs.tenable.com).

4. Qualys, база знаний: рекомендация дополнять Cloud Agent сетевым сканированием.

5. Amazon Web Services: безагентное сканирование EC2 в Amazon Inspector, общедоступный режим с апреля 2024 года.

6. Microsoft Learn: agentless machine scanning в Defender for Cloud.

7. Orca Security, технология SideScanning.

8. CISA, advisory AA22-103A: воздействие на промышленные контроллеры.

9. “A Taxonomy for Contrasting Industrial Control Systems Asset Discovery Tools”, arXiv (2022): отказ ПЛК при активном сканировании.

10. Positive Technologies: архитектура MaxPatrol VM (роли Collector и Agent), MaxPatrol EDR как источник данных о конечных устройствах, PT Container Security 0.7 (июнь 2025), PT NAD и PT ISIM как средства пассивного выявления.

11. OWASP CycloneDX; SPDX (ISO/IEC 5962) - форматы SBOM.

12. Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении, ФСТЭК России, утверждена 12.05.2026 (доведена информационным сообщением от 28.05.2026): требования к SBOM в формате CycloneDX, шесть уровней доверия, связь с ГОСТ Р 56939-2024.

---

Навигация по серии: ⬅️ Предыдущая: Гл. 7. Отчет на 2,2 миллиона строк · ? Оглавление серии · Следующая: Гл. 9. Нельзя защитить то, о чем не знаешь ➡️

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