MaxPatrol SIEM и ГосСОПКА в 2025 году: настройка интеграции и разбор инцидента на обновлённых правилах

Новый пакет корреляционных правил для MaxPatrol SIEM вышел тихо - обновление в репозитории PT Knowledge Base, несколько строчек в release notes. Но за этим стоит конкретная причина: ФСБ методично уточняет требования к форматам и срокам передачи информации об инцидентах в ГосСОПКА, и вендор адаптирует правила под актуальный профиль угроз для объектов КИИ. Мы как раз занимались аудитом у клиента-субъекта КИИ второй категории, когда это обновление прилетело - так что разбирать пришлось не в теории.

Что изменилось в правилах

Пакет обновлений затрагивает несколько направлений сразу.

Правила для АСУ ТП и промышленных протоколов. Добавлены новые корреляционные правила под Modbus, DNP3 и ряд проприетарных промышленных протоколов. Раньше MaxPatrol SIEM на этом участке требовал ручной доработки - правила были либо слишком широкими (генерировали шум), либо отсутствовали вовсе для нестандартных вендоров. Новый пакет закрывает наиболее распространённые сценарии: аномальные команды записи в ПЛК, попытки смены режима работы устройства, сканирование сегмента ОТ.

Таймлайн и приоритеты под требования ФСБ. Регулятор зафиксировал конкретные сроки первичного уведомления об инцидентах на объектах КИИ - и правила теперь учитывают этот временной контекст. Часть правил получила скорректированный приоритет: то, что раньше шло как «medium», по новой классификации поднимается до «high» именно потому, что по требованиям ГосСОПКА требует уведомления в течение трёх часов.

Интеграция с НКЦКИ. Это, наверное, самое ощутимое изменение для тех, кто работает с ГосСОПКА напрямую. MaxPatrol SIEM теперь умеет формировать карточку инцидента в формате, который принимает НКЦКИ - с обязательными полями, классификатором типа инцидента и технической информацией по шаблону ФСБ. Раньше это делалось руками или через промежуточный скрипт. Теперь - из интерфейса SIEM, хотя и не в одно нажатие кнопки.

Настройка интеграции: где споткнулись

Документация на интеграцию с ГосСОПКА у Positive Technologies есть, но написана под идеальный случай. На практике у клиента возникло несколько нюансов, которые стоит знать заранее.

Сетевая доступность. Взаимодействие с НКЦКИ идёт через выделенный канал или через защищённый шлюз ГосСОПКА. Если у клиента ещё не оформлено подключение к технической инфраструктуре ГосСОПКА - а у многих субъектов КИИ оно числится «в процессе» - интеграция просто не заработает, сколько бы правильно ты ни настроил SIEM. Это организационный вопрос, который нужно решать параллельно с технической частью, а не после.

Маппинг классификаторов. Классификатор типов инцидентов по требованиям ФСБ не совпадает один в один с внутренней таксономией MaxPatrol SIEM. Несколько категорий пришлось настраивать вручную через таблицу соответствия в настройках коннектора. Это не сложно, но требует понимания обеих систем классификации одновременно - и нескольких часов, чтобы не наделать ошибок, которые потом вылезут в неправильно заполненных карточках инцидентов.

Права доступа и учётная запись. Для работы коннектора нужна учётная запись в ЛК ГосСОПКА с конкретным набором прав. У клиента учётка была создана для ручной работы - прав для автоматической отправки не хватало. Пришлось обращаться в НКЦКИ за расширением прав, что заняло несколько рабочих дней.

Как выглядит инцидент через новый стек

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

В один из вечеров MaxPatrol SIEM отработал правило аномального поведения: учётная запись сервисного пользователя, которая обычно работает строго в рамках технологического сегмента, попыталась аутентифицироваться на нескольких рабочих станциях корпоративного сегмента в течение десяти минут. Новое правило из обновлённого пакета - раньше этот паттерн не коррелировал.

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

1. Алерт в SIEM с приоритетом «high» - автоматически, по новому правилу.
2. Аналитик SOC открывает карточку: видит цепочку событий, исходные логи, хост-источник.
3. Параллельная проверка через MaxPatrol VM: хост-источник - сервер технологического сегмента без актуальных обновлений безопасности, несколько известных уязвимостей в статусе «не устранено».
4. Изоляция хоста, сбор артефактов, расследование.
5. Итог: скомпрометированная сервисная учётка, использованная для разведки. Источник компрометации - фишинговое письмо на адрес технолога, открытое с корпоративной станции.

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

Что в сухом остатке

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

Но конкретный шаг в сторону практической интеграции с ГосСОПКА - заметен. Меньше ручной работы на этапе формирования уведомления, более релевантные правила для промышленных сегментов, учёт регуляторных сроков в приоритизации алертов. Для субъектов КИИ, у которых интеграция с ГосСОПКА числилась «в планах» - сейчас хорошее время сдвинуть это с мёртвой точки, пока требования ФСБ не начали проверяться жёстче, чем сейчас.

Регуляторика по КИИ в 2025 году заметно плотнее, чем год назад - мы это видим и по изменениям в приказе ФСТЭК № 239, и по практике клиентов. SIEM и ГосСОПКА - не самостоятельная история, а часть общей системы мер, и лучше выстраивать её без аврала.