Сравнение инструментов ИБ: выбор под задачу

Первый полный скан VM-платформы в среднем enterprise выдаёт тысячи findings. Критичных из них - сотни. Реально эксплуатируемых с периметра - единицы. Я видел, как команда две недели разгребала 4 000 findings после Nessus, а потом пентестер за день нашёл один открытый Jenkins без авторизации на 8080 - и через него забрал домен. Без контекста из SIEM и верификации пентест-инструментами отделить эти единицы от потока шума невозможно. Сравнение инструментов ИБ начинается не с рейтингов вендоров, а с понимания: каждый класс решает свою задачу, и подменять один другим - платить дважды.

Три категории: сканеры уязвимостей, SIEM-системы и утилиты для тестирования на проникновение. Scope не случаен - эти три класса формируют операционное ядро blue team и покрывают полный цикл: «найти уязвимость → обнаружить атаку → подтвердить угрозу». EDR, WAF, SOAR надстраиваются поверх, не заменяют. Если ядро собрано криво, надстройки ситуацию не спасут.

SIEM vs сканер уязвимостей vs пентест: три задачи и три режима​

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

Если наложить на MITRE ATT&CK, распределение становится наглядным:


Сканер находит дыру. SIEM фиксирует попытку через неё пролезть. Пентест доказывает, что пролезть действительно можно. Убираем любое звено - получаем слепую зону.

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

Этот принцип ложится на NIST CSF v2.0: сканирование покрывает Identify (ID.AM-01 - инвентаризация активов и обнаружение уязвимостей), SIEM - Detect (DE.AE-01 - анализ событий) и Respond (RS.AN-01 - расследование инцидентов), пентест верифицирует эффективность Protect (устранены ли уязвимости) и Detect (срабатывают ли механизмы обнаружения).

Для субъектов критической информационной инфраструктуры (ФЗ-187) принцип ещё жёстче: ФСТЭК требует не только наличия средств защиты информации, но и регулярного контроля их эффективности - включая анализ уязвимостей и тестирование на проникновение. Ссылаться на «у нас есть SIEM» недостаточно, нужен полный цикл.

Сравнение сканеров уязвимостей: типы и trade-offs​

По классификации Red Canary, сканеры уязвимостей делятся на несколько типов по целевой среде:

• Сетевые сканеры - инфраструктурные уязвимости: открытые порты, мисконфигурации, непатченное ПО на серверах и сетевом оборудовании
• Сканеры веб-приложений (DAST) - уязвимости из OWASP Top 10: Injection (A03:2021), Broken Access Control (A01:2021), Security Misconfiguration (A05:2021)
• Сканеры баз данных - слабые пароли, избыточные привилегии, непатченные СУБД
• Облачные сканеры - мисконфигурации AWS/Azure/GCP, нарушения cloud security best practices
• Контейнерные сканеры - уязвимости в Docker-образах и Kubernetes-кластерах

Тут важно не путать: сетевой сканер и DAST-сканер - разные инструменты с разными задачами. Nessus и OpenVAS сканируют сетевую инфраструктуру на известные CVE и мисконфигурации. Burp Suite и OWASP ZAP тестируют веб-приложения на логические уязвимости (SQL-инъекции, XSS, BOLA по OWASP API Security - API1:2023). Попытка закрыть обе задачи одним инструментом - прямой путь к ложному чувству защищённости: сетевой сканер не проверит бизнес-логику API, а DAST не найдёт непатченный SSH на сервере.

Ниже - сравнение сканеров уязвимостей трёх моделей: международный коммерческий, open source и российский сертифицированный. Между этими тремя подходами чаще всего и решается вопрос в российских организациях.


Для организаций с требованием сертификации ФСТЭК помимо MaxPatrol VM доступен RedCheck (АЛТЭКС-СОФТ) - сканер безопасности и средство аудита конфигураций, сертифицированный ФСТЭК и включённый в Реестр российского ПО. Отдельно стоит Qualys VMDR - облачная платформа, которая, по данным Red Canary, выходит за рамки сканирования и включает непрерывную инвентаризацию, приоритизацию и workflow устранения уязвимостей. Подходит крупным заказчикам с гибридной инфраструктурой, но в российском реестре ПО отсутствует.

Критерии выбора сканера безопасности​

Шесть параметров, на которые стоит смотреть:

1. Тип активов. Что сканировать: сетевую инфраструктуру, веб-приложения, облако, контейнеры? Универсальных лучших сканеров уязвимостей не бывает - каждый силён в своей нише.
2. Нормативные требования. Субъекты КИИ (ФЗ-187), государственные ИС, системы обработки ПДн уровня УЗ1-УЗ2 - только Реестр российского ПО с классом защиты не ниже требуемого (приказ ФСТЭК №76). OpenVAS, Nessus, Qualys для основного контура не подходят. Точка.
3. Масштаб инфраструктуры. На 50 хостах OpenVAS справится. На 5 000 - нужна платформа с распределённым сканированием и приоритизацией. CIS Controls v8 (CIS-1 и CIS-2) требуют непрерывного учёта активов - ручной подход на масштабе разваливается.
4. Квалификация команды. Open source требует экспертизы для развёртывания, настройки и поддержки. Коммерческие решения - порог входа ниже, стоимость выше.
5. Интеграция с SIEM. MaxPatrol VM + MaxPatrol SIEM - нативная связка. Nessus + Splunk - через плагины и API. OpenVAS + любой SIEM - через syslog и ручную настройку парсеров (а это отдельная боль).
6. TCO, не стоимость лицензии. Бесплатный OpenVAS с двумя инженерами на поддержке может стоить дороже коммерческого Nessus с вендорской техподдержкой. Считайте: лицензия + ФОТ + обучение + время на разбор false positives.

Как выбрать SIEM систему: от логов к инцидентам​

По данным Palo Alto Networks, SIEM-платформы в 2025–2026 годах переживают конвергенцию с XDR и внедрение AI-driven детекции. Но базовая задача не изменилась: собрать логи из разных источников, скоррелировать события и выделить то, что требует внимания аналитика SOC.

Типичная ошибка: организация покупает SIEM, ожидая от него функций XDR или SOAR. Через полгода - разочарование, потому что «SIEM не ловит APT» или «SIEM не реагирует автоматически». Он и не должен. По классификации Palo Alto Networks:

• SIEM - агрегация логов + корреляция + детекция + расследование
• XDR - глубокая телеметрия от интегрированных средств защиты + автоматизация реагирования
• SOAR - оркестрация и автоматизация постдетекционных задач (playbooks, enrichment)
• Log Management - хранение логов без security-аналитики (дешевле, но не детектирует угрозы)

Если задача - только хранение логов для compliance, Log Management обойдётся дешевле. Нужно детектировать угрозы - нужен полноценный SIEM.


Выбор решения для мониторинга безопасности определяется не только фичами, но и зрелостью команды. Splunk - один из самых серьёзных SOC инструментов на рынке, но без SPL-эксперта его потенциал не раскрывается. Wazuh развёртывается за день на одном сервере, но для масштабов свыше 500 EPS потребуется кластерная архитектура с OpenSearch - а это уже полноценная DevOps-задача. MaxPatrol SIEM нативно работает с российской ИТ-инфраструктурой, но ограничен on-premise развёртыванием - для облачных сред придётся искать дополнительное решение.

Sigma-правила - отдельный фактор TCO, о котором часто забывают. Sigma стал де-факто стандартом для описания detection rules. Splunk конвертирует их штатно через sigma-cli. Wazuh поддерживает частично. Российские SIEM-системы, как правило, требуют ручной адаптации Sigma-правил под собственный язык запросов - каждое обновление набора правил означает часы работы аналитика. При расчёте TCO считайте не только лицензию, но и стоимость поддержки detection content. На практике именно эта строка бюджета оказывается сюрпризом.

Для организаций с ограниченным бюджетом Wazuh - реальная альтернатива: HIDS, сбор логов, корреляция и compliance-reporting в одном open source пакете. Порог входа - базовые навыки Linux-администрирования и готовность поддерживать хозяйство своими силами.

Сравнение инструментов пентеста: от Nmap до BAS​

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


Для ручного пентеста базовый набор утилит:


Каждый инструмент закрывает свой этап kill chain. Nmap - разведка (Network Service Discovery, T1046). Metasploit - эксплуатация и пост-эксплуатация (Exploit Public-Facing Application, T1190). Burp Suite и OWASP ZAP - поиск веб-уязвимостей из OWASP Top 10: Injection (A03:2021), Broken Access Control (A01:2021), Security Misconfiguration (A05:2021). OWASP ZAP, по данным InvGate, удобен для команд с ограниченным бюджетом и начинающих специалистов благодаря интеграции с CI/CD и REST API.

Для организаций с минимальным бюджетом связка Nmap + Metasploit Framework + OWASP ZAP покрывает базовый пентест: разведка, сканирование, эксплуатация. Все три инструмента бесплатны.

Для тех, кому нужна непрерывная валидация вместо ежеквартального пентеста, существуют BAS-платформы. Бесплатные альтернативы: MITRE Caldera (эмулирует adversary behavior по техникам ATT&CK) и Atomic Red Team (набор атомарных тестов для проверки детектирующих правил). Caldera + Atomic Red Team - способ проверить, работают ли ваши правила корреляции в SIEM, без бюджета на коммерческий BAS.

Алгоритм выбора: от задачи к инструменту​

