SIEM для КИИ: два набора правил корреляции - под ФСТЭК и под ГосСОПКА

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

Субъект - из промышленного сектора, SIEM уже стоял, даже работал. Правила корреляции были написаны несколько лет назад под собственные нужды SOC и с тех пор накопились в количестве, которое сложно описать иначе как «органический рост». Задача пришла с двух сторон одновременно: ФСТЭК на плановой проверке обозначил требования к составу событий и правилам обнаружения по Приказу №239, а ФСБ отдельно напомнил про обязательную передачу инцидентов в ГосСОПКА с дедлайном.

Почему два набора, а не один

Первый порыв клиента был понятен: давайте напишем одни правила, которые покрывают и ФСТЭК, и ГосСОПКА. Экономно, логично. Мы эту идею аккуратно разобрали.

ФСТЭК в рамках 239-го приказа интересует непрерывность защиты: полнота покрытия событий, глубина корреляции, обнаружение аномалий на уровне технологической сети. Здесь важна чувствительность - лучше лишний алерт аналитику, чем пропущенная атака на контроллер. Правила могут быть сложными, с контекстом из нескольких источников, с длинными временными окнами.

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

В итоге получается два логически разных потока с разными требованиями к качеству данных:

• Поток ФСТЭК - широкая корреляция, чувствительные пороги, всё для аналитика внутри SOC.
• Поток ГосСОПКА - узкий фильтр, только подтверждённые инциденты, строгий формат, API наружу.

Совместить их в одном наборе правил технически можно, но сопровождать это потом крайне неудобно. При изменении требований одного регулятора рискуешь поломать логику для другого.

Как делали разделение

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

Для потока ФСТЭК написали правила под четыре основных класса событий, которые приоритизировал регулятор:

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

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

API и обогащение данных

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

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

Где сейчас

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

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

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