Проект ФСТЭК №166998 меняет логику защиты значимых объектов критической информационной инфраструктуры. Смысл не в том, чтобы добавить еще одну бумагу к уже существующему комплекту документов, а в том, чтобы заставить субъектов КИИ регулярно измерять состояние защиты, показывать результаты регулятору и быстрее реагировать на провалы.
Если приказ примут, изменения должны вступить в силу 1 сентября 2026 года. По опубликованным материалам, ФСТЭК предлагает ввести два регулярных измерения: показатель защищенности не реже одного раза в шесть месяцев и уровень зрелости защиты не реже одного р>аза в два года. Карточка проекта размещена на regulation.gov.ru, краткое описание изменений также приводит «Кодекс».
Что именно пытается изменить ФСТЭК
Сейчас многие организации воспринимают защиту КИИ как проект с датой окончания: провели категорирование, внедрили набор м, получили документы, периодически обновляют регламенты. Проект ФСТЭК двигает модель в сторону циклического контроля. Организация должна не просто заявить, что меры защиты внедрены, а регулярно проверять, насколько меры работают.
Показатель защищенности отвечает за практическое состояние защиты. В такую оценку обычно попадают технические и организационные признаки: закрыты ли обязательные меры, работают ли средства защиты, есть ли контроль доступа, журналирование, резервное копирование, мониторинг, разбор инцидентов и устранение выявленных проблем. Главный смысл показателя прост: защита должна измеряться не один раз перед проверкой, а каждые полгода.
Уровень зрелости смотрит глубже. ФСТЭК интересует не только наличие средств защиты, но и способность организации управлять безопасностью как процессом. Есть ли ответственные, бюджет, контроль со стороны руководства, регулярное обновление модели угроз, обучение сотрудников, управление подрядчиками, проверка фактической реализации мер. Такая оценка хуже укладывается в галочку «средство стоит», зато лучше показывает, развалится ли защита при смене администратора, аварии, атаке или конфликте с подрядчиком.
Где польза будет видна на практике
Главная польза появится у организаций, где ИБ уже работает как управляемая функция. Полугодовой расчет показателя защищенности поможет быстрее увидеть деградацию: отключенный агент, устаревшие правила межсетевого экрана, пропавшие журналы, просроченные резервные копии, незакрытые уязвимости, неработающий контроль привилегированных учетных записей. Без регулярной проверки такие проблемы часто всплывают после инцидента или перед внешним аудитом.
Второй плюс связан с руководством. Когда ФСТЭК требует считать показатель и передавать результаты, службе ИБ проще разговаривать с бизнесом не языком страха, а языком измеримых разрывов. Не «нам нужен еще один продукт», а «по критичному объекту показатель просел из-за отсутствия журналирования действий администраторов и резервного канала восстановления».
Третий эффект касается подрядчиков. Проект отдельно обращает внимание на техническую поддержку разработчиков, запрет удаленного доступа сторонних лиц к системам защиты и контроль действий пользователей при работе с критичными объектами. Для КИИ сторонний доступ давно остается слабым местом: подрядчик получает доверенный маршрут внутрь периметра, а организация не всегда видит, кто именно подключился, что изменил и как долго сохранялись права.
Где начнутся проблемы
Первая проблема — формальный расчет ради отчета. Если организация сведет показатель защищенности к таблице, которую раз в полгода заполняют по старым актам, регулятор получит цифры, но безопасность почти не изменится. Реальная оценка требует живых данных: журналов, результатов сканирования, статуса средств защиты, сведений об инцидентах, проверок восстановления и фактических прав доступа.
Вторая проблема — независимость проверки. Слабая схема выглядит так: один и тот же отдел внедряет меры, сам собирает данные, сам оценивает результат и сам пишет, что все в порядке. При таком подходе показатель быстро превращается в самооценку без веса. Нормальная схема требует хотя бы внутреннего разделения ролей, а для крупных субъектов КИИ — периодической внешней проверки.
Третья проблема — нагрузка на небольшие организации. Полугодовой цикл звучит разумно для зрелого банка, телеком-оператора или промышленной группы, но может стать тяжелым для регионального предприятия с маленькой ИБ-командой. Риск очевиден: вместо улучшения защиты люди начнут обслуживать отчетность. Поэтому автоматизация сбора данных станет не удобством, а условием выживания процесса.
| Изменение | Практический смысл | Риск формального подхода |
|---|---|---|
| Показатель защищенности раз в 6 месяцев | Регулярно видно, где защита просела | Таблица заполняется по старым документам |
| Уровень зрелости раз в 2 года | Проверяется управляемость ИБ, а не только наличие средств | Процессы описаны в регламентах, но не работают |
| Отчетность перед ФСТЭК | Руководство не может игнорировать результат | Организация начинает оптимизировать отчет, а не защиту |
| Контроль подрядчиков | Снижается риск доверенного удаленного доступа | Доступ закрывают на бумаге, но оставляют обходные каналы |
Какие мифы лучше сразу отбросить
Первый миф: новый показатель сам повысит безопасность. Не повысит. Метрика помогает увидеть проблему, но не чинит сегментацию, не закрывает уязвимости и не настраивает журналирование. Если у организации нет владельцев процессов, бюджета и дисциплины изменений, показатель лишь покажет хроническую болезнь.
Второй миф: зрелость ИБ равна количеству купленных средств защиты. Можно купить SIEM, DLP, PAM, сканер уязвимостей и все равно жить в хаосе, если никто не разбирает события, не обновляет правила, не контролирует администраторов и не проверяет восстановление. Зрелость начинается там, где меры работают повторяемо и проверяемо.
Третий миф: запрет удаленного доступа подрядчиков решит проблему цепочки поставок. Запрет помогает только при ясных правилах исключений, учете сессий, многофакторной аутентификации, записи действий и отзыве прав после работ. Иначе удаленный доступ просто переедет в менее видимые каналы.
Материал предназначен для легального и ответственного использования. При работе с КИИ, средствами защиты, удаленным доступом и проверками безопасности нужно соблюдать законодательство России и внутренние правила организации. Инструкции и выводы нельзя применять для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного обхода ограничений.
Что делать субъектам КИИ уже сейчас
Рациональный шаг — провести пробный расчет до вступления приказа в силу. Не ради красивой цифры, а ради карты дыр. Нужно взять один значимый объект, собрать фактические данные по мерам защиты, проверить журналы, доступы, резервные копии, поддержку средств защиты, каналы подрядчиков и реакцию на инциденты. После такого прогона станет видно, какие данные организация вообще умеет собирать автоматически, а какие живут только в письмах и Excel.
Отдельно стоит пересмотреть договоры с подрядчиками. В договорах должны появиться правила доступа, требования к учетным записям, журналированию, срокам отзыва прав, уведомлению об инцидентах и ответственности за действия сотрудников подрядчика. Без договорной базы технический контроль быстро упрется в фразу «мы всегда так подключались».
Проект ФСТЭК №166998 не стоит читать как очередной бюрократический слой. Логика документа жестче: субъект КИИ должен доказать, что защита живет между проверками. Где есть мониторинг, инвентаризация, контроль изменений и нормальная работа с инцидентами, новые требования встроятся в процесс. Где безопасность держится на папке документов и одном перегруженном администраторе, полугодовая оценка быстро покажет неприятную правду.
Каковы сроки категорирования объектов КИИ?
После принятия решения о создании объекта КИИ либо выявления существующего объекта субъект КИИ должен провести категорирование и направить сведения во ФСТЭК России в сроки, установленные Федеральным законом №187-ФЗ и подзаконными актами. На практике затягивать процесс рискованно, поскольку отсутствие категорирования значимого объекта может привести к претензиям регулятора.
Что такое категорирование объектов КИИ?
Категорирование — процедура оценки возможных последствий нарушения работы объекта КИИ. Субъект анализирует, какой ущерб может возникнуть для государства, экономики, безопасности, обороны, общественного порядка, жизни и здоровья граждан. По результатам объекту присваивается одна из категорий значимости либо принимается решение об отсутствии категории.
Каковы требования к объектам КИИ?
Для значимых объектов КИИ законодательство требует реализовать организационные и технические меры защиты информации, провести оценку соответствия, контролировать доступ пользователей, обеспечивать регистрацию событий безопасности, резервное копирование, реагирование на инциденты и выполнение требований ФСТЭК России. Конкретный набор мер зависит от категории значимости объекта.
В какой срок субъект КИИ должен направить в ФСТЭК России сведения об объекте КИИ в случае их изменения?
При изменении сведений о значимом объекте КИИ субъект обязан направить обновленную информацию во ФСТЭК России в течение 10 рабочих дней со дня изменения таких сведений. Речь может идти, например, об изменении характеристик объекта, состава систем или иных данных, ранее направленных регулятору.
Показатель защищенности и уровень зрелости — одно и то же?
Нет. Показатель защищенности отражает текущее состояние реализации мер защиты, а уровень зрелости показывает способность организации системно управлять информационной безопасностью и поддерживать защиту в рабочем состоянии на протяжении длительного времени.
Нужно ли ждать вступления приказа в силу?
Ждать не стоит. Даже если отдельные формулировки проекта изменятся, общий вектор уже очевиден: ФСТЭК требует регулярной оценки защищенности и подтверждения эффективности мер безопасности. Подготовиться к таким проверкам проще заранее.
Самый распространенный риск при внедрении новых требований?
Попытка превратить оценку защищенности в формальную отчетность. В таком случае организация получает красивые показатели на бумаге, но не замечает реальные проблемы с доступами, журналированием, резервным копированием, подрядчиками и мониторингом событий безопасности.