Шаг 4 - Посчитайте TCO. Лицензия - верхушка. Добавьте: ФОТ на администрирование, обучение команды, интеграцию с существующим стеком, стоимость поддержки detection content. Бесплатный Wazuh с двумя инженерами на полной загрузке может выйти дороже коммерческого SIEM с вендорской поддержкой.

Шаг 5 - Запросите пилот. Тестируйте на реальной инфраструктуре, не в лабораторных условиях. Ключевые метрики для пилота: количество false positives на 1 000 проверок, время триажа одного алерта, процент покрытия ваших типов активов.

Шаг 6 - Проверьте интеграцию. Сканер должен передавать результаты в SIEM. SIEM должен обогащать алерты данными сканера. Пентест должен верифицировать то, что нашли первые два. Если цепочка не собирается - пересмотрите выбор.

Интеграция: сканер + SIEM + пентест в одной цепочке​

Как отмечает Invicti, связка сканера и SIEM даёт синергию: сканер подтверждает реальные риски, SIEM обеспечивает контекстно-зависимое реагирование. На практике цепочка работает так:

1. Сканер проводит регулярное сканирование → результаты передаются в SIEM как asset context. Если на хосте обнаружена уязвимость, связанная с Vulnerable and Outdated Components (A06:2021 по OWASP Top 10), SIEM получает эту информацию для обогащения будущих алертов.
2. SIEM обогащает алерты данными об уязвимостях. Пример: на хосте срабатывает детекция Brute Force (T1110, Credential Access). Если на этом же хосте сканер нашёл слабую аутентификацию (Identification and Authentication Failures - A07:2021), приоритет алерта повышается автоматически. Дежурный аналитик видит не просто «кто-то брутит», а «кто-то брутит хост с дырявой аутентификацией» - разница колоссальная.
3. Пентест проводится по результатам обоих: верифицирует критичные findings и проверяет, детектирует ли SIEM эксплуатацию. Если при запуске nmap -sV --script vuln против хоста с известной уязвимостью SIEM не генерирует алерт на сканирование (T1046 - Network Service Discovery) - правило детекции нуждается в доработке. Эта команда проверяет детекцию разведки, а не эксплуатации (T1190). Для проверки алертинга на эксплуатацию используйте Metasploit или Atomic Red Team тест конкретной техники.

Эта связка соответствует CIS Controls v8: сканер покрывает CIS-1 (Inventory and Control of Enterprise Assets) и CIS-4 (Secure Configuration). SIEM покрывает мониторинг изменений и CIS-5 (Account Management - детекция аномального доступа). Пентест верифицирует эффективность всех контролей.

Для систематической проверки детектирующих правил используйте Atomic Red Team. Запуск теста, имитирующего конкретную технику ATT&CK (например, T1110 - Brute Force), занимает минуты. Если SIEM не сгенерировал алерт - правило требует доработки. Такая проверка может проводиться еженедельно силами одного аналитика - несопоставимо дешевле полноценного Red Team-упражнения.

Типичная ошибка интеграции - запустить всё в production без настройки парсеров. SIEM получает логи сканера, но не может их нормализовать. Findings лежат в базе, но не участвуют в корреляции. Выделяйте время на интеграцию - это полноценная инженерная задача, а не «подключить syslog за пять минут».

Большинство организаций, с которыми я работал, покупали инструменты ИБ до того, как строили процессы. Схема типовая: CISO получает бюджет, закупает SIEM с максимальным EPS, VM-платформу «как у конкурентов» и заказывает ежегодный пентест для аудитора. Через полгода SIEM генерирует тысячи алертов в день, из которых разбирается малая доля. Сканер нашёл тысячи уязвимостей - закрыли сотни. Пентест-отчёт лежит в PDF, потому что рекомендации невозможно приоритизировать без контекста из первых двух систем.

Проблема не в инструментах. Проблема в том, что процесс, связывающий их в единую цепочку, никто не проектировал. Сканер должен кормить SIEM контекстом. SIEM должен поднимать приоритет алертов на хостах с известными уязвимостями. Пентест должен верифицировать критичные findings и проверять, работает ли детекция. Без этой связки каждый инструмент работает в вакууме - и деньги потрачены, и реальная защищённость не выросла.

Рейтинг инструментов ИБ, каким бы полным он ни был, эту задачу не решит. Решит - понимание задачи каждого класса, пилотирование на реальных данных и интеграция с первого дня. Убеждён: тройка правильно настроенных open source инструментов бьёт пятёрку enterprise-платформ, работающих в изоляции. Инструмент без процесса - строка в бюджете, не в защите. Если интересно, как другие blue team команды выстраивают связку VM + SIEM в российских реалиях - на форуме codeby.net обсуждаем подобные кейсы в тематических тредах.