Сканирование уязвимостей конечных точек: агент или сеть?

Какая проблема решается и почему сканеры часто мешают работе

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

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

Тормоза обычно возникают по трем причинам:

• Сканер создает много одновременных запросов по сети (особенно при проверке подсетей).
• На устройствах растет нагрузка на CPU и диск (инвентаризация, чтение реестра, сравнение версий, анализ компонентов).
• Сканирование попадает в то же окно, что обновления, антивирус, бэкап или рабочие часы.

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

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

Агентный подход: где он сильнее всего

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

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

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

Обычно помогают простые правила:

• запускать тяжелые проверки в нерабочие часы или когда устройство подключено к питанию;
• ограничивать потребление CPU и приоритет диска для агентных задач;
• разделять частую легкую проверку (инвентаризация) и редкую глубокую (поиск уязвимостей).

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

Сетевой подход: когда он подходит, а когда нет

Сетевое сканирование работает снаружи. Оно проходит по диапазонам IP, находит живые хосты и проверяет, какие порты и сервисы доступны. По ответам устройств сканер часто определяет тип сервиса, версию и базовые настройки (например, поддерживаемые шифры у TLS). По сути он видит то, что видно любому соседу по сети.

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

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

Когда сетевой скан подходит

Сетевой скан уместен, если нужно быстро проверить поверхность атаки и держать под контролем серверные роли:

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

Когда он дает мало пользы и может мешать

Для ноутбуков, удаленных пользователей и хостов, которые часто вне сети, покрытие будет неполным. А активное сканирование иногда создает шум: растет нагрузка на ЛВС, срабатывают IDS/IPS, межсетевые экраны режут запросы, а некоторые средства защиты могут временно блокировать сканер как подозрительную активность.

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

Комбинированная схема: покрытие без лишнего шума

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

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

Практичное распределение обязанностей выглядит так:

• Агент: установленное ПО, версии библиотек, локальные настройки, отсутствующие патчи, уязвимости без сетевого следа.
• Сеть: доступные порты и протоколы, слабые настройки сервисов, лишняя экспозиция наружу, ошибки сегментации.
• Удаленные сегменты: агент в приоритете, сетевой скан точечно и ближе к месту (локальный сканер или редкие окна).

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

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

Пример: в офисе агенты собирают данные о патчах раз в неделю ночью, а сетевой скан запускается только по подсетям серверов в ЦОДе и по ключевым офисным VLAN, но в короткие окна. Покрытие остается широким, а «шума» становится заметно меньше.

Расписания сканирований: частота и окна без конфликтов

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

Частоту задавайте по риску и по тому, как быстро меняется устройство. Практичный ориентир:

• Критичные серверы и периметр (VPN, почта, веб, DMZ): еженедельно и после заметных изменений.
• Остальные серверы: раз в 2-4 недели.
• Обычные ПК и ноутбуки: раз в месяц, плюс быстрый перескан после крупных обновлений.
• Редкие устройства (киоски, терминалы, учебные классы, редко включаемые ПК): по событию (включили, переехали, сменили образ) и раз в квартал.
• Новые активы: сразу после ввода в домен или выдачи пользователю.

Окна сканирования выбирайте не «как удобно ИБ», а там, где меньше конкуренции за ресурсы. Для офисных ПК часто подходит ночь или обед, для серверов - выходные окна или отдельные ночные слоты по сервисам. Если часть сотрудников работает удаленно, добавьте «плавающее окно» (например, в течение 3-5 дней), чтобы ноутбуки успели попасть в проверку, когда они онлайн.

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

Учитывайте «патч-вторники» и любые массовые изменения: обновления ОС, антивируса, образов, гипервизора. Логика простая: сначала ставим патчи, затем даем 24-72 часа на стабилизацию, и только потом запускаем полный скан, чтобы не ловить шум на переходном состоянии.

Чтобы сканы не совпадали с бэкапами и окнами обслуживания, ведите общий календарь (ИБ, инфраструктура, сервис-деск). В нем фиксируйте:

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

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

Как снизить нагрузку на ЛВС и на сами устройства

Главный источник «тормозов» - не сам факт проверки, а то, как она организована: сколько задач запускается одновременно, как быстро идет опрос и какие сегменты сети затрагиваются.

Первое, что дает быстрый эффект, - ограничить параллельность и скорость опроса. Если сканер умеет, задайте лимит на одновременные хосты и на число одновременных проверок на одном хосте, а также поставьте паузы между запросами. Лучше сканировать дольше, но без всплесков, чем «взорвать» сеть за 20 минут.

Упростите цель сканирования: делите инфраструктуру на группы. Обычно удобно разделять по подсетям (офисы, Wi-Fi, серверная), по типу устройств (ПК, VDI, серверы, кассы) и по критичности. Так проще запускать проверки волнами и не задевать всех сразу.

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

Чаще всего помогает набор базовых настроек:

• снизить параллельность и включить лимиты по хостам и запросам в секунду;
• разнести задания по подсетям и по ролям устройств, запускать волнами;
• для «постоянных» активов использовать агентные сканы, а сетью проверять наличие и базовую доступность;
• исключить большие диапазоны, которые не относятся к вашей зоне ответственности (гостевые сети, чужие VLAN, лаборатории);
• планировать окна по нагрузке: серверы отдельно от пользовательских ПК.

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

• пиковая загрузка канала на межсетевых линках и между офисами;
• число одновременных соединений и рост ошибок таймаута;
• CPU, RAM и диск на конечных устройствах во время скана;
• жалобы пользователей и рост времени отклика типовых сервисов (почта, файлы, ERP).

Исключения: как настроить и не сделать хуже

Исключения нужны, чтобы сканирование уязвимостей конечных точек не ломало работу и не создавало лишний шум. Но каждое исключение - это осознанная «дыра» в видимости, поэтому относитесь к нему как к временному риску, а не как к удобной кнопке «не мешай».

Чаще всего исключают не устройство целиком, а конкретный объект, который действительно мешает. Например, процесс резервного копирования дает таймауты при сетевом сканировании, и проще временно исключить конкретный порт или сервис на время окна бэкапов.

Типовые виды исключений:

• хосты или подсети (редко, только для особых зон);
• порты или сервисы (точечно и с причиной);
• директории и файлы (актуально для агентного сканирования);
• процессы и приложения (чтобы не задевать критичные операции);
• конкретные проверки и уязвимости (по идентификатору, если есть подтверждение).

Главный критерий - «почему исключаем и на какой срок». Почти всегда у исключения должен быть срок действия (например, 30-90 дней) и владелец, который отвечает за устранение причины. Если срок не задан, исключение превращается в постоянную слепую зону.

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

• что именно исключаем (объект и точные параметры);
• причину и влияние на бизнес (что ломается без исключения);
• компенсирующие меры (например, ручная проверка раз в месяц);
• срок действия и условия снятия (патч, обновление, перенос сервиса);
• кто утверждает (ИБ) и кто владелец системы (ИТ или бизнес).

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

Ложные срабатывания: проверка, подтверждение, учет

Ложные срабатывания неизбежны и в агентном, и в сетевом режиме. Если реагировать на каждое как на инцидент, команда быстро выгорит, а бизнес начнет игнорировать отчеты. Задача - быстро отделять реальную уязвимость от ошибки сканирования и аккуратно фиксировать результат.

Быстрый триаж

Сначала проверьте, что сканер действительно увидел правильную версию ПО и правильный хост. Часто проблема не в уязвимости, а в недоступности порта, временном таймауте, прокси, NAT или в том, что агент отстал и не обновил инвентарь.

Практичный порядок действий:

• повторите проверку тем же методом в другое время и сравните результат;
• сверяйте версию ПО и патч-уровень: что пишет сканер и что установлено по факту;
• проверьте, не было ли в момент скана перегрузки CPU или диска, обрывов сети;
• сопоставьте находку с источником: CVE и условие срабатывания (версия, компонент, включенная функция);
• если расходится только один признак (например, порт виден, но версия не читается), пометьте как «требует подтверждения».

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

Учет и решения

Ручное подтверждение чаще всего нужно для критичных сервисов, спорных находок на серверах и случаев, где сетевой детект опирается на косвенные признаки (баннеры, открытые порты), но доступ ограничен.

Фиксируйте итог в одном реестре, чтобы не возвращаться к одному и тому же каждую неделю: «подтверждено», «не подтверждено», «принято как риск» (с датой пересмотра). Исключения используйте как техническую меру (например, ложный детект конкретной версии), а не как способ «спрятать» проблему. У исключения всегда должны быть владелец, причина и срок действия.

Как настроить процесс шаг за шагом

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

Сначала соберите инвентарь. Достаточно базы: какие устройства сканируем (ПК, ноутбуки, серверы), где они находятся (офис, филиал, VPN), кто отвечает за актив (ИТ, бухгалтерия, подрядчик), и насколько критична остановка. На этом шаге часто всплывают «забытые» машины в переговорных или тестовые серверы.

Дальше выберите подход по группам. Агент удобен для ноутбуков и удаленных сотрудников, сеть подходит там, где все в одном сегменте и есть стабильные окна. Смешанная схема обычно самая практичная: например, агенты на мобильных ПК, сетевые проверки для серверов в дата-центре.

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

Рабочая последовательность:

• разбейте активы на 3-5 групп по типу и важности и выберите для каждой агентный, сетевой или смешанный режим;
• настройте доступы только там, где они реально нужны (например, для проверки установленных патчей);
• задайте расписание и лимиты (скорость, параллельность), затем проведите пилот на 10-20 устройствах;
• согласуйте формат отчета: что считается критичным, в каком виде приходит задача, кто подтверждает риск;
• переведите процесс в цикл: сканирование, триаж, исправление, повторная проверка.

