Категорирование КИИ на практике: первый завершённый проект и что нас удивило
Завершили первый проект категорирования КИИ у производственного клиента. Оказалось, половина ИТ-систем изначально не попала в периметр - методология требует глубокого погружения.
Первые реальные проекты категорирования объектов КИИ по 187-ФЗ в российских компаниях, лето 2018
Первый завершённый проект категорирования по 187-ФЗ закрыт. Клиент - производственное предприятие, не из самых маленьких. Работу делали по всем правилам: комиссия, перечень объектов, показатели критичности, акт категорирования. По итогу можем сказать прямо: самое трудоёмкое в этой работе - не заполнение форм и не согласования, а предшествующий шаг, который в регламентах описан одной фразой «идентификация объектов КИИ».
Как мы думали, что будет
Наивная картина в начале проекта выглядела примерно так: приходим, клиент показывает список своих ИТ-систем, мы смотрим какие из них участвуют в критических процессах, присваиваем категории, оформляем документы. Всё это укладывалось в разумные сроки.
Реальность оказалась другой.
Что происходит на самом деле
Когда мы начали погружаться в процессы предприятия, выяснилось, что треть систем, которые реально участвуют в производственных процессах, в первоначальном списке ИТ-систем вообще не фигурировала. Не потому что клиент скрывал - просто никто не думал о них как о «ИТ-системах» в привычном смысле. Часть из них висела на балансе производственных подразделений, часть считалась «инфраструктурой» и никогда не включалась ни в какие ИТ-реестры.
Конкретные варианты того, что мы нашли в процессе:
- Системы мониторинга и диспетчеризации производственного цеха - в ИТ-отделе о них знали поверхностно, потому что поддерживал их подрядчик напрямую с производством.
- Промышленные контроллеры с сетевым интерфейсом, у которых был выход во внутреннюю сеть - формально не ИТ-системы, но фактически часть критической цепочки.
- Системы управления зданием - видеонаблюдение, СКУД, управление климатом в серверных. На первый взгляд далеко от производства, но при глубоком анализе несколько из них оказались связаны с технологическим процессом.
- Несколько унаследованных баз данных, которые сопровождала другая команда и которые никто формально не «регистрировал» как отдельные системы.
По итогу первоначальный список объектов КИИ вырос примерно вдвое относительно того, что клиент считал «своими ИТ-системами» до начала проекта.
Почему методология требует именно такого подхода
Постановление Правительства №127 описывает категорирование через критические процессы - сначала определяешь процессы, нарушение которых может привести к ущербу, а потом уже смотришь, какие системы эти процессы обеспечивают. Это не «смотри на список ИТ-систем и выбирай важные». Это «смотри на технологическую цепочку и спрашивай, что сломается, если вот этот участок встанет».
Разница принципиальная. ИТ-отдел обычно думает в категориях инфраструктуры. Производство думает в категориях непрерывности выпуска продукции. Категорирование КИИ требует обоих взглядов одновременно, и организовать их совместную работу - отдельная задача.
Мы провели несколько совместных рабочих сессий, где за одним столом сидели ИТ-директор, начальник производства, главный технолог и служба безопасности. Без этого аналитика была бы неполной.
Что это значит для процесса
Практические выводы, которые мы несём в следующий проект:
- Начинать с процессов, а не с систем. Берёшь схему технологического процесса и идёшь по ней, спрашивая: что автоматизирует вот этот шаг? Потом уже сопоставляешь с ИТ-реестром.
- ИТ-реестр клиента - отправная точка, не финальная картина. Почти наверняка там будут дыры. Закладывать на это время.
- Интервью с производственными подразделениями обязательны. ИТ-отдел не знает всего. Это нормально, не претензия - просто факт.
- Подрядчики и аутсорсеры. Если часть систем поддерживается внешними командами, нужен отдельный сбор информации - подрядчик не пойдёт сам к комиссии по категорированию.
Про акт категорирования
Когда периметр был зафиксирован, дальнейшая работа пошла значительно проще. Оценка показателей по каждому объекту, расчёт ущерба, присвоение категорий - это уже процедурная работа, пусть и объёмная. Акт категорирования в итоге получился большой, но аргументированный. У каждой системы - своё обоснование: почему включена, почему такая категория, на какой критический процесс влияет.
Именно такой акт потом не стыдно предъявлять ФСТЭК. И именно от него мы будем отталкиваться, когда пойдёт работа по аудиту соответствия требованиям приказа №239.
Следующий проект категорирования уже в работе - другая отрасль, другой масштаб. Посмотрим, насколько картина будет отличаться.