Что делать после категорирования объекта КИИ: требования 187-ФЗ

Если компания относится к субъектам КИИ, это ещё не означает, что у неё автоматически есть значимые объекты КИИ.

Значимым объект становится только после того, как ему присвоили I, II или III категорию значимости, сведения проверил регулятор, а сам объект включили в реестр. С этого момента компании нужно выстраивать постоянный режим управления объектом: контролировать его границы, доступы, изменения и способность к восстановлению.

Разберёмся, как проходит категорирование и что именно меняется в работе компании после.

Субъект КИИ — это статус компании в рамках регулирования.

Объект КИИ — информационная система, информационно-телекоммуникационная сеть или автоматизированная система управления, принадлежащая субъекту КИИ на законном основании.

Значимый объект КИИ — объект, которому присвоена одна из трёх категорий значимости и который включён в реестр значимых объектов КИИ.

Как проходит категорирование объекта КИИ

Категорирование проводится комиссией, которую создаёт сам субъект КИИ.

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

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

Если объект обслуживают внешние подрядчики, их тоже стоит подключить к разбору. Они могут знать детали эксплуатации, интеграций, сопровождения и взаимодействия систем.

После этого комиссия собирает исходные данные по объекту.

Необходимо понять:

• что делает объект и какие процессы поддерживает;
• кто зависит от его работы;
• из каких компонентов он состоит;
• с какими системами и сетями взаимодействует;
• какие данные через него проходят;
• какие угрозы и сценарии нарушения работы возможны.

Важно рассматривать как саму систему, так и её окружение. Бизнес-сервис может зависеть от СХД, платформы виртуализации, каналов связи, Active Directory и т.д. Отказ любого из этих компонентов может нарушить процесс.

Также необходимо учитывать перечни типовых отраслевых объектов и отраслевые особенности, установленные для конкретной сферы деятельности. Для банка, медицинской организации, промышленного предприятия и оператора связи они будут разными.

Как объекту присваивают категорию значимости

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

• Пострадают ли люди?
• Остановится ли услуга?
• Будут ли финансовые потери?
• Нарушится ли производство?
• Появятся ли риски для транспорта, связи, энергетики или других критичных сфер?

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

По результатам объект может получить первую, вторую или третью категорию значимости.

• Первая — самый высокий уровень значимости.
• Вторая — средний уровень.
• Третья — минимальный уровень среди значимых объектов.

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

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

Что меняется после присвоения категории значимости

С присвоением категории значимости у объекта появляется новый статус, а у компании — новые задачи, зоны ответственности и требования к управлению этой системой.

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

Важно разделять два уровня обязанностей. 

1. Со статусом субъекта КИИ уже связано информирование о компьютерных атаках и инцидентах и взаимодействие с ГосСОПКА.
2. После появления значимого объекта добавляются специальные требования к его системе безопасности, защите, восстановлению и реагированию на инциденты.

Первый необходимый шаг — анализ текущего состояния. Здесь проверяют, как объект работает сейчас:

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

После аудита становится понятно, какие части контура нужно проверить и привести в порядок.

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

Разберём по порядку.

1. Контур объекта и зоны ответственности

Сначала необходимо зафиксировать границы значимого объекта: какие серверы, базы данных, сети, средства защиты, площадки входят в его состав. Это нужно, чтобы обозначить зону контроля.

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

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

• Должен быть владелец со стороны бизнеса: тот, кто отвечает за процесс, который держится на этой системе, и понимает последствия её остановки.
• Отдельно должен быть определён технический владелец — команда или подразделение, которое отвечает за работу инфраструктуры, доступность, обновления, резервное копирование, мониторинг и восстановление.
• Со стороны информационной безопасности должны быть понятны требования к защите, порядок реагирования на инциденты, контроль доступов и взаимодействие с ГосСОПКА.
• На уровне руководства необходимо определить, кто принимает решения по рискам, бюджету, срокам и изменениям в контуре.

2. Доступы

После присвоения категории нужно понимать, кто имеет доступ к объекту, на каком основании, с какими правами и как эти права пересматриваются.

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

Особенно внимательно смотрим на:

• административные доступы;
• удалённые подключения;
• учётные записи подрядчиков;
• сервисные учётные записи;
• общие учётные записи;
• права сотрудников, которые сменили должность;
• доступы, которые выдавали временно, но забыли отозвать.

Отдельная зона риска — доступ подрядчиков, действия должны быть ограничены, контролируемы и доступны для последующего разбора.

3. Изменения и зависимости

Работа значимого объекта зависит от его окружения: платформы, сети, интеграций, доступов и подрядчиков. Любые изменения в этом контуре нужно планировать, согласовывать, фиксировать и проверять после внедрения.

Для значимого объекта управление изменениями должно отвечать как минимум на пять вопросов:

• что именно меняется;
• какие компоненты и процессы это затронет;
• кто согласовал изменение;
• как проверить результат;
• как вернуться к предыдущему состоянию, если что-то пойдёт не так.

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

4. Мониторинг и реагирование

Команда должна понимать, что происходит с системой в обычном режиме и что меняется при сбое, атаке или ошибке в работе.

Для этого нужны мониторинг и журналирование.

• Мониторинг показывает состояние объекта: доступность сервисов, ошибки, нагрузку, работу каналов связи, баз данных, серверов, интеграций и других компонентов, от которых зависит система.
• Журналы помогают восстановить картину событий: кто подключался, какие действия выполнял, какие ошибки возникали, какие изменения вносились, когда началось отклонение и какие системы оно затронуло.

Без мониторинга и журналов команда дольше разбирается в инциденте: где началась проблема, какие системы затронуты, были ли подозрительные действия и что менялось перед сбоем.

5. Резервное копирование и восстановление

Подробнее о построении стратегии восстановления мы рассказывали в статье. Для значимого объекта КИИ эта тема становится ещё важнее. 

Одна из задач системы безопасности значимого объекта, прямо закреплённых в № 187-ФЗ, — восстановление его функционирования, в том числе за счёт создания и хранения резервных копий.

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

Компания должна понимать:

• какие данные и компоненты попадают в резервное копирование;
• где хранятся копии;
• защищены ли они от удаления, повреждения и шифрования;
• кто запускает восстановление;
• какие системы поднимаются первыми;
• сколько времени занимает возврат объекта в работу;
• какой объём данных допустимо потерять;
• проверялся ли этот сценарий на практике.

Если текущая схема не выдерживает проверку, возникает инфраструктурная задача: усилить резервирование, пересмотреть хранение копий, подготовить порядок переключения, проверить DR-сценарий или доработать архитектуру восстановления. Архитектуру нужно проектировать с учётом изоляции, неизменяемости копий и риска отказа основной площадки.

6. Актуальность сведений и пересмотр категории

Компания должна следить, чтобы сведения по значимому объекту оставались актуальными. Если объект изменился, прежняя оценка может уже не отражать реальную картину.

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

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

Итого

Присвоение категории значимости — начало нового режима управления объектом.

Значимый объект КИИ становится частью живого контура, где должны совпадать:

• описание объекта в документах;
• его реальная работа;
• действия команды при изменении, сбое или инциденте.

Если хотя бы один из этих уровней существует отдельно, появляется разрыв. На бумаге объект защищён, а на практике у компании нет полного перечня зависимостей, актуальных доступов, проверенного плана реагирования или возможности восстановить систему в установленный срок.

Главный вопрос после категорирования: «Сможет ли объект продолжить работу или восстановиться, когда произойдёт реальный инцидент?»

Если после категорирования у вас остались вопросы по инфраструктуре, резервному копированию, DR-плану или репликации, заполните форму.

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