Хороший пилот - это один отдел и один серверный сегмент. Если после первого запуска пользователи жалуются на «тормоза», а сеть проседает, не расширяйте охват. Сначала уменьшите параллельность, перенесите окна и уточните исключения.

Финальный штрих - маршрут обработки находок. Договоритесь, какие уязвимости закрываются патчами, какие - настройками, а какие принимаются как риск с датой пересмотра. Тогда результаты становятся управляемыми, а не просто «еще одним отчетом».

Короткий чеклист перед запуском и после

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

Перед запуском

Сначала договоритесь о правилах. Один созвон с ИТ, безопасностью и сервис-деском часто экономит часы разбирательств после.

• Согласуйте окна и частоту: когда можно нагружать сеть и ПК, а когда нельзя (например, закрытие месяца, учебные часы, ночные резервные копии).
• Задайте лимиты нагрузки: сколько одновременных проверок допускается на сегмент, и какие пороги по CPU или сети считать критичными.
• Проверьте инвентарь активов: какие подсети и группы устройств должны попадать в сканирование, и кто владелец каждой группы.
• Пересмотрите исключения: временные пометьте сроком, постоянные обоснуйте.
• Определите контакты и действия при инцидентах: куда звонить, если сканирование «положило» слабый Wi-Fi, старый принтер или узкий канал.

После запуска

Первые 1-2 цикла лучше считать тестовыми. Смотрите не только отчет по уязвимостям, но и то, как сканирование ведет себя в реальной сети.

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

Ориентир простой: если после старта выросло число тикетов «интернет тормозит», а в отчете много уязвимостей на одном и том же продукте, начните с лимитов параллельности и проверки детектов, а не с расширения охвата.

Пример: компания на 300 ПК и 20 серверов без перегруза сети

Компания: 300 ПК (из них 80 ноутбуков), 20 серверов. Есть головной офис и 4 филиала, связь с филиалами через VPN с ограниченной полосой. ПК разделены по типу работы: бухгалтерия, колл-центр, инженерный отдел. Цель: регулярное сканирование уязвимостей конечных точек без жалоб на «тормоза» и без просадки каналов.

Выбрали смешанную модель. На ноутбуки поставили агент: они часто уходят из офиса, а агент проверяет устройство и вне сети, и в домашней Wi-Fi. В серверных подсетях сделали сетевое сканирование: серверы всегда доступны, и важно видеть открытые порты и конфигурации именно «снаружи» сегмента.

Расписания развели по окнам, чтобы не пересекаться с пиковыми нагрузками:

• Колл-центр: короткие проверки ночью по будням, полная проверка в воскресенье.
• Бухгалтерия: полная проверка после закрытия дня 2 раза в неделю.
• Инженеры: в обед только «легкий» профиль, полная проверка в субботу.
• Серверы: сетевой скан по ролям (AD, почта, приложения) разными ночами, чтобы не бить по дискам и бэкапам.

Чтобы не «положить» каналы в филиалы, для обновлений агентов и передачи результатов выставили лимиты: не больше 10 одновременных агентов на филиал, ограничение скорости на хост и случайный сдвиг старта (джиттер) на 30-60 минут. Для сетевого сканирования филиалов выделили отдельные окна и снизили параллельность, чтобы VPN не забивался.

Через первую неделю получили 10 находок. Три оказались ложными: сканер ругался на старую версию компонента, но на ПК уже стоял патч, просто файл имел другой номер сборки. Две находки потребовали исключения на 30 дней: в бухгалтерии работало legacy-приложение, которое ломалось при обновлении библиотеки. Эти исключения оформили как временные, с датой пересмотра, владельцем риска и компенсирующей мерой (ограничение доступа по сети и усиленный мониторинг).

Следующие шаги: сделать процесс регулярным и управляемым

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

Зафиксируйте роли и правила

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

• Владелец сканирования: расписания, охват, контроль нагрузки.
• Владелец исправлений: патчи, настройки, обновления ПО на устройствах.
• Владелец исключений: согласование, срок действия, пересмотр.

Исключения держите как временную меру. У каждого исключения должны быть причина, срок пересмотра и компенсирующие меры (например, сегментация, ограничение доступа, усиленный мониторинг).

Метрики, без которых процесс не управляется

Не нужно десятки графиков. Возьмите 3-4 показателя и смотрите их каждую неделю:

• покрытие: какая доля ПК и серверов реально сканируется;
• время закрытия: сколько дней проходит от находки до устранения;
• повторные находки: что возвращается снова и снова;
• доля ложных срабатываний: сколько результатов не подтверждается.

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

Если нужен подрядчик, чаще всего имеет смысл отдать внедрение (настройку расписаний, агентный и сетевой контуры, интеграции с учетом инцидентов) и регулярное сопровождение (пересмотр исключений, разбор ложных срабатываний, отчеты для руководства). GSE.kz (gse.kz) как системный интегратор может помочь выстроить такой процесс на вашей инфраструктуре и поддерживать его в рабочем состоянии.