MaxPatrol SIEM vs RuSIEM: два года в продакшне у клиента с КИИ - честный разбор

Когда два года назад мы разворачивали MaxPatrol SIEM у клиента - крупный производственный холдинг, три значимых объекта КИИ второй категории - вопрос «а может RuSIEM?» звучал на каждом совещании по выбору инструментов. В итоге выбрали MaxPatrol: сертификат ФСТЭК, наличие коробочных правил под Windows/AD/VipNet, известное имя для регулятора. RuSIEM остался в списке «посмотрим потом». Сейчас MaxPatrol SIEM 8.0 и RuSIEM оба анонсировали обновления корреляционных движков с упором на детекцию угроз КИИ - и это хороший повод написать, что два года реальной эксплуатации добавили к тому выбору.

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

Что работает без боли

Коробочные правила под Windows и AD. Это реально хорошо. Правила на Kerberoasting, Pass-the-Hash, аномальное время входа, нетипичные источники аутентификации - настраиваются за разумное время и дают сигнал. Не идеальный - но рабочий. Для инфраструктуры, где 80% активов это Windows Server и AD, это существенно сокращает время до первого работающего SOC-процесса.

Сбор событий с отечественных СЗИ. ViPNet Coordinator, Secret Net Studio, Dallas Lock - коннекторы есть, работают. Не без нюансов: в некоторых версиях ViPNet нормализация была с артефактами, пришлось подкрутить. Но в целом это не то место, где тратишь неделю.

Инвентаризация активов через MaxPatrol VM. Когда SIEM и сканер - один вендор, контекст актива в событии появляется почти автоматически. Это сильно упрощает корреляцию: видим событие с хоста, у которого есть CVE с CVSS выше 8 и открытый порт наружу - это уже приоритет без ручного обогащения.

Где пришлось строить самим

Промышленные протоколы и OT-сегмент. Вот тут коробка заканчивается быстро. Modbus, OPC-UA, DNP3 - нормализаторов под эти протоколы в базе нет или они рудиментарные. Для КИИ в промышленном секторе это критичный пробел: именно там, где угрозы самые чувствительные, детекция самая слабая из коробки. Мы писали кастомные нормализаторы под конкретное оборудование клиента - это несколько недель работы, и это нужно закладывать в проект заранее.

Linux и опенсорсный стек. Под классический LAMP-стек, nginx, PostgreSQL, Docker - правил мало. Аномальный cron на Linux-сервере, подозрительные bind-монтирования в контейнере, нетипичные исходящие соединения от пользователя postgres - всё это пишешь сам. Для инфраструктуры с большой долей Linux это реально ощутимо: eBPF-детекция на K8s-нодах мы именно поэтому и тестировали - как дополнение к SIEM, а не замену.

Детекция по BDU ФСТЭК. Корреляция с реестром угроз ФСТЭК декларируется, но сопоставление конкретных техник с конкретными угрозами из BDU требует ручной работы. Готового маппинга «событие -> угроза из BDU» нет - есть инструмент, которым можно это построить.

ГОСОПКА: от теста до живой отправки

Интеграция с ГОСОПКА у MaxPatrol SIEM реализована через механизм action в корреляционном правиле: при срабатывании правило отправляет уведомление в НКЦКИ. В теории - красиво. На практике выяснилось несколько вещей.

Первое - реестровый идентификатор объекта КИИ. Его нужно заводить вручную как кастомный атрибут актива. Это не страшно, но это работа, которую надо сделать до того, как правило сработает в первый раз. Мы описывали обновление API ГОСОПКА в марте - с тех пор ситуация не упростилась: новый формат требует kii_registry_id как обязательное поле, и если атрибут не заведён, уведомление уходит с ошибкой. Тихо, без алерта внутри SIEM.

Второе - классификация инцидента. impact_category принимает фиксированный список значений. Корреляционное правило должно уметь выставить правильную категорию - либо в логике самого правила, либо через атрибут события. Это не сложно, но это отдельный слой логики, который нужно проектировать.

Третье - проверяйте ответ сервера. MaxPatrol не показывает детальный ответ НКЦКИ в интерфейсе. Нужно идти в логи action-а и смотреть тело ответа там. Без этого можно месяц думать, что уведомления уходят - и однажды обнаружить, что НКЦКИ их отклоняет.

RuSIEM - что можно сказать с дистанции

Глубокого опыта эксплуатации RuSIEM у нас нет - видели у одного клиента в среднем бизнесе, не КИИ. Субъективно: UI удобнее для аналитика, база правил меньше но структурирована понятнее, поддержка отвечает быстрее. Новый коробочный движок с претензией на KII-детекцию - пока смотрим на тезисы из релизных заметок, не на живую инсталляцию. Брать только на основании обновлённого маркетинга было бы торопливо.

Что важно для выбора в КИИ-контексте: сертификат ФСТЭК у MaxPatrol есть и он актуален, у RuSIEM сертификат тоже есть, но при закупке нужно сверять конкретную версию с реестром.

Где стоим сейчас

Два года спустя MaxPatrol SIEM у клиента работает и приносит пользу. Но честный ответ на вопрос «а всё ли работает из коробки» - нет. Коробка закрывает Windows/AD/стандартные СЗИ. Всё что связано с Linux, OT, нестандартными источниками и тонкой настройкой ГОСОПКА - это проектная работа, которую надо планировать и оплачивать отдельно.

Если аудит инфраструктуры показывает большую долю промышленных систем или Linux в составе КИИ-объектов - закладывайте на кастомные правила и нормализаторы столько же времени, сколько на базовое развёртывание SIEM. Это не недостаток продукта - это реальность любого enterprise SIEM: коробка даёт 60-70% покрытия для типового стека, остальное - работа команды.

Анонсы 8.0 смотрим с интересом, но оценивать будем по тому, что появится в реальных инсталляциях, а не по changelog.