Взаимодействие ИБ и ИТ департаментов при категорировании КИИ: решение конфликтов

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

Регламент передачи данных об IP-адресах и новых системах: пошаговый алгоритм

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

Шаг 1. Триггер — событие в ИТ-инфраструктуре. ИТ-отдел фиксирует одно из следующих событий: ввод в эксплуатацию новой ИС, АСУ или сети; изменение IP-адресов или доменных имён; вывод системы из эксплуатации; существенная модернизация (смена платформы, миграция в облако).

Шаг 2. Уведомление ИБ. В течение 3 рабочих дней с момента события ИТ-отдел направляет в службу ИБ уведомление по утверждённой форме. Форма должна содержать: наименование системы, функциональное назначение, перечень IP-адресов и доменных имён, состав технологического стека, связи с другими системами.

Шаг 3. Оценка ИБ. Служба ИБ в течение 5 рабочих дней определяет: является ли система потенциальным объектом КИИ (по перечням типовых объектов); требуется ли категорирование или пересмотр категории существующего объекта; необходимо ли обновить сведения во ФСТЭК.

Шаг 4. Решение комиссии. Если система признана потенциальным объектом КИИ, вопрос выносится на заседание комиссии по категорированию. Комиссия проводит категорирование в установленные ПП № 127 сроки.

Шаг 5. Обратная связь. Служба ИБ уведомляет ИТ-отдел о результатах оценки и решении комиссии. Если объекту присвоена категория значимости, ИТ-отдел получает перечень мер защиты, которые необходимо реализовать совместно.

SLA между ИБ и ИТ: шаблон внутреннего соглашения

Регламент — это «что делать». Но он не работает без фиксации «в какие сроки» и «какие последствия за нарушение». Для этого нужно внутреннее соглашение об уровне сервиса (SLA) между ИБ и ИТ. Такое соглашение — не стандартная практика для российских организаций, но именно его наличие отличает компании, которые проходят проверки ФСТЭК без замечаний.

Ниже — ключевые параметры, которые должны быть зафиксированы в SLA.

Типичная ошибка: организации фиксируют SLA только «сверху вниз» — обязанности ИТ перед ИБ. Но SLA должно быть двусторонним: ИБ тоже берёт на себя обязательства — например, заблаговременно уведомлять ИТ о планируемой установке СЗИ, проводить совместное тестирование, не блокировать системы без согласования.

Автоматизация обмена данными: как убрать человеческий фактор

Даже самый подробный регламент работает ровно до тех пор, пока люди его выполняют. Единственный способ гарантировать актуальность данных об объектах КИИ — автоматизация. Рассмотрим три уровня зрелости.

Уровень 1: Общий реестр (электронная таблица)

Минимальный вариант для небольших организаций (до 20 объектов КИИ). ИТ и ИБ ведут общий реестр в формате Excel или Google Sheets с обязательными полями: наименование ИС, IP-адреса, домены, дата последнего обновления, статус категорирования. Назначается ответственный за актуализацию. Главный недостаток — зависимость от дисциплины.

Уровень 2: Интеграция через ITSM / Service Desk

ИТ-отдел уже использует систему управления ИТ-услугами (ServiceNow, Jira Service Management, GLPI и др.). В процесс управления изменениями (Change Management) встраивается обязательный чек-бокс: «Изменение затрагивает объект КИИ?» При положительном ответе автоматически создаётся задача на службу ИБ. Это устраняет риск «забыли уведомить».

Уровень 3: SGRC-платформа

Специализированные системы Security Governance, Risk and Compliance (SGRC) автоматически собирают данные об ИТ-активах из CMDB, Zabbix, NetBox, Active Directory. При появлении нового актива или изменении сетевых параметров система автоматически уведомляет ИБ и сопоставляет актив с перечнями типовых объектов КИИ. Это наиболее зрелый подход, который полностью исключает человеческий фактор в процессе передачи данных.

Выбор уровня зависит от масштаба организации и бюджета. Но даже минимальная автоматизация (уровень 1) кратно снижает риск конфликтов: спор «кто должен был предоставить данные» превращается в объективную запись в реестре.

Эскалация и арбитраж: что делать, когда регламент не работает

Даже при наличии регламента и SLA бывают ситуации, когда ИБ и ИТ не могут договориться. Например: ИТ считает, что система не является объектом КИИ, а ИБ настаивает на категорировании. Или ИТ отказывается устанавливать средство защиты, ссылаясь на риск простоя. Для таких случаев необходим механизм эскалации.

