КИИ: первый этап - инвентаризация ИС и сопоставление с критическими бизнес-процессами

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

Откуда берётся перечень объектов КИИ

Логика 187-ФЗ такова: объект КИИ - это информационная система, которая обеспечивает критический бизнес-процесс субъекта. Не «важная система», не «дорогая система», а именно та, нарушение работы которой приводит к последствиям из статьи 7: ущерб жизни и здоровью, нарушение функционирования критической инфраструктуры, экономический ущерб и так далее.

Значит, правильный порядок такой:

1. Сначала определяем критические бизнес-процессы.
2. Потом смотрим, какие ИС, АСУ и сети их обеспечивают.
3. Из этого списка ИС и получается перечень кандидатов в объекты КИИ.

Если сделать наоборот - начать со списка систем и потом думать «а вдруг это КИИ?» - получится каша. Мы видели такой подход у одного из заказчиков ещё весной: взяли реестр всего IT-имущества, поставили галочки «наверное критическое» и пошли к руководству утверждать. Руководство ничего не утвердило, потому что непонятно, по какому принципу галочки расставлены.

Как выглядит реальная инвентаризация

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

Первый шаг - интервью с руководством и владельцами процессов. Не с IT-отделом. Именно с теми, кто отвечает за производство, транспортировку, сбыт или другие ключевые функции. Вопросы простые, но ответы даются с трудом:

• Что произойдёт, если этот процесс остановится на сутки? У большинства нет готового ответа. Начинают думать вслух, и это уже полезно.
• Есть ли процессы, остановка которых приведёт к физическому ущербу или ЧС? Здесь обычно называют два-три кандидата - и это ядро для дальнейшей работы.
• Какие процессы регулируются государством и имеют лицензионные или технологические требования к непрерывности? Энергетики сразу вспоминают про диспетчерское управление, транспортники - про системы управления движением.

Результат первого шага - список критических бизнес-процессов с коротким описанием возможных последствий их нарушения. Не роман, буквально таблица: процесс, последствие, к какому виду ущерба из 187-ФЗ это относится.

Сопоставление с информационными системами

Второй шаг - берём каждый критический процесс и спрашиваем IT: «Какие системы это обеспечивают?» Тут начинается самое занимательное.

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

Мы сопоставляем вручную, через интервью и просмотр конфигураций. Для каждой ИС фиксируем:

• Критические бизнес-процессы, которые она обеспечивает (может быть несколько).
• Тип системы - ИС, АСУ, ИТКС, или всё вместе.
• Взаимодействие с другими системами - особенно с внешними сетями и технологическими сегментами.
• Текущее состояние документации - есть/нет/устарела.

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

Что тормозит работу

Основная проблема не техническая. Люди. Владельцы процессов не понимают, зачем это нужно IT-шникам, IT-шники не понимают, зачем процессники лезут в реестр систем. Регуляторный контекст большинству сотрудников среднего звена не близок - это «что-то про безопасность, которое придумали сверху».

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

Где мы сейчас

Первый этап - определение критических бизнес-процессов и составление перечня ИС - занял у нас около трёх недель на объекте среднего размера. Это нормально. Быстрее не получится, если делать честно, а не рисовать красивую таблицу из головы.

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

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