На аудите энергетической компании в прошлом году я наткнулся на ситуацию, которую с тех пор вижу на каждом втором объекте: СКУД на подстанции хранил биометрические шаблоны 340 сотрудников. Это одновременно объект КИИ в сфере энергетики и ИСПДн с биометрией. Два закона, два регулятора, два комплекта документов - и ни один не закрыт полностью. Акт категорирования ФСТЭК содержал систему, а политика обработки ПДн вообще не учитывала биометрию. При инциденте компания обязана уведомлять и ГосСОПКА, и Роскомнадзор - с разными сроками, форматами и адресатами. Штрафы по КоАП ст. 13.12.1 за нарушения в области безопасности КИИ (суммы зависят от части статьи - сверяйте с актуальной редакцией КоАП), плюс оборотные штрафы за утечку ПДн по обновлённому 152-ФЗ, плюс уголовка по ст. 274.1 УК РФ - до 10 лет. Мотивация разобраться, как два режима работают вместе, более чем достаточная.
Где ФЗ-187 и ФЗ-152 пересекаются на практике
ФЗ-187 «О безопасности КИИ» и ФЗ-152 «О персональных данных» - формально независимые законы. Первый про устойчивость критической информационной инфраструктуры и защиту от компьютерных атак. Второй - про права граждан на защиту персональных данных и обязанности оператора ПДн. Регуляторы разные: для КИИ - ФСТЭК и ФСБ, для ПДн - Роскомнадзор (общий контроль), ФСТЭК (техническая защита) и ФСБ (криптозащита ПДн, приказ ФСБ №378).Пересечение возникает, когда объект КИИ обрабатывает персональные данные. А это случается почти всегда:
- Энергетика: биллинговые системы хранят данные абонентов, СКУД - биометрию сотрудников
- Здравоохранение: медицинские ИС содержат спецкатегории ПДн (состояние здоровья) и одновременно относятся к КИИ
- Телеком: системы расчётов с абонентами обрабатывают ПДн миллионов субъектов на объектах КИИ в сфере связи
- Финансы: банковские системы - объекты КИИ в кредитно-финансовой сфере с ПДн клиентов
Ключевые различия двух режимов
| Аспект | ФЗ-187 / Приказы ФСТЭК 235, 239 | ФЗ-152 / ПП-1119 / Приказ ФСТЭК 21 |
|---|---|---|
| Объект регулирования | Объект КИИ (ОКИИ) | ИСПДн |
| Классификация | Категория значимости (1-3 или без категории) | Уровень защищённости (УЗ1-УЗ4) |
| Регулятор | ФСТЭК + ФСБ | Роскомнадзор + ФСТЭК |
| Уведомление об инциденте | ГосСОПКА (НКЦКИ) | Роскомнадзор |
| Набор мер защиты | Приказ ФСТЭК №239 | Приказ ФСТЭК №21 |
| Уголовная ответственность | Ст. 274.1 УК РФ (до 10 лет) | Нет (административная) |
| Штрафы | КоАП ст. 13.12.1 (суммы зависят от части статьи и редакции КоАП) | Оборотные штрафы по поправкам 2024 г. |
Выполнение требований ФЗ-187 не освобождает от 152-ФЗ. Даже если приказ ФСТЭК №239 закрывает основную часть технических мер для ИСПДн, остаются правовые обязанности: основания обработки, согласия субъектов, политика обработки ПДн, уведомление Роскомнадзора (ст. 22 ФЗ-152), порядок трансграничной передачи (ст. 12 ФЗ-152).
Категорирование КИИ и обработка персональных данных: последовательность действий
Субъект КИИ проводит категорирование объектов по ПП №127 от 08.02.2018. Параллельно оператор ПДн определяет перечень ИСПДн, типы обрабатываемых данных, актуальные угрозы и уровень защищённости по ПП-1119 (четыре уровня: УЗ1 - наивысший, для спецкатегорий ПДн при угрозах 1-го типа, до УЗ4 - для общедоступных ПДн при угрозах 3-го типа).Первая практическая проблема: один и тот же информационный актив может быть и ОКИИ, и ИСПДн, но описывается в двух разных реестрах, по двум разным методикам. Решение, которое я видел работающим - единый реестр информационных систем в GRC-инструменте (R-Vision, MaxPatrol VM или даже Confluence), где каждая система получает двойную атрибуцию: «является ОКИИ» (категория), «является ИСПДн» (УЗ), «типы ПДн» (общедоступные, биометрические, специальные, иные по классификации из ПП-1119).
Для систем на пересечении обе классификации определяются одновременно. Пример: АСУ ТП электростанции с модулем учёта рабочего времени на основе биометрии - ЗОКИИ 3-й категории плюс ИСПДн с биометрическими ПДн. По ПП-1119, для биометрических ПДн при актуальных угрозах 2-го типа (связанных с НДВ в прикладном ПО) требуется УЗ2, при угрозах 1-го типа - УЗ1 (п. 8–10 ПП-1119). Отсечка по числу субъектов (менее/более 100 000) применяется к иным категориям ПДн, а не к биометрическим. Модель угроз по методике ФСТЭК 2021 года позволяет учитывать и угрозы ЗОКИИ, и угрозы ИСПДн в одном документе.
Что приказ ФСТЭК 239 не перекрывает из требований по ПДн
Приказ №239 устанавливает технические и организационные меры для значимых объектов КИИ. Но ФЗ-152 содержит требования, которые приказ №239 не затрагивает вообще:- Правовые основания обработки (ст. 6 ФЗ-152) - согласие субъекта, договор, требование закона для каждой цели обработки
- Политика обработки ПДн (ст. 18.1 ФЗ-152) - публичный документ на сайте оператора
- Уведомление Роскомнадзора (ст. 22 ФЗ-152) - перед началом обработки, с указанием целей, категорий данных, мер защиты
- Ответственный за организацию обработки ПДн (ст. 22.1 ФЗ-152) - это не тот же человек, что ответственный за безопасность ЗОКИИ по приказу №235
- Оценка вреда субъектам (п. 5 ч. 1 ст. 18.1 ФЗ-152) - отдельная процедура
- Локализация баз данных (ч. 5 ст. 18 ФЗ-152) - первичная запись и хранение ПДн граждан РФ на территории РФ
- Поручение обработки ПДн третьему лицу (ч. 3 ст. 6 ФЗ-152) - договор с обработчиком при передаче ПДн подрядчикам
Двойное уведомление при инциденте на ЗОКИИ с ПДн
Инцидент на системе, которая одновременно ЗОКИИ и ИСПДн, запускает два параллельных процесса уведомления. На практике это самый болезненный момент - SOC-команда в первые часы должна готовить два сообщения разным адресатам.| Действие | Адресат | Срок | Основание |
|---|---|---|---|
| Первичное уведомление о компьютерном инциденте | НКЦКИ (ГосСОПКА) | 3 часа с момента обнаружения инцидента (для всех субъектов КИИ); 24 часа - передача технических сведений | ФЗ-187 ст. 9, Приказ ФСБ №367 от 24.07.2018 (в ред. приказа ФСБ №282 от 27.06.2019) |
| Первичное уведомление об утечке ПДн | Роскомнадзор | 24 часа | ст. 21 ч. 3.1 ФЗ-152 (в ред. Федерального закона №266-ФЗ от 14.07.2022) |
| Результаты внутреннего расследования утечки ПДн (с указанием причин и виновных лиц) | Роскомнадзор | 72 часа с момента выявления инцидента | ст. 21 ч. 3.1 ФЗ-152 (в ред. Федерального закона №266-ФЗ от 14.07.2022) |
| Дополнительные сведения по запросу | ГосСОПКА | Не позднее 48 часов | ПП №43 |
Форматы уведомлений различаются: ГосСОПКА ожидает технический формат (IoC, вектор атаки, затронутые системы), Роскомнадзор - информацию о категориях затронутых ПДн, количестве субъектов, мерах по минимизации последствий.
За взаимодействие с ГосСОПКА отвечает лицо, назначенное по приказу №235. За уведомление РКН - ответственный за организацию обработки ПДн по ст. 22.1 ФЗ-152. Если это разные люди (а в крупных организациях так и должно быть), incident response playbook обязан содержать явную маршрутизацию: кто кому передаёт данные об инциденте, кто подписывает уведомления, кто отвечает на запросы каждого регулятора. Без этой маршрутизации в playbook вы узнаете о проблеме из предписания РКН - проверено.
Совмещение требований ИБ КИИ и ПДн: единая система мер
Приказы ФСТЭК №239 (для ЗОКИИ) и №21 (для ИСПДн) используют схожую структуру мер защиты. Ряд групп совпадает полностью:| Группа мер | Приказ 239 (КИИ) | Приказ 21 (ИСПДн) | Совпадение |
|---|---|---|---|
| Идентификация и аутентификация (ИАФ) | Да | Да | Полное |
| Управление доступом (УПД) | Да | Да | Полное |
| Регистрация событий безопасности (РСБ) | Да | Да | Полное |
| Антивирусная защита (АВЗ) | Да | Да | Полное |
| Межсетевое экранирование (МЭ) | Да | Да | Полное |
| Контроль целостности (ОЦЛ) | Да | Да | Полное |
| Обеспечение доступности (ОДТ) | Да | Частично | КИИ строже |
| Реагирование на инциденты (ИНЦ) | Да | Нет отдельной группы | Только КИИ |
| Управление конфигурациями (УКФ) | Да | Нет отдельной группы | Только КИИ |
| Управление обновлениями (ОПО) | Да | Нет отдельной группы | Только КИИ |
Для ЗОКИИ, обрабатывающего ПДн, алгоритм прямой: берём базовый набор мер из приказа №239 для соответствующей категории значимости, дополняем мерами из приказа №21, которые не покрыты. Дополнение на практике минимальное - приказ №239 содержит 17 групп мер, приказ №21 - 15, при этом 12-13 пересекаются.
Средства защиты информации: как выбрать класс
Класс СЗИ для ЗОКИИ определяется п. 31 приказа ФСТЭК №239 (требования к СрЗИ и классы защиты - приказ ФСТЭК №76 от 02.06.2020 и соответствующие профили защиты): ЗОКИИ 1-й категории - класс 4, 2-й - класс 5, 3-й - класс 6. Для ИСПДн класс СЗИ определяется по уровню защищённости: УЗ1–УЗ4 - классы СЗИ различаются по типам средств (СВТ, СЗИ от НСД, МЭ, СОВ и др.), конкретные требования - п. 12 приказа ФСТЭК №21. Проще говоря: чем выше УЗ, тем выше требуемый класс СЗИ.Если ЗОКИИ 3-й категории обрабатывает ПДн с УЗ2, потребуется СЗИ не ниже класса 5 - берётся более строгое требование из двух. Одно средство, один сертификат, но класс определяется по максимуму. Это экономит бюджет: не нужно покупать два отдельных МЭ или два антивируса для одного и того же сегмента сети. На практике именно здесь экономия ощутимая.
Detection-чеклист для SOC: алерты под двойной комплаенс
SOC-команде, обслуживающей инфраструктуру с объектами на пересечении КИИ и ПДн, нужно учитывать оба контекста при настройке корреляционных правил. Ключевое: в SIEM (MaxPatrol SIEM, KUMA, RuSIEM или другом) активы, попадающие под оба режима, должны быть помечены тегами «ЗОКИИ» и «ИСПДн» одновременно. Это позволяет при каждом алерте автоматически определять, какие notification workflow запускать.Приоритетные сценарии
- Несанкционированный доступ к ИСПДн на ЗОКИИ. Попытки входа с использованием скомпрометированных учёток - Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation / Defense Evasion). Корреляция: множественные неуспешные входы, затем успешный вход с нетипичного IP или в нерабочее время, пользователь не входит в группу авторизованных для обработки ПДн. Алерт с двойной маркировкой.
- Эксфильтрация данных из ИСПДн на ЗОКИИ. Вывод информации по нетипичным каналам - Exfiltration Over C2 Channel (T1041, Exfiltration). Правило: объём исходящего трафика из сегмента с ЗОКИИ/ИСПДн превышает baseline в N раз. Дополнительно: обращение к БД с ПДн из необычного контекста - Data from Local System (T1005, Collection).
- Эксплуатация публичного сервиса. Атака на веб-интерфейс, который и объект КИИ, и обрабатывает ПДн (личные кабинеты энергосбытовых компаний, порталы пациентов) - Exploit Public-Facing Application (T1190, Initial Access).
- Компрометация удалённого доступа. Несанкционированный вход через VPN/RDP к ЗОКИИ - External Remote Services (T1133, Persistence / Initial Access). Правило: подключение к сегменту ЗОКИИ из неавторизованного пула IP.
- Шифрование/уничтожение данных на ЗОКИИ с ИСПДн - Data Encrypted for Impact (T1486, Impact) / Data Destruction (T1485, Impact). Это одновременно компьютерный инцидент по ФЗ-187 и блокирование/уничтожение ПДн по ФЗ-152.
- Отключение СЗИ - Impair Defenses (T1562, Defense Evasion). На ЗОКИИ - событие для ГосСОПКА. Если затронута защита ИСПДн - нарушение требований по безопасности ПДн.
Код:
rule dual_scope_unauthorized_access {
condition:
event.source IN asset_list["ЗОКИИ_с_ПДн"] AND
event.type == "authentication_success" AND
(event.src_ip NOT IN whitelist["admin_ips"] OR
event.time NOT IN schedule["working_hours"]) AND
event.user NOT IN group["pd_authorized"]
action:
alert(severity="high",
tags=["КИИ_инцидент", "ПДн_НСД"],
notify=["soc_l2", "kii_responsible", "pd_responsible"])
}Практический чеклист: совмещение требований КИИ и ПДн
За три года категорирования объектов КИИ в энергетике и телекоме я не встречал организаций, которые с первого раза правильно увязали оба режима. Типичная картина: отдел ИБ добросовестно закрывает приказ №239, юристы параллельно пишут политику обработки ПДн - и два этих мира не пересекаются до первого инцидента. SOC видит алерт, запускает playbook по КИИ, уведомляет ГосСОПКА в срок. А через неделю прилетает запрос из Роскомнадзора: почему не уведомили об утечке? Потому что в SIEM актив не был помечен как ИСПДн, и playbook не содержал ветки уведомления РКН.
Проблема не в сложности законов - оба написаны прямолинейно. Проблема в организационной разобщённости: КИИ ведёт одна команда, ПДн - другая, а точки пересечения никто не отслеживает. В GRC-реестре у большинства организаций нет поля «ИСПДн» напротив ОКИИ. А если поле есть - не заполнено, потому что за него никто не отвечает. Рабочий подход один: единый реестр активов с двойной атрибуцией, один ответственный за актуальность обоих атрибутов и автоматическая маршрутизация инцидентов в SIEM по тегам. Не два параллельных комплаенс-процесса, а один процесс с двумя выходами. Кто продолжает вести КИИ и ПДн как отдельные проекты с раздельными командами - будет узнавать о пересечениях из предписаний регуляторов. На codeby.net есть тред, где коллеги разбирают конкретные коллизии между приказами 239 и 21 в привязке к реальным конфигурациям SIEM - если выстраиваете единый комплаенс-процесс, есть смысл сверить подход.
