ADG Оставить заявку
Блог Регуляторика 4 мин чтения

Категорирование КИИ на практике: первый завершённый проект и что нас удивило

Завершили первый проект категорирования КИИ у производственного клиента. Оказалось, половина ИТ-систем изначально не попала в периметр - методология требует глубокого погружения.

Контекст момента

Первые реальные проекты категорирования объектов КИИ по 187-ФЗ в российских компаниях, лето 2018

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

Как мы думали, что будет

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

Реальность оказалась другой.

Что происходит на самом деле

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

Конкретные варианты того, что мы нашли в процессе:

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

По итогу первоначальный список объектов КИИ вырос примерно вдвое относительно того, что клиент считал «своими ИТ-системами» до начала проекта.

Почему методология требует именно такого подхода

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

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

Мы провели несколько совместных рабочих сессий, где за одним столом сидели ИТ-директор, начальник производства, главный технолог и служба безопасности. Без этого аналитика была бы неполной.

Что это значит для процесса

Практические выводы, которые мы несём в следующий проект:

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

Про акт категорирования

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

Именно такой акт потом не стыдно предъявлять ФСТЭК. И именно от него мы будем отталкиваться, когда пойдёт работа по аудиту соответствия требованиям приказа №239.

Следующий проект категорирования уже в работе - другая отрасль, другой масштаб. Посмотрим, насколько картина будет отличаться.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.