ФСТЭК опубликовала проект методики оценки уровня зрелости деятельности в области технической защиты информации в информационных системах и безопасности значимых объектов КИИ. Если коротко, регулятор предлагает считать не только наличие средств защиты и документов, а зрелость процессов: кто управляет защитой, как организация ищет угрозы, обновляет системы, закрывает уязвимости, контролирует удаленный доступ, работает с подрядчиками и применяет ИИ.
Главная перемена не в самой формуле, а в логике контроля. Организации все чаще придется доказывать, что защита работает в эксплуатации, а не только красиво выглядит перед аттестацией. Проект методики связан с новой регуляторной рамкой ФСТЭК и показателем ПЗИ, который в материалах ведомства и отраслевых разборах описывается как показатель зрелости защиты информации. Подробнее о публикации проекта написал SecPost, а сам проект размещен на сайте ФСТЭК.
Материал предназначен для легального и ответственного применения в корпоративной ИБ, аудите и управлении рисками. Читателю нужно соблюдать законы своей страны, особенно России. Описанные подходы нельзя применять для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного обхода ограничений.
Как работает оценка зрелости
Оценка зрелости похожа на попытку заменить вопрос «у вас стоит средство защиты?» вопросом «вы умеете постоянно управлять защитой?». В первом случае организация показывает документы, схемы, акты внедрения и перечень средств. Во втором проверяющий смотрит, встроена ли защита в регулярную работу: кто отвечает за процесс, как часто проверяются настройки, где фиксируются уязвимости, кто принимает риск, как контролируются изменения и что происходит после инцидента.
Проект методики предлагает оценивать зрелость по 21 направлению. В новостном разборе перечислены области от организации управления защитой до защиты при применении ИИ. В отраслевых обзорах отдельно упоминаются управление уязвимостями, управление обновлениями, защита удаленного и беспроводного доступа, привилегированный доступ, контроль конфигураций и работа с информацией ограниченного доступа.
Шкала выглядит как лестница. Нулевой уровень означает, что зрелость фактически отсутствует. Начальный уровень показывает, что отдельные действия уже выполняются, но процесс еще слабый. Системный уровень предполагает повторяемость и закрепленные правила. Контролируемый уровень требует измеримости и регулярного контроля. Верифицируемый уровень означает, что организация может подтвердить зрелость доказательствами, а не только словами ответственного сотрудника.
| Уровень | Что обычно означает на практике |
|---|---|
| Нулевой | Процесс не описан, ответственные и доказательства отсутствуют или случайны. |
| Начальный | Отдельные меры есть, но организация зависит от ручного контроля и конкретных людей. |
| Системный | Правила закреплены, процесс повторяется, результаты можно проверить по журналам и документам. |
| Контролируемый | Организация измеряет процесс, видит отклонения, управляет сроками и ответственными. |
| Верифицируемый | Вывод подтверждается независимыми следами: отчетами, журналами, проверками, метриками и результатами тестов. |
Формула в таких методиках нужна не для красоты. Весовые коэффициенты позволяют не считать все требования одинаковыми. Например, формальная политика управления уязвимостями и реальный процесс закрытия критических уязвимостей за измеримый срок не должны весить одинаково. Хорошая методика должна отличать «бумага лежит в папке» от «процесс меняет поведение ИТ и бизнеса».
Где польза видна быстро
Самая понятная польза появится у организаций, где ИБ годами держалась на героизме нескольких специалистов. Методика заставляет разложить работу по направлениям и увидеть провалы, которые обычно всплывают только после инцидента. Например, средства защиты куплены, но инвентаризация активов устарела. Сканер уязвимостей установлен, но исправления не доходят до промышленной среды. Политика удаленного доступа написана, но подрядчики подключаются через исключения, которые никто не пересматривает.
Для руководителя зрелость удобна тем, что переводит разговор с языка «нам нужен еще один продукт» на язык управляемых рисков. Становится видно, почему SOC не помогает без нормального учета активов, почему DLP мало что дает без классификации данных и почему управление привилегированным доступом бессмысленно, если локальные администраторы размножаются быстрее, чем служба ИБ успевает их проверять.
Для подрядчиков методика может стать фильтром допуска. Заказчик сможет требовать не только лицензию и красивую презентацию, а подтвержденный уровень зрелости работ по защите информации. Для операторов КИИ и государственных структур такой подход особенно чувствителен: подрядчик с незрелыми процессами создает риск не снаружи, а прямо внутри защищаемого контура.
Где начнутся проблемы
Первая проблема, кадры. Внешнюю оценку, по оценкам экспертов из новости, смогут проводить лицензиаты ФСТЭК и специалисты с профильной квалификацией. Даже если организаций с лицензиями много, это не означает, что рынок сразу получит достаточно сильных аудиторов. Формально лицензиат может быть в реестре, но зрелую оценку процессов должны вести люди, которые понимают эксплуатацию, КИИ, управление уязвимостями, модели угроз, журналы событий, архитектуру доступа и реальную работу ИТ.
Вторая проблема, цена и очереди. Если методика станет массовым требованием, спрос на аудиторов вырастет быстрее, чем качество предложения. Слабый рынок почти наверняка начнет продавать шаблонные отчеты. Формально отчет будет, но пользы для защиты не появится. Такой риск уже знаком по аттестациям, когда заказчик иногда покупает не результат, а возможность закрыть пункт проверки.
Третья проблема, ИИ. Включение защиты при применении искусственного интеллекта выглядит своевременно, но рынок пока не договорился даже о базовом наборе проверок. Нужно оценивать источники данных, контроль доступа к моделям, риск утечек через запросы, журналирование, целостность модели, проверку ответов и границы применения. Но обещание «проверить ИИ по методике» легко превращается в имитацию, если аудитор не понимает, где заканчивается обычная ИБ и начинается специфический риск модели.
Четвертая проблема, сравнимость результатов. Две организации могут получить похожий балл, но находиться в разном состоянии. Одна честно показала слабые места, другая аккуратно подготовила витрину перед проверкой. Методика снижает произвол, но не отменяет профессиональное суждение аудитора. Чем больше веса получат качественные признаки, тем важнее станут доказательства: журналы, заявки, протоколы разборов, результаты тестов, фактические сроки устранения проблем.
Какие мифы лучше убрать сразу
Первый миф: высокий уровень зрелости равен защищенности от атак. Нет. Зрелость показывает, насколько управляемо организация строит защиту. Атаки все равно возможны, особенно через цепочки поставок, ошибки подрядчиков, неизвестные уязвимости и человеческий фактор. Но зрелая организация быстрее замечает сбой, понимает владельца риска и восстанавливается не по памяти одного администратора, а по процессу.
Второй миф: методика нужна только КИИ. Проект действительно фокусируется на информационных системах и значимых объектах КИИ, но логика зрелости полезна шире. Любая крупная компания с персональными данными, подрядчиками, удаленным доступом и критичными сервисами сталкивается с теми же процессными провалами. Разница в том, что для регулируемых организаций оценка может стать обязательной частью контроля, а для остальных останется инструментом управления.
Третий миф: внутренней самооценки хватит. Самооценка полезна как подготовка, особенно до внешнего аудита. Но самооценка почти всегда мягче независимой проверки. Внутренняя команда знает, почему процесс «временно не работает», и легко принимает объяснения, которые внешний аудитор не примет. Лучше использовать самооценку как черновик, а не как финальный доказательный документ.
Четвертый миф: зрелость можно купить продуктами. Нельзя. Сканер, SIEM, PAM, WAF или система управления конфигурациями помогают поднять зрелость только при нормальной эксплуатации. Если алерты никто не разбирает, исключения не пересматриваются, учетные записи подрядчиков живут годами, а обновления ставятся по настроению владельца системы, набор продуктов не превращается в зрелый процесс.
Что делать организации уже сейчас
Ждать финальной редакции методики пассивно невыгодно. Разумный первый шаг, провести внутреннюю инвентаризацию по тем направлениям, которые уже понятны: управление защитой, угрозы, конфигурации, уязвимости, обновления, удаленный доступ, привилегии, мобильные устройства, подрядчики, мониторинг и реагирование. Не нужно сразу писать толстый отчет. Достаточно честной таблицы: процесс есть или нет, кто владелец, какие доказательства можно показать, какие метрики реально собираются.
Второй шаг, проверить доказательства. Для зрелости важны не заявления, а следы работы. Если команда говорит, что управляет уязвимостями, должны быть результаты сканирования, реестр исключений, сроки исправления, владельцы систем, решения о принятии риска и история закрытия задач. Если организация контролирует удаленный доступ, нужны перечень пользователей, правила выдачи доступа, журнал подключений, пересмотр прав и отдельный порядок для подрядчиков.
Третий шаг, отделить регуляторный минимум от реальной защиты. Методика поможет пройти проверку только тогда, когда организация не превращает оценку в отдельный проект «для ФСТЭК». Самый опасный сценарий, создать параллельную бумажную систему, которая живет рядом с настоящей ИТ-эксплуатацией. Аудитор уйдет, документы останутся, но уязвимости, забытые права и слепые зоны мониторинга никуда не исчезнут.
Кого в первую очередь затронет методика ФСТЭК?
В первую очередь операторов информационных систем, значимых объектов КИИ, операторов ИСПДн, подрядчиков и заказчиков работ по защите информации. Для нерегулируемых компаний методика тоже может стать ориентиром, но юридическая обязанность зависит от конкретного статуса организации и применимых требований.
ПЗИ заменит аттестацию?
Нет. Показатель зрелости не выглядит как простая замена аттестации. Скорее ФСТЭК добавляет слой оценки процессов поверх привычной проверки мер защиты. Аттестация отвечает на вопрос соответствия системы требованиям, а зрелость показывает, насколько организация умеет поддерживать защиту в работе.
Можно ли провести оценку своими силами?
Проект допускает внутреннюю оценку, но внешняя проверка будет восприниматься как более объективная. Самооценка полезна для подготовки: организация заранее найдет слабые места, соберет доказательства и поймет, где внешний аудит может ударить по срокам и бюджету.
Почему в методике появился ИИ?
ИИ уже применяют в государственных и корпоративных системах, а риски не ограничиваются обычной защитой сервера. Нужно контролировать данные, запросы, ответы модели, доступ, целостность, скрытые каналы утечки и границы применения. Проблема в том, что практические критерии оценки ИИ пока формируются, поэтому первые проверки могут идти неравномерно.
Высокая зрелость гарантирует отсутствие инцидентов?
Нет. Высокая зрелость снижает вероятность хаоса, но не отменяет уязвимости, ошибки людей и атаки через подрядчиков. Сильная зрелость означает, что организация быстрее обнаружит проблему, назначит владельца, примет решение и подтвердит действия фактами.
Что проверить до внешнего аудита?
Нужно проверить владельцев процессов, актуальность реестров, журналы событий, сроки устранения уязвимостей, пересмотр прав доступа, правила работы подрядчиков, контроль изменений, результаты учений и разборов инцидентов. Если доказательств нет, процесс для аудитора почти не существует.
Методика ФСТЭК не сделает защиту сильнее сама по себе. Сильнее станут те организации, которые используют оценку как повод навести порядок в процессах, а не как еще одну папку для проверки. Начинать лучше с простой инвентаризации: где есть владелец, где есть доказательства, где процесс держится на устных договоренностях. Именно такие места обычно ломаются первыми.
