MaxPatrol SIEM и ГОСОПКА 2.0 API: автоматическая отправка инцидентов без ручного заполнения формы

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

Почему API, а не форма

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

API решает это через маппинг, который настраивается один раз. Дальше - триггер по правилу, автоматическое формирование карточки, отправка. Дежурный видит статус в интерфейсе SIEM и может вмешаться, если что-то пошло не так.

Структура запроса

API ГОСОПКА 2.0 принимает JSON по HTTPS с авторизацией через токен организации. Базовая структура карточки инцидента включает несколько блоков.

Обязательные поля - без них запрос вернёт 400:

• incident_type - тип инцидента из закрытого классификатора НКЦКИ (несанкционированный доступ, деструктивное ПО, нарушение доступности и ещё несколько категорий)
• object_id - идентификатор объекта КИИ, присвоенный при категорировании
• detection_time - время обнаружения в ISO 8601
• affected_systems - список пострадавших систем в формате идентификаторов из реестра объекта
• severity - уровень критичности по шкале НКЦКИ (low / medium / high / critical)
• description - текстовое описание, не менее 100 символов

Дополнительные, но практически обязательные - технически необязательны, но без них карточку могут вернуть на уточнение:

• ioc - индикаторы компрометации (IP, хэши, домены)
• attack_vector - вектор атаки
• initial_access - точка первоначального доступа
• affected_users - количество затронутых учётных записей

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

Маппинг полей MaxPatrol - ГОСОПКА

Это самая трудоёмкая часть настройки. SIEM работает в своей таксономии событий, ГОСОПКА ждёт свою классификацию.

Что мы делали в коннекторе MaxPatrol SIEM 8.0:

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

Detection_time берётся из поля event.time первого события в инциденте - это время обнаружения в SIEM, не время создания инцидента. Принципиально: ГОСОПКА хочет именно момент обнаружения, а не момент открытия тикета.

Affected_systems - самое болезненное поле. Идентификаторы систем в реестре объекта КИИ и имена хостов в SIEM - это разные вселенные. Пришлось завести справочник соответствия и подключить его к коннектору. Примерно 80% хостов покрылось автоматически, остаток - ручная доработка справочника. Без этого справочника автоматизация работает только для задокументированных систем.

Severity конвертируется из внутреннего criticality_score MaxPatrol по трём порогам, которые мы согласовали с заказчиком. Пороги субъективны - здесь нет универсального правила.

Фильтрация false positive до отправки

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

Поэтому мы добавили буферный шаг между срабатыванием правила и отправкой.

Логика такая:

1. Правило срабатывает - инцидент попадает в очередь на отправку, но не уходит автоматически.
2. Автоматические проверки. Коннектор прогоняет инцидент через несколько условий: уровень критичности не ниже high, источник события из числа источников с хорошим качеством данных, инцидент не дублирует уже открытый в ГОСОПКА за последние 24 часа.
3. Окно подтверждения - 15 минут. Если за это время дежурный не отклонил инцидент как false positive, отправка происходит автоматически. Если дежурный отклонил - уходит в ручной разбор.

Пятнадцать минут - баланс между скоростью уведомления (регулятор ждёт оперативности) и возможностью перехватить очевидный false positive. Для критических инцидентов (когда severity = critical) окно сокращается до пяти минут.

На первой неделе работы из очереди было отклонено примерно каждое пятое срабатывание - в основном плановые тесты безопасности и пентесты, которые шли без предварительного уведомления SOC. Это ожидаемо при запуске; план на следующий спринт - донастроить правила под эти исключения.

Где интеграция ещё сырая

Честно: с affected_systems справочник неполный - ряд нестандартных систем ОТ в реестр не внесён или внесён под именами, которые в SIEM не используются. Каждый такой инцидент требует ручного заполнения поля перед отправкой. Это решается доработкой справочника, но требует времени и участия владельцев систем.

Второй момент - качество поля description. Автоматически сгенерированный текст из шаблона MaxPatrol формально удовлетворяет минимуму в 100 символов, но читается как машинный вывод. Пока дежурный его редактирует вручную при сложных инцидентах - это правильно, но несколько нивелирует автоматизацию для тех случаев, где описание важно.

Если коллеги из отрасли уже прошли похожий путь и нашли способы автогенерировать человекочитаемые описания из данных SIEM - было бы интересно сравнить подходы.

О том, что вообще происходит с MaxPatrol и другими SIEM на рынке прямо сейчас, мы писали на прошлой неделе в сравнении отечественных SIEM 2026. Если нужна помощь с настройкой подобной интеграции - это задача для нашей практики интеграции.