MaxPatrol SIEM + ГосСОПКА: автоматическая передача инцидентов КИИ через API

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

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

Что технически означает «передача через API»

ГосСОПКА предоставляет API на основе TAXII 2.1 - это стандартный протокол обмена данными об угрозах и инцидентах, данные передаются в формате STIX 2.1. MaxPatrol SIEM с версии 5.0 умеет отправлять инциденты во внешние системы через action в правилах корреляции - HTTP POST с телом в JSON.

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

Первый - аутентификация. API ГосСОПКА работает по сертификатному принципу: каждый субъект получает клиентский сертификат при регистрации личного кабинета. Сертификат нужно корректно прописать в настройках коллектора MaxPatrol - не в теле action, а в конфигурации HTTP-клиента коллектора. Это не документировано в базовом руководстве MaxPatrol по интеграциям, нашли в технической документации НКЦКИ после получаса поиска.

Второй - маппинг полей. STIX 2.1 ожидает конкретную структуру объектов типа incident и indicator. MaxPatrol SIEM хранит инциденты в своей внутренней модели: severity, assets, matched_rule, timestamp и т.д. Эти поля нужно привести к STIX-нотации вручную в шаблоне action.

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

• name - из incident.name MaxPatrol (название правила корреляции)
• description - генерируем шаблоном из matched_rule.description + список затронутых активов
• severity - конвертируем из числового (1-10 в MaxPatrol) в текстовой enum STIX: low / medium / high / critical; граница high у нас с 7
• first_observed / last_observed - из incident.start_time и incident.end_time
• object_refs - массив ссылок на observed-data объекты; для каждого актива создаём отдельный объект с IP и hostname

Самая нудная часть - object_refs: STIX требует, чтобы каждый связанный объект имел уникальный UUID в формате observed-data--<uuid4>. MaxPatrol не генерирует такие идентификаторы сам, пришлось писать шаблон, который вычисляет UUID на основе хэша от IP-адреса актива и временной метки инцидента. Немного изобретательства, но работает детерминированно.

Тестирование канала без реального инцидента

Это оказалась отдельная задача. Идея - проверить, что данные доходят в правильном формате и API ГосСОПКА их принимает, не дожидаясь настоящего инцидента.

НКЦКИ предоставляет тестовую среду (sandbox) - отдельный endpoint с тем же API, но не попадающий в продуктивную базу. Хорошая новость: он есть. Плохая: документация по нему скудная, URL и параметры доступа пришлось уточнять через техподдержку НКЦКИ напрямую - получили ответ через два рабочих дня.

Для теста мы сделали отдельное правило корреляции в MaxPatrol с условием срабатывания на специальный тестовый тег в событии - его можно навесить вручную на любое событие в интерфейсе. Правило срабатывает, action формирует STIX-пакет и отправляет на тестовый endpoint. В ответ API возвращает идентификатор принятого объекта - это подтверждение, что структура корректная.

На первой итерации API вернул 422 с описанием: поле created в объекте инцидента должно быть в UTC с явным суффиксом Z, а не в локальном времени. MaxPatrol отдавал timestamp в московском времени без указания зоны. Исправили шаблон - перевели в UTC и добавили Z. Вторая итерация прошла чисто.

Что нужно проверить перед включением в продуктиве

Несколько вещей, которые мы проверяем на каждом таком проекте:

Срок действия клиентского сертификата. Сертификаты ГосСОПКА не вечные, и если он истечёт - передача молча перестанет работать. Нужен мониторинг срока действия: мы добавили alert в Zabbix на 30 дней до истечения.

Очередь при недоступности endpoint. Если канал до ГосСОПКА недоступен в момент инцидента - MaxPatrol не буферизует неотправленные события автоматически. Action просто вернёт ошибку. Мы настроили логирование неуспешных отправок в отдельный датасет внутри MaxPatrol - оттуда можно вручную инициировать повторную отправку.

Дублирование инцидентов. Если правило срабатывает несколько раз на один и тот же инцидент при обновлении - API ГосСОПКА может получить дубли. STIX позволяет передавать modified для обновления существующего объекта, но для этого нужно сохранять выданный API идентификатор. Пока мы реализовали простой вариант: один инцидент - одна отправка, без обновлений. Это закрывает основной кейс, но не покрывает ситуацию, когда инцидент существенно изменился.

Что в итоге

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

Общее впечатление: технически задача решаемая, но требует аккуратности в деталях - особенно в части формата timestamp и маппинга объектов. Документация со стороны НКЦКИ есть, но местами отстаёт от реального поведения API, и без прямого контакта с техподдержкой несколько вопросов просто не решить быстро.

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