Приказ ФСТЭК № 227: разбираем акт категорирования объектов КИИ

Пока мы разбирались с Meltdown и Spectre, ФСТЭК выпустил ещё один важный документ по КИИ - приказ № 227, утверждающий форму акта категорирования объектов критической информационной инфраструктуры. Это не просто бланк. Структура формы по сути диктует методологию: как думать об объектах, что описывать и в каком порядке. Разбираемся что там внутри и как с этим работать.

Десять дней назад, когда 187-ФЗ вступил в силу, мы писали что инвентаризацию можно начинать не дожидаясь всех нормативных актов. Теперь у нас есть ещё один кусок пазла - утверждённая форма акта, под которую нужно подгонять результаты этой инвентаризации.

Что за документ и зачем он нужен

Акт категорирования - итоговый документ комиссии субъекта КИИ. В нём фиксируется: какие объекты есть, по каким критериям оценивались, какую категорию значимости получили (или не получили вовсе). Именно на основании акта ФСТЭК вносит объект в реестр значимых объектов КИИ.

Форма структурирована. Это хорошо - не нужно изобретать формат. Плохо то, что заполнить её грамотно без понимания логики всё равно не получится.

Раздел про объект: описание процессов

Первое, что нужно описать - к каким критическим процессам относится объект КИИ. Здесь чаще всего возникает первая ошибка.

Организации склонны писать про технологию, а не про процесс. «Система управления базами данных Oracle» - это не процесс. «Управление расчётами с абонентами» или «диспетчерское управление энергосетью» - это процесс. Объект КИИ существует потому что обеспечивает или участвует в каком-то процессе. И оценивать его нужно именно через призму этого процесса - что будет, если система упадёт или будет скомпрометирована.

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

Оценка показателей значимости: где ловушки

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

Несколько вещей, которые на практике вызывают вопросы.

«Количество пострадавших граждан». Цифру нужно обосновывать, а не брать с потолка. Для систем ЖКХ это худо-бедно считается - сколько абонентов в зоне обслуживания. Для информационных систем промышленного предприятия это сложнее: нужно думать о цепочке последствий. Остановка производства -> социальные последствия в регионе присутствия. Цепочка длинная, обоснование требует усилий.

«Ущерб в рублях». Прямой финансовый ущерб считается на уровне субъекта КИИ. Но форма также предполагает косвенные потери - это тема отдельного методологического разговора, у ФСТЭК нет жёстких инструкций по методике расчёта. Пока что видим что большинство комиссий действуют консервативно и не пытаются накрутить показатели - обратная история тоже не нужна никому.

Объекты «без категории». Если объект не достигает ни одного порога ни по одному показателю - он незначимый, но это не значит что про него можно забыть. Его всё равно нужно внести в перечень объектов и передать сведения в ФСТЭК. Форма акта это предусматривает - незначимые объекты отражаются отдельным разделом.

Взаимодействие комиссии и документирование

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

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

Вот здесь мы видим практический риск: акт, написанный формально, без реальной проработки последствий, вернётся. А переделывать документ, который уже подписан комиссией и руководством - не самое приятное занятие. Лучше сделать тяжелее один раз, но правильно.

Что значит «правильно» описать последствия

Это самый содержательный вопрос. Форма задаёт структуру, но не даёт ответа на вопрос «как думать».

Наш рабочий подход: идти от сценария инцидента к последствиям, а не от абстрактной «критичности». Для каждого объекта - моделируем три ситуации: полный отказ системы, частичный отказ, несанкционированный доступ с возможностью модификации данных или управляющих команд. Для каждого сценария - конкретные последствия с попыткой привязать их к показателям из постановления № 127.

Это трудоёмко, особенно для организаций с большим числом объектов. Но иного способа обосновать категорию документально мы не видим.

Где мы сейчас

Форма акта появилась, логика понятна. Нормативная база по КИИ всё ещё формируется: ждём финального текста постановления № 127, методических документов по оценке показателей. Часть вопросов остаётся открытой.

Работа по нескольким объектам у клиентов уже идёт - в режиме «делаем по проекту постановления, с расчётом на финальный текст». Принципиальных расхождений с утверждённой формой акта пока не видим. Если появятся - откорректируем.