За последние три года я развернул MaxPatrol VM, RedCheck Enterprise и подключил ScanFactory в четырёх корпоративных средах - от госоргана с AD на 2000 хостов до промышленного предприятия с КИИ. Маркетинговые таблицы вендоров врут. Не по злому умыслу - просто каждый измеряет покрытие по-своему. Реальная картина проявляется, когда запускаешь два сканера на одном хосте и сравниваешь экспорты через
comm -23. Этот материал - итог такого сравнения: российские сканеры уязвимостей, их реальное покрытие CVE, расхождения в детекции и готовность к проверке ФСТЭК.Зачем сравнивать сканеры на одной инфраструктуре
Большинство русскоязычных обзоров строятся по шаблону: взяли маркетинговые PDF-ки трёх вендоров, составили таблицу «есть/нет». На выходе - одинаковые галочки у всех и нулевая практическая ценность. Пентестеру или VM-инженеру нужно другое: как конкретный сканер уязвимостей ФСТЭК ведёт себя на реальных хостах, где детекция расходится и почему.Проблема глубже, чем кажется. По данным Cyentia Institute (отчёт «Prioritization to Prediction», Vol. 1, 2018), лишь около 5,5% опубликованных CVE когда-либо эксплуатируются в реальных атаках (в более поздних томах - от 2% до 7% в зависимости от методологии). Так что критична не «ширина покрытия» (сколько CVE в базе), а скорость появления сигнатуры и точность детекции - отсутствие false positive и false negative.
Именно тут российские сканеры уязвимостей расходятся сильнее всего. Именно это я и сравниваю ниже.
MaxPatrol VM: обзор глазами инженера
MaxPatrol VM от Positive Technologies - флагман российского рынка управления уязвимостями. Трёхзвенная архитектура: сервер управления, распределённые сканирующие узлы, веб-консоль. Поддерживает агентный и безагентный режим.Что работает хорошо
Continuous VM - главное преимущество. Когда в NVD или БДУ ФСТЭК появляется новая уязвимость, MaxPatrol VM автоматически проверяет, затронуты ли уже проинвентаризированные активы. Не нужно ждать планового сканирования - и на КИИ первой категории это реально спасает.Интеграция с MaxPatrol SIEM и PT Network Attack Discovery позволяет коррелировать уязвимости с событиями: если на хосте обнаружена CVE и одновременно SIEM фиксирует подозрительный трафик по MITRE ATT&CK T1190 (Exploit Public-Facing Application), приоритет взлетает мгновенно. На практике это означает, что VM-инженер не разгребает тысячу алертов - ему прилетает десяток, но каждый по делу.
Приоритизация по ExploitabilityScore с учётом публичных эксплоитов - не просто CVSS, а реальный контекст: есть ли PoC на Exploit-DB, фигурирует ли CVE в каталоге CISA KEV. Например для меня, это одна из самых полезных фич - CVSS 9.8 без публичного эксплоита и CVSS 7.5 с готовым PoC на GitHub требуют совершенно разного внимания.
Где MaxPatrol VM буксует
Стоимость. Для организаций менее 500 активов лицензия непропорционально дорога. Минимальный боевой деплой с выделенным сервером управления и парой сканирующих узлов для сегментированной сети - серьёзный бюджет.Сложность развёртывания в изолированных сегментах. Формально поддерживается, но настройка передачи данных из изолированного сегмента через однонаправленные шлюзы - задача на несколько дней с участием вендора. Я потратил на это три рабочих дня на одном из проектов, и без инженера PT не обошлось.
Покрытие специфического российского ПО. MaxPatrol VM неплохо работает с Windows AD, Linux (RHEL, Debian, Ubuntu), сетевым оборудованием Cisco. Но при сканировании хостов с Astra Linux SE или ALT Linux детекция заметно тоньше, чем у RedCheck. Об этом ниже.
RedCheck: сканер уязвимостей для госсектора
RedCheck от АЛТЭКС-СОФТ - сертифицированный сканер уязвимостей ФСТЭК, который чаще всего встречается в госструктурах и организациях с жёсткими требованиями к compliance.Сильные стороны
Нативная интеграция с БДУ ФСТЭК. RedCheck изначально проектировался под российскую нормативку. Идентификаторы BDU:XXXX-XXXXX - первичные в отчёте, CVE - вторичные. Для инспектора ФСТЭК при проверке выполнения меры АНЗ.1 (Приказы ФСТЭК N 21, N 239, N 117) это принципиально: он ожидает именно BDU-идентификаторы. Если принесёте отчёт только с CVE - будут вопросы.Покрытие российского ПО. 1С, Astra Linux, ALT Linux, PostgreSQL (включая PostgresPro), Apache-стек - RedCheck детектирует уязвимости в этих продуктах заметно лучше любого другого инструмента на рынке. Для инфраструктур, прошедших импортозамещение, это решающий фактор.
Compliance-аудит по OVAL-профилям. RedCheck проверяет не только наличие уязвимостей, но и соответствие конфигураций - например, требования DISA STIG для PostgreSQL или собственные профили ФСТЭК. Одним инструментом закрываете и АНЗ.1 (анализ уязвимостей), и часть мер по контролю конфигураций.
Где RedCheck проигрывает
Нет continuous VM. RedCheck работает в режиме периодического сканирования - по расписанию или по запросу. Между сканированиями новые уязвимости не обнаруживаются автоматически. Для объектов КИИ первой категории, где нужен непрерывный мониторинг, это серьёзный минус.Приоритизация примитивнее. Нет встроенного учёта EPSS или CISA KEV. Приоритет строится в основном на CVSS-скоре. Когда у вас 3000 уязвимостей и половина - CVSS 7+, разделять их вручную по эксплуатабельности - удовольствие сомнительное.
Интеграционные возможности уже. API есть, Syslog есть, но по сравнению со связкой MaxPatrol SIEM + NAD - небо и земля. Для полноценного VM-процесса потребуется внешняя SGRC-платформа.
ScanFactory: сканер внешнего периметра
ScanFactory - SaaS-решение для непрерывного мониторинга внешнего периметра. Принципиально другая ниша: не сканирование внутренней инфраструктуры, а attack surface management.Для чего подходит
Быстрый старт без инфраструктуры - добавляешь домен, получаешь результат. Непрерывный мониторинг веб-приложений и API. Интеграция с DevSecOps-пайплайнами. Для организаций с развитым веб-периметром ScanFactory закрывает задачу, которую MaxPatrol VM и RedCheck решают хуже - постоянный мониторинг внешней атакующей поверхности.Критические ограничения
Внутренняя инфраструктура не сканируется. Для выполнения АНЗ.1 по Приказам ФСТЭК N 21 и N 239 ScanFactory в одиночку не годится - регулятор требует анализ защищённости всей информационной системы, включая внутренние сегменты.Сертификация ФСТЭК - статус нужно уточнять у производителя, он может меняться. Без подтверждённого сертификата для ГИС и КИИ этот инструмент - дополнение, а не основной сканер.
Нет поддержки БДУ ФСТЭК в классическом виде. Отчёты формируются с CVE-идентификаторами, BDU-привязка отсутствует. Для инспектора - минус.
Сравнение по ключевым критериям
| Критерий | MaxPatrol VM | RedCheck | ScanFactory |
|---|---|---|---|
| Сертификат ФСТЭК | Да | Да | Уточнять |
| Режим сканирования | Непрерывный (Continuous VM) | Периодический | Непрерывный (внешний периметр) |
| Поддержка БДУ ФСТЭК | Да | Да (приоритетный источник) | Нет |
| Агентное сканирование | Да | Да | Нет |
| Безагентное сканирование | Да | Да | Да (SaaS) |
| Покрытие Astra Linux / ALT Linux | Частично | Нативно | Нет |
| Покрытие Windows AD | Нативно | Да | Нет |
| Покрытие сетевого оборудования | Cisco, Huawei, Check Point | Cisco, Huawei | Нет |
| Compliance-аудит (OVAL) | Частично | Да | Нет |
| Интеграция с SIEM | MaxPatrol SIEM (нативно) | Syslog, API | Через API |
| Приоритизация по эксплуатабельности | ExploitabilityScore + публичные PoC | CVSS-based | CVSS + контекст периметра |
| Внутренняя инфраструктура | Да | Да | Нет |
| Внешний периметр | Ограниченно | Ограниченно | Нативно |
| Целевая аудитория | Крупные организации, SOC, КИИ 1-й кат. | Госорганы, КИИ, импортозамещение | DevSecOps, веб-периметр |
Пропасть между БДУ ФСТЭК и NVD: что это значит для покрытия CVE
Тема, которую российские обзоры обходят стороной, но для пентестера она ключевая.
По данным Recorded Future Insikt Group (2022, «Russia's National Vulnerability Database»), БДУ ФСТЭК публикует лишь часть от общего числа известных уязвимостей. Задержка публикации по сравнению с NVD и CNNVD может составлять десятки дней. При этом ФСТЭК не позиционирует БДУ как исчерпывающую базу - её фокус на уязвимостях, характерных для ГИС и критических объектов.
На практике это значит: если ваш сканер уязвимостей ФСТЭК опирается только на БДУ, вы гарантированно пропустите значительную часть уязвимостей. MaxPatrol VM и RedCheck используют БДУ в дополнение к NVD и собственным базам, но приоритет источников различается.
Интересный факт из того же исследования: БДУ ФСТЭК покрывала около 61% CVE, известных как эксплуатируемые российскими APT-группами, - при том что общее покрытие БДУ составляло лишь ~10% от всех CVE в NVD. Иными словами, доля APT-релевантных уязвимостей в БДУ непропорционально высока по сравнению с общим объёмом базы. Recorded Future отмечает, что такая выборочность может объясняться не столько «фокусом на реальных угрозах», сколько разведывательной мотивацией при формировании базы. Выводы делайте сами.
Для VM-инженера суть такая: нельзя полагаться на один источник. MaxPatrol VM тут выигрывает - он комбинирует БДУ, NVD и собственную базу PT. RedCheck нативно работает с БДУ, но тоже подтягивает NVD.
Когда сканеры расходятся: детекция одних и тех же CVE
Вот тут начинается самое интересное. Берём конкретный сценарий, типичный для корпоративной среды: Windows Server 2019 (build 1809) с неустановленным патчем для CVE-2025-62221 - Use After Free в Windows Cloud Files Mini Filter Driver (CVSS 7.8 HIGH, CWE-416, повышение привилегий локально). Типичная уязвимость уровня ОС, которую оба сканера детектируют через проверку KB-обновлений.MaxPatrol VM при безагентном сканировании определяет уязвимость через проверку установленных KB. Агентный режим даёт более точный результат. RedCheck действует аналогично - проверяет KB через WMI/WinRM. В большинстве случаев оба находят одно и то же. Скучно? Подождите.
Расхождения начинаются на менее типовых хостах. На Astra Linux SE 1.7 с PostgresPro Enterprise RedCheck стабильно находит уязвимости, которые MaxPatrol VM пропускает - просто потому, что база детекции для российского ПО у RedCheck полнее. На сетевом оборудовании Huawei ситуация обратная: MaxPatrol VM чаще цепляет уязвимости в firmware.
Отдельная боль - version-based detection (проблема описана в публикациях ProjectDiscovery, актуальна и для российских сканеров). Оба - MaxPatrol VM и RedCheck - во многом полагаются на сопоставление версий пакетов. Backported patches (распространённая практика в Astra Linux и ALT Linux) приводят к ложным срабатываниям: сканер видит «старую» версию пакета, но патч безопасности уже накатан через бэкпорт. На одном проекте мы получили 40+ false positive на Astra Linux именно из-за этого - пришлось вручную фильтровать каждый алерт.
Независимые бенчмарки западных сканеров показывают существенный разрыв между заявленным покрытием и фактической точностью детекции. Российские вендоры таких бенчмарков не публикуют, но в моей практике разрыв между «заявленным покрытием» и «реальной детекцией» наблюдается у всех. Без исключений.
Практическое руководство: запуск сравнительного сканирования
Требования к окружению
- Два развёрнутых сканера: MaxPatrol VM (сервер + минимум один сканирующий узел) и RedCheck Enterprise (сервер). Версии: актуальные на момент тестирования, обновлённые базы.
- Сетевой доступ: учётная запись с правами локального администратора на Windows-хостах, root-доступ по SSH на Linux, SNMP community или SSH на сетевом оборудовании.
- Режим: безагентное сканирование для одинаковых условий.
- Запустите полное сканирование одного и того же хоста обоими сканерами с максимальной глубиной проверок. В MaxPatrol VM создайте задачу через веб-консоль с профилем «Полный аудит». В RedCheck - задачу с профилем «Аудит уязвимостей + Compliance».
- Экспортируйте результаты в CSV или XML. Ключевые поля для сопоставления: CVE-идентификатор, BDU-идентификатор (если есть), CVSS-скор, название уязвимости, затронутый компонент.
- Постройте diff - какие CVE нашёл только MaxPatrol VM, какие только RedCheck, какие оба. Для автоматизации хватит простого скрипта:
Bash:
# Извлечение CVE-ID из экспортов и построение diff
comm -23 <(grep -oP 'CVE-\d{4}-\d+' maxpatrol_export.csv | sort -u) \
<(grep -oP 'CVE-\d{4}-\d+' redcheck_export.csv | sort -u) \
> only_in_maxpatrol.txt
comm -13 <(grep -oP 'CVE-\d{4}-\d+' maxpatrol_export.csv | sort -u) \
<(grep -oP 'CVE-\d{4}-\d+' redcheck_export.csv | sort -u) \
> only_in_redcheck.txt- Проанализируйте расхождения. Для каждой CVE из diff проверьте: это false positive одного сканера или пропуск другого? Установлен ли патч? Применён ли бэкпорт? Точно ли версия ПО соответствует уязвимой?
Что проверяет ФСТЭК: практический чеклист
Для пентестеров, работающих с объектами КИИ и ГИС, - что именно инспектор ФСТЭК проверяет при оценке выполнения меры АНЗ.1.По Приказу ФСТЭК N 239 (КИИ) мера АНЗ.1 обязательна для значимых объектов всех категорий. По Приказу N 21 (ИСПДн) - для уровней защищённости УЗ-1 - УЗ-4. По Приказу N 17 (ГИС; с 2025 г. заменён Приказом N 117) - мера АНЗ.1 входит в базовый набор для классов К1 и К2; для К3 включается по результатам моделирования угроз.
Инспектор запрашивает:
- Сертификат ФСТЭК на средство анализа защищённости. Не сертифицированный инструмент (Nessus, OpenVAS, Nuclei) - мера АНЗ.1 считается невыполненной, даже если сканирование проводилось и CVE найдены. Да, нашли 500 уязвимостей Nuclei - молодцы, но мера не закрыта.
- Отчёты сканирования с BDU-идентификаторами. CVE в американском формате принимаются, но BDU - приоритет.
- Документирование устранения уязвимостей. Не просто «нашли», а полный цикл: нашли → приоритизировали → устранили → пересканировали → подтвердили устранение.
- Регулярность сканирования. Разовое сканирование перед проверкой не пройдёт - нужна история за период.
Отдельно про взаимодействие с ГосСОПКА (НКЦКИ) по ФЗ-187: субъекты КИИ обязаны уведомлять о компьютерных инцидентах не позднее 3 часов с момента обнаружения на значимых объектах КИИ и не позднее 24 часов для иных инцидентов (Приказ ФСБ России № 367 от 24.07.2018). Интеграция сканера с SIEM и процессом уведомления - не роскошь, а операционная необходимость. Если у вас ScanFactory нашёл критическую уязвимость на периметре, а внутренний SIEM об этом не знает - у вас проблема.
Как выбрать: матрица решений
Вместо универсального ответа - алгоритм выбора под конкретную ситуацию:
Крупная организация, КИИ 1-й категории, есть SOC - MaxPatrol VM. Непрерывный мониторинг, интеграция со стеком PT, приоритизация по эксплуатабельности. Дополнить ScanFactory для внешнего периметра.
Госорган, ГИС К1/К2, инфраструктура на российском ПО - RedCheck. Нативная работа с БДУ ФСТЭК, покрытие Astra Linux / ALT Linux / 1С, формирование отчётов для инспектора. Compliance-аудит по OVAL-профилям закроет и смежные меры.
Средняя организация, смешанная инфраструктура - зависит от бюджета. RedCheck как основной сканер + ScanFactory для внешнего периметра - разумный компромисс. MaxPatrol VM - если бюджет позволяет и есть ресурсы на развёртывание.
DevSecOps-команда, фокус на веб-приложениях - ScanFactory как основной инструмент для attack surface management. Но для выполнения АНЗ.1 в ГИС/КИИ потребуется дополнительный сертифицированный сканер для внутренней инфраструктуры.
Ни один сканер не закрывает все потребности. Комбинация двух инструментов - внутреннего (MaxPatrol VM или RedCheck) и внешнего (ScanFactory) - даёт покрытие, близкое к полному. Я на последнем проекте использовал связку RedCheck + ScanFactory и доволен результатом - при бюджете вдвое меньше, чем MaxPatrol VM.
Вопрос к читателям
При сравнительном сканировании Windows Server 2019 (1809) с помощью MaxPatrol VM и RedCheck я стабильно наблюдаю расхождение в 5–15% по списку CVE. Основной источник расхождений - различие в обработке KB-цепочек: один сканер считает superseded-KB закрытием уязвимости, другой - нет. У кого из вас есть опыт запускаcomm -23 по экспортам двух российских сканеров на одном хосте? Какой процент расхождения получился и какой тип уязвимостей чаще попадает в diff - Windows KB, Linux-пакеты или firmware сетевого оборудования?
Последнее редактирование модератором:
