SIEM, корреляция и ГосСОПКА: первые попытки настроить передачу инцидентов

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

Что уточнила ФСБ

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

Технической документации по интеграции - минимум. Конкретного протокола, формата передачи событий, адреса приёмного узла - этого в публичном доступе нет. Часть информации закрыта, часть, судя по всему, ещё в процессе оформления. Клиенты спрашивают: «А когда будет API или инструкция по подключению SIEM?» Честный ответ на сейчас - неизвестно.

С чего мы начали

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

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

Второе - регламент уведомления. Приказ №239 прописал срок - 24 часа с момента обнаружения. Регламент должен отвечать на вопросы: кто принимает решение о том, что инцидент подпадает под уведомление? Кто формирует уведомление? Куда оно уходит прямо сейчас, пока технического канала нет? Форма уведомления - пока по образцу ФСБ, который можно найти в опубликованных методических документах.

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

SIEM: корреляция как промежуточная задача

На нескольких проектах параллельно идёт работа с SIEM - у одного клиента MaxPatrol SIEM, у другого HP ArcSight, у третьего пока только syslog-сборка с перспективой перехода на нормальный инструмент. Задача одна: настроить корреляцию таким образом, чтобы на выходе получать не тысячи сырых событий, а осмысленные инциденты.

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

Несколько наблюдений по корреляции для объектов КИИ, которые не очевидны сразу:

• Промышленные протоколы нужно логировать отдельно. Modbus, OPC, PROFINET - это не стандартный сетевой трафик, и их корреляция требует отдельных правил. Большинство готовых content-пакетов для SIEM написаны под корпоративный IT-сегмент.
• Временные метки из промышленного оборудования ненадёжны. Встречали контроллеры с часами, которые уходят на несколько часов в сторону. Нормализация времени перед записью в SIEM обязательна, иначе корреляция по времени даёт мусор.
• Ложные срабатывания критичнее, чем кажется. Если SIEM в промышленном сегменте генерирует 50 инцидентов в день, оператор перестаёт на них реагировать за неделю. Надо добиться разумного числа реальных срабатываний.

Что получается в итоге

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

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