Еще несколько лет назад разговор о проверках безопасности сводился к простой схеме: сначала найти "живые" хосты, затем посмотреть на них снаружи и, при необходимости, зайти внутрь с учетной записью. Три подхода - Host Discovery, Pentest и Audit - действительно закрывали большую часть задач. Но инфраструктуры изменились: ноутбук разработчика может неделями не попадать в корпоративный сегмент, облачная виртуалка успевает прожить 40 минут и исчезнуть, а ПЛК на производстве нельзя "прощупывать" активными запросами вообще. Плюс современное приложение часто собрано из сотен чужих библиотек, и уязвимость прячется в зависимости, о существовании которой команда может даже не подозревать.
Поэтому сегодня корректнее говорить не о "трех методах", а о наборе способов получить данные об активе. Сканирование - лишь часть этой картины: рядом стоят агенты, пассивное наблюдение за трафиком, анализ образов и состава ПО, коннекторы к ИТ-системам и интеграции с ИБ-инструментами. И только собрав все это вместе, получается рабочая управление уязвимостями VM система, которая видит инфраструктуру целиком, а не "фрагмент на момент сканирования".
Host Discovery: разведка, а не диагноз
Host Discovery - это этап разведки: выяснить, кто вообще отвечает в сети, какие порты доступны и какая ОС может стоять на узле. Его включают и на старте, когда о периметре почти ничего не известно, и перед более глубокими проверками, чтобы не тратить время на "мертвые" адреса.
Типовые техники обнаружения активов хорошо известны:
- ICMP ping - классический echo request/echo reply: ответ есть - узел жив.
- UDP ping - отправка UDP-пакета: тишина может означать и фильтрацию, и открытый порт; ICMP port unreachable обычно говорит о закрытом порте.
- ARP ping - запрос ARP в локальном сегменте: один из самых надежных способов понять, есть ли устройство рядом.
- TCP ping - попытка установить соединение с портом: если соединение поднялось, порт открыт.
Важно помнить границы метода: Host Discovery видит только то, что отвечает в момент проверки и только в тех подсетях, которые ему задали. Ночной "сон" сервера, сегмент за фильтрующим маршрутизатором или подсеть, о которой никто не вспомнил, - и узел выпадет из поля зрения. Поэтому обнаружение почти всегда усиливают другими каналами: ARP-таблицами коммутаторов, данными гипервизоров и облачных кабинетов, каталогами обновлений, сведениями от контроллеров домена, антивирусов и EDR, событиями SIEM, телеметрией NTA, CMDB и даже ручным добавлением активов. Чем больше независимых точек наблюдения, тем меньше "белых пятен" и тем надежнее последующее сканирование инфраструктуры на уязвимости.
Pentest: "черный ящик" и взгляд глазами атакующего
Pentest-сканирование - это проверка "снаружи", без доверенных учетных данных: какие сервисы доступны, что именно слушает на портах, где есть известные проблемы. Такой подход обычно начинает с проверки доступности узла, затем перебирает открытые TCP/UDP-порты и пытается определить приложения и их версии.
Внутри "черного ящика" чаще всего встречаются два класса проверок:
1) Баннерные - определение сервиса по отклику (баннеру). Это быстро, но ненадежно: баннер могли изменить вручную, забыть обновить после апгрейда или скрыть. В результате появляются ложные совпадения и "фантомные версии".
2) Эксплуатационные - аккуратная имитация атаки, которая подтверждает уязвимость по реакции системы. Это медленнее, зато дает гораздо более точный ответ: проблема действительно воспроизводится на конкретном узле и конкретном порту.
Главная ценность "черного ящика" даже не в точности классификации, а в перспективе: он показывает, как актив выглядит для злоумышленника. Агент внутри хоста и аудит по учетке расскажут о патчах и конфигурациях, но не всегда ответят на вопрос, что реально торчит наружу и что можно зацепить с сетевой стороны. Когда команды сравнивают результаты, нередко выясняется, что "внутри все хорошо", а наружу опубликован лишний сервис или забытый интерфейс администрирования - и именно это превращается в главную точку риска. Отсюда и практический вопрос, который часто звучит в закупках: "пентест сканирование сети цена" - но корректнее считать не стоимость запуска сканера, а цену найденных (или пропущенных) внешних дыр.
Audit: "белый ящик" и проверка изнутри
Audit-сканирование работает иначе: система получает доступ к узлу с учетной записью и проверяет конфигурации, установленные обновления, параметры политик, права, локальные настройки сервисов. Это тот самый "белый ящик", который особенно полезен там, где баннеры врут, а сервисы спрятаны за прокси или балансировщиком.
Однако аудит требует подготовки: учетные данные, корректные права, открытые административные порты/протоколы, а иногда - выделенные сервисные аккаунты и правила в межсетевых экранах. Без этого "белый ящик" либо не стартует, либо дает обрезанную картину.
Агент: максимум телеметрии, но не "вся правда"
Хостовое, то есть агентное сканирование уязвимостей, дает очень детальные данные: фактические версии пакетов, результаты инвентаризации, состояние патчей, локальные политики и признаки небезопасных настроек. Это особенно ценно для рабочих станций, серверов в закрытых сегментах и устройств, которые редко бывают доступны для сетевых проверок.
Но агент принципиально не умеет отвечать на один ключевой вопрос: "как меня видят снаружи". Он может сообщить, что установлен уязвимый сервис, но не докажет, что сервис действительно доступен из нужной зоны. Поэтому выбирать "агент или удаленный аудит" обычно не приходится - в зрелых процессах это дополняющие инструменты.
Новые реалии: облака, контейнеры, состав ПО и пассивные методы
В облаках часто удобнее не "стучаться" к каждой ВМ, а использовать безагентное получение данных: API провайдера, сведения об образах, security groups, метаданные инстансов, конфигурации управляемых сервисов. Такой подход быстрее и лучше подходит для ресурсов, которые появляются и исчезают за часы.
Отдельная история - контейнеры и образы. Проверка "живого" контейнера полезна, но не закрывает риск уязвимостей, которые попадают в прод еще на этапе сборки. Здесь на первый план выходят SCA и SBOM: анализ состава ПО, библиотек и зависимостей, чтобы находить проблемы в третьесторонних компонентах до деплоя.
Для веб-приложений нужен DAST: динамическое тестирование, которое пытается обнаружить типовые дефекты на уровне логики и веб-слоя. В отличие от сетевого сканирования, здесь важны маршруты, формы, авторизация и поведение приложения при "неправильных" запросах.
Наконец, есть активы, которые лучше не трогать активными запросами: промышленное оборудование, критичные сегменты, нестабильные системы. В таких случаях помогает пассивное выявление - "слушать, а не стучать": анализ сетевого трафика, который уже ходит по сегменту, и построение карты устройств и сервисов без агрессивных проверок.
Коннекторы, ручной ввод и интеграции: данные без сканирования
Чтобы уменьшить слепые зоны, часто подключают коннекторы к ИТ-системам: CMDB, каталоги обновлений, системы учета активов, MDM, EDR и другие инструменты, где уже лежит полезная инвентаризация. Это особенно важно для удаленных сотрудников и гибридных сред: даже если узел не в сети, его можно "увидеть" по другим сигналам.
Ручное заведение активов - крайний, но иногда необходимый путь: для редких устройств, изолированных сегментов и ситуаций, когда автоматизация упирается в ограничения бизнеса.
Как выбрать метод и как часто проверять
Подбор подхода зависит от типа актива и допустимого риска: серверы на периметре логично регулярно проверять "черным ящиком", критичные узлы - аудитом и агентом, облака - API/конфигурационными проверками, контейнеры - анализом образов и зависимостей, веб - DAST. Частоту задают не "как удобно сканеру", а динамика изменений: где релизы каждый день, там и контроль должен быть ближе к CI/CD.
И еще один практический нюанс: иногда сканирование ломает то, что сканирует. Это случается из‑за слабых реализаций сетевых стеков, старых сервисов, кривых IDS/IPS-настроек или излишне агрессивных профилей. Поэтому режимы, окна и нагрузку лучше согласовывать заранее, а для хрупких сегментов предусматривать пассивные методы и выборочные проверки.
После сканирования: склейка и работа с результатом
Самая частая ошибка - считать, что ценность появляется в момент запуска сканера. На деле она начинается после: нужно склеить данные из разных каналов (агент, аудит, "черный ящик", облачные API, SCA/SBOM, DAST, коннекторы) в единую карточку актива, убрать дубли, сопоставить уязвимости с реальными сервисами и приоритизировать по риску и экспозиции.
На этом этапе многие также упираются в выбор платформы и бюджета - от пилотов до промышленной эксплуатации. И вопрос "сканер уязвимостей купить" обычно правильнее переформулировать так: какой набор методов поддерживает продукт, насколько хорошо он сводит результаты в единый контур и может ли развиваться вместе с инфраструктурой. В этом контексте полезно ориентироваться на практические разборы вроде сканирование инфраструктуры на уязвимости, где акцент сделан не на "магии одной кнопки", а на комбинировании подходов.
В итоге "просканировать все" - это не про один режим и не про один инструмент. Это про сбор пазла из активного и пассивного наблюдения, сетевых и хостовых проверок, анализа конфигураций и зависимостей, а затем - про дисциплину обработки результатов: от склейки и валидации до исправлений и контроля повторного появления проблем.