По данным Gartner (Q4 2023, 303 руководителя ИБ), 63% организаций в мире уже частично или полностью внедрили стратегию Zero Trust. При этом у большинства она покрывает половину среды или менее - и снижает четверть общего риска или менее. Внедрение идёт, а измеримого эффекта нет. Проблема не в технологиях - проблема в отсутствии системной оценки зрелости. За последние два года я провёл gap-анализ по Zero Trust для шести организаций с гибридной инфраструктурой (Active Directory + Azure AD + on-prem), и в каждом случае первый вопрос от руководства звучал одинаково: «Где мы сейчас, куда двигаемся и сколько это стоит?» Без фреймворка оценки зрелости на этот вопрос не ответить.
Зачем измерять зрелость Zero Trust и какой фреймворк выбрать
Внедрение Zero Trust - не проект с дедлайном. NIST SP 800-207 (Section 7) говорит прямо: миграция к ZTA должна быть путешествием, а не одномоментной заменой инфраструктуры. Без оценки текущего состояния организация теряет три вещи:- Baseline для измерения прогресса - нельзя доказать улучшение, если не зафиксирована отправная точка.
- Приоритизацию инвестиций - без понимания, какой столп отстаёт критически, бюджет размазывается ровным слоем и не даёт видимого результата.
- Язык для общения с руководством - фраза «мы на уровне Traditional в идентичности и Initial в сетях» понятна совету директоров. «Нам нужно поставить ещё один NGFW» - нет.
CISA Zero Trust Maturity Model v2.0 - модель зрелости с четырьмя уровнями
CISA ZTMM v2.0 (апрель 2023) - наиболее структурированный инструмент для самооценки. Модель отражает семь постулатов Zero Trust из NIST SP 800-207 и организует их вокруг пяти столпов.
Пять столпов и три сквозные функции
Столпы CISA ZTMM: Identity, Devices, Networks, Applications and Workloads, Data. Плюс три сквозные функции, пронизывающие каждый столп:- Visibility and Analytics - наблюдаемость и аналитика
- Automation and Orchestration - автоматизация и оркестрация
- Governance - управление политиками и соответствие требованиям
Четыре уровня зрелости: от Traditional до Optimal
Каждый столп оценивается по четырём уровням:| Уровень | Характеристика | Что это значит на практике |
|---|---|---|
| Traditional | Ручные процессы, статичные политики | Учётные записи управляются вручную, MFA не покрывает все системы |
| Initial | Частичная автоматизация, начальная интеграция | MFA развёрнута для критичных систем, есть базовый IdP |
| Advanced | Централизованное управление, cross-pillar интеграция | Динамические политики на основе контекста, микросегментация |
| Optimal | Полная автоматизация, непрерывная верификация | Автоматическая реакция на аномалии, real-time адаптация политик |
В версии 2.0 добавлены функции Data Categorization, Data Availability и Secure Application Development and Deployment Workflow - критерии движения к immutable workloads, что соответствует требованиям OMB M-22-09 (https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf).
Практический результат: 24 крупнейших федеральных агентства (CFO Act agencies) к сентябрю 2024 года достигли «high 90 percent range» по начальным целям Zero Trust. USDA развернула FIDO2 для ~40 000 пользователей. GSA получила 29,8 млн долларов из Technology Modernization Fund и построила SASE-архитектуру с фокусом на три столпа: пользователи, устройства, сети.
По данным CISA ZTA Implementation Report (январь 2025), столп Data оказался самым проблемным - ему выделялось меньше ресурсов, а без эффективной стратегии данных общие цели ZTA недостижимы. Запомните эту цифру - она пригодится при приоритизации бюджета.
NIST SP 800-207 - архитектурные принципы и план миграции
NIST SP 800-207 (август 2020) - не модель зрелости в чистом виде, а архитектурное руководство. Документ определяет, что такое Zero Trust Architecture и из каких логических компонентов она состоит. По данным CyberArk, NIST SP 800-207 фокусируется на стратегиях и компонентах внедрения Zero Trust, делая акцент на защите ресурсов через непрерывную верификацию и строгий контроль доступа по принципу наименьших привилегий.
Семь постулатов Zero Trust по NIST
Постулаты из NIST SP 800-207 формируют систему координат для любого фреймворка оценки:- Все источники данных и вычислительные сервисы - ресурсы.
- Вся коммуникация защищена, независимо от расположения в сети.
- Доступ к ресурсам выдаётся на основе сессии с минимальными привилегиями.
- Доступ определяется динамической политикой (кто запрашивает, с какого устройства, откуда, когда).
- Организация непрерывно мониторит безопасность и целостность всех активов.
- Аутентификация и авторизация динамичны и строго применяются до предоставления доступа.
- Организация собирает максимум информации об активах, сетевой инфраструктуре и коммуникациях для улучшения защиты.
Три архитектурных компонента и шаги миграции
NIST определяет три компонента ZTA: Policy Engine (движок политик), Policy Administrator (администратор политик) и Policy Enforcement Point (точка применения политик). CyberArk подчёркивает, что NIST рекомендует вводить trust algorithm, который строится на наблюдаемых данных и уточняется через ленту threat intelligence. Оценка доверия может рассчитываться однократно или динамически меняться на основе поведенческих паттернов.Section 7.3 описывает семь шагов миграции к ZTA в существующей инфраструктуре - от инвентаризации активов до пилотного развёртывания и расширения. Документ вендорно-нейтрален и адаптируется к гибридным средам.
Microsoft Zero Trust Model - шесть столпов и Secure Score
Microsoft Zero Trust Model - вендорная модель, которая отличается от CISA и NIST привязкой к конкретным продуктам и встроенным инструментом измерения (Microsoft Secure Score). Для организаций с инфраструктурой на Azure AD (Entra ID), Microsoft 365, Intune - это наиболее операционно доступный фреймворк.
Шесть столпов Microsoft и их отличие от CISA
Microsoft выделяет шесть столпов: Identities, Devices, Applications, Data, Infrastructure, Networks. Различие с CISA: Microsoft выделяет Infrastructure в отдельный столп (виртуальные машины, контейнеры, serverless), тогда как CISA объединяет приложения и нагрузки. У CISA есть три сквозные функции (Visibility, Automation, Governance), которых у Microsoft в явном виде нет - они растворены в продуктовых возможностях (Azure Monitor, Azure Policy, Microsoft Sentinel).Microsoft Secure Score как инструмент измерения
Microsoft Secure Score - числовая метрика (0–100%), которая оценивает покрытие рекомендуемых контролей безопасности. Secure Score показывает конкретные действия: «включите MFA для всех администраторов» (+10 баллов), «настройте Conditional Access для legacy-протоколов» (+5 баллов). Прогресс измерим в реальном времени - и, что критично, визуализируем для руководства.Ограничение: Secure Score охватывает только Microsoft-стек. Если в организации параллельно живут on-prem GNU/Linux-серверы, сетевое оборудование Cisco или NGFW UserGate - их зрелость Secure Score не покажет. Для гибридных сред нужен комбинированный подход: Secure Score для облачной части + CISA ZTMM для общей картины.
Сравнение трёх фреймворков оценки зрелости Zero Trust
| Критерий | CISA ZTMM v2.0 | NIST SP 800-207 | Microsoft ZT Model |
|---|---|---|---|
| Тип документа | Модель зрелости | Архитектурное руководство | Вендорная модель + инструменты |
| Столпы / компоненты | 5 столпов + 3 сквозных функции | 7 постулатов, 3 компонента | 6 столпов |
| Уровни зрелости | 4 (Traditional -> Optimal) | Нет явных уровней | Secure Score (0-100%) |
| Целевая аудитория | Федеральные агентства, адаптируемо для бизнеса | Любые организации | Организации с Microsoft-стеком |
| Инструмент измерения | Self-assessment по матрице столпов | Gap-анализ по постулатам | Microsoft Secure Score (автоматический) |
| Регуляторная привязка | OMB M-22-09, M-24-14 | Executive Order 14028 | SOC 2, ISO 27001 (через Compliance Manager) |
| Вендорная нейтральность | Да | Да | Нет (Microsoft-стек) |
| Покрытие on-prem | Полное | Полное | Частичное (через Azure Arc) |
| Дорожная карта миграции | Встроена (четыре уровня) | Section 7.3 (7 шагов) | Рекомендации по продуктам |
| Преимущество | Готовая шкала для отчётности | Архитектурная глубина | Автоматическое измерение |
| Ограничение | Требует ручной адаптации | Нет числовых метрик | Вендорный lock-in |
Когда какой фреймворк выбрать
CISA ZTMM - если нужно регулярно отчитываться перед руководством о прогрессе. Четыре уровня дают понятную шкалу: «мы были Traditional, стали Initial, цель - Advanced за 18 месяцев».NIST SP 800-207 - если организация только начинает путь к Zero Trust и нужна архитектурная основа. Документ отвечает на вопрос «что строить», но не «где мы сейчас».
Microsoft ZT Model - если 70%+ инфраструктуры на Microsoft-стеке и нужны автоматические метрики. Secure Score обновляется в реальном времени и снимает проблему ручного аудита.
Оптимальная комбинация для гибридной среды: NIST SP 800-207 как архитектурный фундамент + CISA ZTMM для самооценки и отчётности + Microsoft Secure Score для автоматического мониторинга Microsoft-сегмента.
Zero Trust метрики прогресса - что измерять для отчёта руководству
Фреймворк без метрик - декларация. Метрики без фреймворка - набор цифр без контекста. Ниже - конкретные метрики, которые я использую при подготовке отчётов для CISO и бюджетных комитетов.
Столп Identity (Идентичность):
- Процент учётных записей с MFA (цель: 100% для привилегированных, 95%+ для всех)
- Количество orphaned accounts (учётные записи без владельца)
- Среднее время деактивации уволенного сотрудника (цель: менее 4 часов)
- Покрытие PAM для привилегированных учётных записей
Столп Devices (Устройства):
- Процент устройств с актуальным EDR-агентом
- Процент устройств, соответствующих baseline-конфигурации
- Среднее время обнаружения несоответствия compliance policy
- Процент микросегментированных workloads
- Количество lateral movement path-ов (можно измерить через BloodHound или аналоги)
- Процент трафика, проходящего через Policy Enforcement Point
Столп Applications and Data:
- Процент приложений с SSO-интеграцией
- Процент данных с автоматической классификацией по чувствительности
- Количество приложений с динамическими политиками доступа
Сквозные метрики:
- Среднее время обнаружения аномалии (MTTD)
- Процент автоматизированных реакций на инциденты (vs ручных)
- Покрытие аудита: процент ресурсов с централизованным логированием
Обоснование бюджета Zero Trust - от технических метрик к финансовым аргументам
Совет директоров не читает матрицы CISA. CISO, который приходит с запросом «нам нужно перейти с Traditional на Initial в столпе Identity», получит встречный вопрос: «Сколько это стоит и что будет, если не делать?»
Формула стоимости инцидента vs стоимости контроля
Базовый аргумент строится на сопоставлении:Стоимость инцидента (ALE) = Вероятность инцидента × Средний ущерб
Стоимость контроля = Капитальные затраты + Операционные затраты за период
Пример для столпа Identity: организация без MFA на привилегированных учётных записях. Вероятность компрометации через Valid Accounts (T1078) или pass-the-hash/pass-the-ticket (T1550) - по данным вашей отраслевой статистики инцидентов или актуарных оценок страховщика. Средний ущерб от компрометации привилегированного доступа доходит до десятков миллионов рублей (штрафы, простой, восстановление, репутация). Развёртывание MFA с FIDO2-токенами на 500 пользователей - несколько миллионов рублей единоразово + поддержка.
Формат презентации для бюджетного комитета:
| Контроль | Текущий уровень CISA | Целевой уровень | Стоимость внедрения | Снижение риска |
|---|---|---|---|---|
| MFA для всех пользователей | Traditional | Initial | Зависит от масштаба | Закрывает T1078, T1621 |
| Микросегментация критичных сегментов | Traditional | Advanced | Зависит от инфраструктуры | Закрывает T1550 (pass-the-hash/pass-the-ticket) |
| Автоматическая классификация данных | Traditional | Initial | По результатам пилота | Закрывает gap в столпе Data |
| PAM для привилегированных учётных записей | Initial | Advanced | По количеству учётных записей | Закрывает T1078, T1556 |
Тут есть нюанс: руководство воспринимает не абсолютные цифры, а соотношение. Если стоимость контроля - 5–10% от потенциального ущерба, обоснование проходит легко. Если 50% - придётся копать глубже.
Привязка к регуляторным требованиям
Для российских организаций дополнительный аргумент - соответствие ФЗ-187 (безопасность КИИ), где ФСТЭК надзирает за выполнением требований по обеспечению безопасности значимых объектов КИИ. Контроли Zero Trust (управление доступом, аудит, минимальные привилегии) напрямую маппятся на требования приказов ФСТЭК. Контроль AC-1 (Access Control Policy) из NIST SP 800-53 Rev 5 требует разработки, документирования и распространения политики управления доступом - это фундамент столпа Identity. Контроль IA-1 (Identification and Authentication) закрывает требования к MFA и непрерывной верификации.Аналогично, требования ФЗ-152 к защите персональных данных и приказ ФСБ №378 (меры криптозащиты ПДн) создают регуляторную основу для обоснования инвестиций в столп Data.
Регуляторный аргумент на практике срабатывает быстрее вероятностного: «мы обязаны это сделать по закону» бьёт «есть 15% шанс инцидента» в любом бюджетном комитете.
Чеклист самооценки зрелости Zero Trust
Готовый чеклист для первичного gap-анализа. Формат: вопрос -> уровень по CISA ZTMM. Передайте ответственному за ИБ и заполните по каждому столпу.Identity (Идентичность):
- MFA развёрнута для 100% привилегированных учётных записей - Да/Нет
- MFA развёрнута для 95%+ всех пользователей - Да/Нет
- Есть единый IdP (Identity Provider) с федерацией учётных данных - Да/Нет
- Orphaned accounts выявляются и деактивируются автоматически - Да/Нет
- PAM-решение внедрено для управления привилегированным доступом - Да/Нет
- Политики доступа учитывают контекст (устройство, геолокация, время) - Да/Нет
- Все корпоративные устройства зарегистрированы в системе MDM/UEM - Да/Нет
- EDR-агент установлен на 95%+ устройств - Да/Нет
- Compliance-политики устройств проверяются перед предоставлением доступа - Да/Нет
- BYOD-устройства изолированы от критичных сегментов - Да/Нет
- Критичные сегменты сети микросегментированы - Да/Нет
- Весь трафик между сегментами проходит через NGFW/Policy Enforcement Point - Да/Нет
- DNS-трафик мониторится и фильтруется - Да/Нет
- Legacy-протоколы (LLMNR, NBT-NS, WPAD) отключены - Да/Нет
- Все веб-приложения интегрированы с SSO - Да/Нет
- Доступ к приложениям выдаётся на основе per-session проверки - Да/Нет
- Есть процесс secure development lifecycle (SDL) для внутренних приложений - Да/Нет
- Данные классифицированы по уровням чувствительности - Да/Нет
- Шифрование at-rest и in-transit применяется ко всем критичным данным - Да/Нет
- Есть DLP-политики для предотвращения утечек - Да/Нет
- Централизованный SIEM собирает логи со всех критичных систем - Да/Нет
- Есть автоматизированные playbook-и реагирования (SOAR) - Да/Нет
- Политики безопасности версионируются и пересматриваются ежеквартально - Да/Нет
Типичные ошибки при оценке зрелости
Оценка зрелости Zero Trust - не разовое упражнение для аудиторов. Это операционный процесс, который повторяется ежеквартально. OMB M-24-14 (июль 2024) обязал федеральные агентства предоставить обновлённые ZT-планы с текущими и целевыми уровнями зрелости по каждому столпу для высокоценных активов к концу FY2026. Частный сектор формально не обязан - но организации, которые делают это добровольно, получают преимущество в переговорах со страховщиками, регуляторами и партнёрами.
Большинство организаций подходят к Zero Trust как к проекту: есть начало, есть конец, есть бюджет. Мой опыт говорит обратное - это операционная модель, как финансовый учёт или управление рисками. Никто не говорит «мы внедрили бухгалтерию, проект завершён». Но именно так звучат презентации вендоров, продающих «Zero Trust из коробки».
Вторая проблема, которую редко проговаривают вслух: ни один фреймворк сам по себе не закрывает весь спектр задач. CISA ZTMM хорош для самооценки, но не говорит, какую конкретно технологию ставить. NIST SP 800-207 даёт архитектурную глубину, но не даёт числовых метрик для совета директоров. Microsoft Secure Score даёт числа, но только для своего стека. Я видел организации, которые отчитывались о Secure Score 85%, при этом имея полностью открытый on-prem сегмент с flat network и domain admin без MFA. Формальная метрика создавала ложное чувство безопасности.
Работающий подход - комбинация: NIST как архитектурная основа, CISA ZTMM как шкала для отчётности, Secure Score как автоматический мониторинг облачного сегмента. И ручной gap-анализ для всего, что не покрывается ни одним из трёх. Чеклист из этой статьи - отправная точка, но не финиш. Финиш наступает, когда каждый столп имеет назначенного владельца, утверждённый бюджет и квартальный review с измеримыми метриками перед CISO. Всё остальное - PowerPoint.
Последнее редактирование модератором:
