Приказ ФСБ № 367: разрабатываем внутреннюю процедуру уведомления НКЦКИ об инцидентах на объектах КИИ

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

Проблема в том, что фундамент этот небольшой. Приказ 367 достаточно лаконичен по содержанию: даёт общие требования к составу уведомления и срокам, но не описывает операционный уровень - кто внутри организации это делает, по каком сигналу и в каком виде. Вот этот пробел мы сейчас и закрываем для заказчиков из числа субъектов КИИ.

Что говорит приказ

Основная механика по 367-му выглядит так: субъект КИИ при обнаружении компьютерного инцидента на объекте КИИ обязан в течение 24 часов уведомить НКЦКИ (Национальный координационный центр по компьютерным инцидентам - структура ФСБ, которая и является оператором ГосСОПКА). При инцидентах на объектах первой или второй категории срок - 3 часа от момента обнаружения.

Состав уведомления: дата и время обнаружения, описание инцидента, сведения об объекте КИИ, предварительная оценка ущерба, принятые меры. Плюс - обязанность направить обновление, если обстоятельства инцидента прояснились или изменились. Формальных форм в приказе нет - отсылка к регламенту НКЦКИ, который должен появиться отдельно.

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

Где ломается любая процедура без подготовки

Три часа - это очень мало. Особенно с учётом того, что:

• Инцидент надо сначала обнаружить и квалифицировать. Алерт в SIEM - это не инцидент. Это сигнал, который дежурный должен оценить, чтобы понять: это срабатывание корреляционного правила на легитимную активность или реальное событие, требующее реакции. До момента, когда кто-то принял решение «это инцидент», часы не тикают - или тикают, но никто не знает.

• Кто отправляет уведомление? Дежурный? Ответственный за ИБ? Руководитель? Если процедура не прописана, в три часа ночи в пятницу уведомление пойдёт тому, до кого дозвонились первым.

• Что именно писать в «описание инцидента», если первые два часа ушли на диагностику? На этапе обнаружения картина неполная по определению. Нужно понимать, что первичное уведомление - это именно первичное: никто не требует полного расследования за три часа.

Как мы строим внутреннюю процедуру

Работаем сейчас с несколькими заказчиками-субъектами КИИ. Подход, который вырабатывается на практике:

Первое - момент старта отсчёта. Фиксируем явное определение: отсчёт 24/3 часов начинается с момента, когда ответственный дежурный принял решение о квалификации события как инцидента на объекте КИИ. Это решение должно фиксироваться в тикете или журнале немедленно - для доказательства таймлайна, если понадобится.

Второе - матрица ответственных. Для каждого объекта КИИ определяем цепочку: дежурный оператор - дежурный специалист ИБ - ответственный за уведомление НКЦКИ. Последний - конкретное физическое лицо с подтверждёнными контактами и заместителем на случай отпуска. Не «отдел ИБ» - человек с именем.

Третье - шаблон первичного уведомления. Заранее готовим шаблон с заполненными статичными полями: наименование субъекта КИИ, реквизиты, перечень объектов с их предварительными категориями. В момент инцидента дежурный заполняет только переменные поля: дата/время, описание, объект. Это экономит критичное время и снижает риск забыть обязательный реквизит.

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

Что пока остаётся неопределённым

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

Временно закрываем это двумя контактами: известный email НКЦКИ (cert@gos-cert.ru) и телефон. Этого достаточно для первичного уведомления, пока не появится регламент с официальными каналами.

Промежуточный итог

Приказ 367 - необходимый документ, который устанавливает обязанность и основные параметры. Но между «обязанность уведомить» и «уведомление ушло вовремя» - целый операционный слой, который каждый субъект КИИ должен выстраивать самостоятельно.

Хорошая новость: если работа по категорированию объектов уже идёт - большая часть исходных данных для процедуры уже есть. Перечень объектов, ответственные, критичность - всё это частично собрано. Остаётся оформить это в регламент и проверить на табletop-учении, пока настоящего инцидента нет.

Процедуру информирования НКЦКИ разрабатываем в рамках работ по аудиту - вместе с документацией по категорированию и внутренними регламентами реагирования.