Уровень 1: Рабочее совещание. CISO и CIO проводят встречу с привлечением владельца бизнес-процесса. Цель — совместно оценить риски и принять обоснованное решение. В 80% случаев конфликт разрешается на этом уровне, если обе стороны видят полную картину.

Уровень 2: Комиссия по категорированию. Неразрешённые вопросы выносятся на заседание комиссии по категорированию. Решение комиссии фиксируется протоколом и является обязательным для обоих подразделений.

Уровень 3: Решение руководителя организации. Если комиссия не пришла к консенсусу (например, голоса разделились поровну), вопрос выносится на уровень генерального директора или заместителя, ответственного за безопасность КИИ (в соответствии с Указом № 250). Руководитель принимает финальное решение и несёт за него персональную ответственность.

Критическое правило: до момента принятия решения по спорному объекту действует принцип «безопасность по умолчанию» — система рассматривается как потенциальный объект КИИ и к ней применяются базовые меры защиты. Это снижает риск штрафов в случае проверки ФСТЭК до завершения спора.

Чек-лист внедрения: 12 шагов к бесконфликтному взаимодействию

Ниже — практический чек-лист, который мы используем при настройке взаимодействия ИБ и ИТ у клиентов. Его можно взять за основу и адаптировать под специфику организации.

1. Провести стартовую встречу CISO и CIO. Синхронизировать понимание требований 187-ФЗ, ПП № 1762, методики ФСТЭК. Зафиксировать общие цели.
2. Утвердить матрицу RACI. Распределить зоны ответственности по каждой задаче категорирования (используйте таблицу из раздела 4 этой статьи).
3. Разработать и утвердить регламент передачи данных. Зафиксировать триггеры, форматы уведомлений, сроки (см. раздел 5).
4. Подписать внутреннее SLA между ИБ и ИТ. Зафиксировать сроки, ответственных, порядок эскалации (см. раздел 6).
5. Включить чек-бокс «КИИ» в процесс Change Management. Любое изменение в инфраструктуре должно проверяться на влияние на объекты КИИ.
6. Создать общий реестр объектов КИИ. Доступный ИБ и ИТ, с фиксацией IP-адресов, доменов, дат обновления.
7. Назначить ответственного за актуализацию реестра. Конкретный сотрудник, конкретные сроки обновления.
8. Провести совместное обучение. ИТ-специалисты должны понимать, зачем нужны данные для ИБ; ИБ-специалисты должны знать, как работает ИТ-инфраструктура.
9. Настроить автоматизацию. Выбрать уровень в зависимости от зрелости: Excel, ITSM или SGRC.
10. Установить периодичность совместных сверок. Рекомендуем ежеквартально. Оформлять протоколом.
11. Включить взаимодействие по КИИ в KPI обоих подразделений. Пока категорирование не влияет на оценку ИТ-специалистов, оно будет восприниматься как «чужая задача».
12. Проводить ежегодный аудит процесса. Проверять, выполняется ли регламент, актуален ли реестр, все ли объекты КИИ выявлены.

Итог

Конфликт между ИБ и ИТ при категорировании КИИ — это не проблема «плохих людей», а следствие отсутствия системного подхода к взаимодействию. Каждое подразделение выполняет свою функцию, но без формализованных процессов их зоны ответственности пересекаются, а данные теряются на стыках.

Три ключевых инструмента решают проблему: матрица RACI, регламент передачи данных и внутреннее SLA. Вместе они превращают хаотичное взаимодействие в управляемый процесс, где каждый знает свою роль, сроки и последствия бездействия. Автоматизация через SGRC или ITSM закрепляет результат и исключает человеческий фактор.

Начните с малого: проведите совместную встречу CISO и CIO, зафиксируйте текущие болевые точки и утвердите матрицу ответственности. По нашему опыту, организации, которые формализуют взаимодействие ИБ и ИТ, проходят повторное категорирование в среднем на 45% быстрее и с минимальными замечаниями регулятора.

Нужна помощь с выстраиванием взаимодействия ИБ и ИТ при категорировании КИИ? Оставьте заявку — специалисты sertifikat.bz проведут бесплатную экспресс-оценку ваших процессов и помогут разработать регламент, матрицу ответственности и SLA для вашей организации.