Уровни зрелости кибербезопасности (CMMC 2.0, Министерство обороны США)

«У нас есть антивирус» — не ответ на вопрос о зрелости кибербезопасности, а в лучшем случае один из десятков элементов. CMMC (Cybersecurity Maturity Model Certification) — программа Министерства обороны США, которая превращает разговор о защите информации в конкретную и проверяемую лестницу: какие требования обязательны для обычной контрактной информации, какие — для контролируемой несекретной информации и какие — для самых чувствительных программ. Для оборонных подрядчиков США это регуляторное требование, для остальных — ясный образец того, как выглядит «базовая цифровая гигиена» и как отличается от серьёзной защиты.

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

Важное предупреждение о статусе. Ниже описаны требования и сроки программы по состоянию на 20 сентября 2026 года: 13 июля 2026 года Министерство обороны (в текущих документах — «Department of War») приостановило переход ко второму этапу внедрения и начало 60-дневный пересмотр программы, итоги которого на дату подготовки текста не опубликованы. Для решений о сертификации сверяйтесь с актуальными публикациями Министерства и вашего контрактного офицера. Для компаний вне США CMMC не обязателен: полезны структура уровней и логика доказательств, а формальные требования вашей страны и отрасли определяются местным регулированием (в России, например, требованиями о защите персональных данных и приказами ФСТЭК — их следует уточнять у профильных специалистов).

Происхождение и исследовательская база

Программа выросла из проблемы цепочек поставок: чувствительная информация Министерства обороны хранится не только в его системах, но и в сетях сотен тысяч подрядчиков и субподрядчиков, среди которых много малых компаний. До CMMC подрядчики обязывались соблюдать требования NIST SP 800-171 (публикация Национального института стандартов и технологий США о защите контролируемой несекретной информации в негосударственных системах; пункт DFARS 252.204-7012), но соблюдение декларировалось самими компаниями и почти не проверялось. Первую версию модели (CMMC 1.0) Министерство обороны опубликовало в 2020 году: пять уровней, включая оценку «зрелости процессов» и обязательную стороннюю сертификацию. Версия 2.0, представленная в ноябре 2021 года, упростила модель: три уровня, привязка требований непосредственно к публикациям NIST, отказ от отдельной шкалы «зрелости процессов» и допущение самооценки на нижних уровнях.

Правовое оформление заняло годы. Правило программы (32 CFR Part 170) было опубликовано 15 октября 2024 года и вступило в силу 16 декабря 2024 года; правило о договорных условиях (изменения DFARS, 48 CFR) опубликовано 10 сентября 2025 года и вступило в силу 10 ноября 2025 года. Внедрение планировалось в четыре этапа: первый (с 10 ноября 2025 года) — самооценки уровней 1 и 2, второй — через год, с требованием сторонней сертификации уровня 2 для соответствующих контрактов, далее — расширение и уровень 3. 13 июля 2026 года второй этап и все последующие вехи были приостановлены «до дальнейших указаний»; во время приостановки действуют требования первого этапа, пункт DFARS 252.204-7012, NIST SP 800-171 и отчётность по самооценке. В заявлении руководства Министерства названы причины: непомерные затраты на соответствие, острая нехватка сторонних оценщиков и сложные регуляторные сроки, вынуждающие малые компании уходить из оборонных контрактов.

Уровни модели, по документам программы. Уровень 1 (Foundational, «базовый») — 15 базовых требований безопасности из пункта FAR 52.204-21 для защиты «контрактной информации федерального заказчика» (FCI): контроль доступа, идентификация и аутентификация, защита носителей, физическая защита, защита систем и целостность (обновления, защита от вредоносного кода); проверяется ежегодной самооценкой с подтверждением руководителя. Уровень 2 (Advanced, «продвинутый») — 110 требований NIST SP 800-171 (редакция Rev. 2) в 14 семействах для защиты контролируемой несекретной информации (CUI); для части контрактов допускается самооценка, для приоритетных — оценка сертифицированной сторонней организацией (C3PAO) раз в три года с ежегодным подтверждением. Уровень 3 (Expert, «экспертный») — уровень 2 плюс 24 избранных усиленных требования NIST SP 800-172 для программ с наивысшим приоритетом; оценка проводится государственными экспертами (DIBCAC).

Документированные кейсы

Открытых независимых исследований эффективности CMMC пока мало: программа введена недавно и ещё внедряется. Поэтому ниже — три документированных примера, объясняющих, зачем нужны базовые требования, и оценка затрат от самого регулятора. Оговорка: примеры иллюстрируют логику уровней, но не доказывают эффект CMMC.

Кейс 1. Colonial Pipeline (2021): один пароль без второго фактора

7 мая 2021 года вымогательское ПО группы DarkSide остановило операции Colonial Pipeline, крупнейшего топливного трубопровода восточного побережья США; последовали перебои с топливом и паническая скупка в ряде штатов. Как сообщил Сенату США на слушаниях в июне 2021 года руководитель компании Джозеф Блаунт, доступ был получен через устаревшую систему удалённого доступа (VPN), защищённую паролем без многофакторной аутентификации; пароль, по сообщениям, оказался в утечке данных из другого источника. Компания заплатила выкуп — 75 биткоинов (около 4,4 млн долларов на тот момент), значительную часть которого позднее удалось вернуть Министерству юстиции США.

Как читать через CMMC. Многофакторная аутентификация, учёт учётных записей и отключение устаревших способов доступа — не «продвинутые» меры, а базовые: они относятся к семействам «идентификация и аутентификация» и «контроль доступа», которые есть уже в первом и втором уровнях. Оговорка: Colonial Pipeline — коммерческая компания вне оборонных контрактов, и нельзя утверждать, что CMMC предотвратил бы эту атаку; кейс показывает цену пропущенной базовой меры.

Кейс 2. Target (2013): подрядчик как путь внутрь

Злоумышленники проникли в сеть американского ритейлера Target 15 ноября 2013 года, использовав учётные данные подрядчика — компании Fazio Mechanical Services, обслуживавшей системы отопления и охлаждения и имевшей удалённый доступ для выставления счетов. Как сообщалось, сотрудник подрядчика получил фишинговое письмо с вредоносной программой. В итоге, по заявлениям компании, затронуты около 40 млн платёжных карт и данные до 70 млн человек; в 2017 году Target урегулировал претензии генеральных прокуроров штатов, выплатив 18,5 млн долларов — на тот момент крупнейшее многоштатное урегулирование по утечке данных.

Как читать. Безопасность организации определяется и безопасностью тех, у кого есть доступ: именно поэтому в CMMC требования передаются по цепочке субподрядчиков (flow-down), а уровень подрядчика должен соответствовать типу информации, которую он получает. Для любой компании отсюда практический вывод: учитывать доступы подрядчиков в реестре, ограничивать их сегментацией и проверять их гигиену.

Кейс 3. Оценка затрат самим регулятором и причины приостановки

В регуляторном анализе воздействия к правилу CMMC Министерство обороны оценило число затронутых организаций — 337 968, из них 229 818 малых. Для малого предприятия расчётная стоимость сторонней сертификации уровня 2 и подтверждения составила около 101 752 долларов (около 104 670 долларов за три года с ежегодными подтверждениями); при этом регулятор оговаривает, что это модельные оценки, а реальные цены услуг сторонних оценщиков определит рынок. Расчётная нагрузка и дефицит оценщиков стали одним из доводов в решении о приостановке второго этапа в июле 2026 года.

Как читать. Требования должны соответствовать риску и возможностям: слишком тяжёлая сертификация вытесняет малых подрядчиков, слишком лёгкая не защищает данные. Для вашей компании это аргумент в пользу поэтапного подхода: сначала базовая гигиена, затем усиление по мере роста риска. Оговорка: цифры — оценки регулятора на момент публикации правила и не гарантируют реальных затрат.

Ключевые идеи и принципы

1. Принцип: три уровня — по типу информации

   Уровень определяется не размером компании, а тем, какую информацию она обрабатывает: обычная контрактная информация федерального заказчика (FCI) — первый уровень; контролируемая несекретная информация (CUI) — второй; самые чувствительные программы — третий. Для вашей организации это переносится на классификацию данных: какие данные публичные, какие внутренние, какие — персональные, коммерческие тайны, критичные для бизнеса; уровень защиты задаётся классом данных.

2. Принцип: каждый уровень — конкретный проверяемый список требований

   В отличие от моделей зрелости с качественными описаниями, CMMC даёт перечень практик, для каждой из которых есть цели оценки и доказательства. Диагностика превращается в вопрос «выполнено или нет, и чем это подтверждается»: настроена ли многофакторная аутентификация для всех удалённых доступов, есть ли перечень устройств, тестируется ли восстановление из резервной копии. Такие вопросы полезнее общих «мы серьёзно относимся к безопасности».

3. Принцип: сначала граница, потом меры

   Прежде чем оценивать выполнение требований, нужно определить границу оценки — какие системы, люди, помещения и подрядчики работают с защищаемой информацией. Чем меньше и чётче граница (например, выделенная защищённая среда для защищаемых данных), тем дешевле и проще защита. Типовая ошибка — оценивать «всю компанию» или, наоборот, забыть о личных устройствах, облачных сервисах и подрядчиках.

4. Принцип: доказательства и документы

   Оценщик проверяет не намерения, а свидетельства: план безопасности системы (System Security Plan), описания процессов, конфигурации, журналы, записи обучения, результаты сканирования. Программа CMMC для уровня 2 использует также оценку по методике Министерства обороны для NIST SP 800-171: баллы вычитаются за невыполненные требования, максимум — 110; результат сообщается в систему SPRS. Для условной сертификации допускается ограниченный «план действий и этапов» (POA&M) при выполнении порога по баллам и закрытии остатка в установленный срок (по правилу программы — 180 дней). Для вашей компании это модель: реестр невыполненных мер с владельцами и сроками закрытия.

5. Принцип: защита соответствует риску

   Не каждой компании нужен третий уровень; большинству достаточно базовой гигиены и системной работы над рисками. Смысл модели — соответствие защиты реальному риску, а не максимальная защита ради самой защиты. Риск оценивается через ценность данных, вероятность и последствия инцидента; см. аудит информационной безопасности и систему менеджмента информационной безопасности ISO 27001.

6. Принцип: безопасность — непрерывный процесс

   Уровень не присваивается навсегда: программа предусматривает ежегодные подтверждения соответствия руководителем и повторную оценку раз в три года. В организации это означает регулярный пересмотр: обновления, аудит прав доступа, проверка резервных копий, обучение сотрудников, учения по реагированию (см. управление инцидентами (ITIL)).

7. Принцип: метрики кибергигиены

   Метрики привязываются к мерам: доля учётных записей и удалённых доступов с многофакторной аутентификацией; среднее время установки критичных обновлений; доля устройств из реестра, охваченных управлением и защитой; доля успешных тестовых восстановлений из резервных копий; доля сотрудников, прошедших обучение, и доля кликов по учебным фишинговым письмам; число учётных записей без владельца и подрядчиков с открытым доступом; время обнаружения и реагирования на инцидент; число невыполненных мер и средний возраст записей в плане устранения. Показатели полезны, если по ним принимаются решения, а не только строится отчёт.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: считают, что маленькой компании кибербезопасность не нужна.

   «Мы никому не интересны» — заблуждение: небольшие компании часто становятся целью именно из-за слабой защиты, а также как путь к крупным партнёрам (Target).

   Как избежать

   внедрить хотя бы базовую гигиену (уровень 1), даже без формальной сертификации, и учитывать требования партнёров.

2. Ошибка 2: покупают дорогие инструменты без базовой гигиены.

   Внедряется продвинутое решение для обнаружения угроз, а многофакторная аутентификация, обновления и резервные копии не закрыты (Colonial Pipeline).

   Как избежать

   сначала закрыть базовые меры (доступ, обновления, копии, обучение), затем усиливать защиту.

3. Ошибка 3: считают безопасность разовым проектом.

   Меры внедряются один раз и не пересматриваются, хотя угрозы, сотрудники и системы постоянно меняются.

   Как избежать

   заложить регулярный пересмотр: обновления, аудит прав, проверка копий, обучение, учения.

4. Ошибка 4: не определяют границу защищаемой среды.

   Меры внедряют «везде» или забывают о личных устройствах, облачных сервисах и подрядчиках; оценка становится бесконечной или пропускает риски.

   Как избежать

   определить, какие данные, системы, люди и подрядчики входят в границу; по возможности выделить защищённую среду для критичных данных.

5. Ошибка 5: не учитывают подрядчиков.

   Подрядчик с удалённым доступом остаётся самым слабым звеном (Target).

   Как избежать

   вести реестр доступов подрядчиков, давать минимально необходимые права и проверять их защиту; передавать требования по цепочке.

6. Ошибка 6: оформляют документы, но не выполняют меры.

   Политики написаны «для оценщика», но не внедрены; при инциденте выясняется, что резервные копии не восстанавливаются, а учётных записей уволенных сотрудников не отключали.

   Как избежать

   проверять меры на практике: тест восстановления, учебный инцидент, аудит прав доступа; хранить доказательства.

7. Ошибка 7: не планируют устранение недостатков.

   Недостатки выявлены, но без владельцев и сроков; список растёт.

   Как избежать

   вести реестр невыполненных мер: владелец, срок, риск, промежуточные компенсирующие меры.

План внедрения

1. Неделя 1: классификация данных и граница

   Определить, какие данные защищаются (контрактные, персональные, коммерческие тайны), где они хранятся и кто имеет доступ, включая подрядчиков; определить границу защищаемой среды и целевой уровень защиты.

2. Неделя 2: пароли, доступ и многофакторная аутентификация

   Внедрить многофакторную аутентификацию для удалённого и привилегированного доступа, отключить устаревшие способы доступа, провести аудит учётных записей и прав, удалить неиспользуемые.

3. Неделя 3: обновления, резервные копии и защита рабочих станций

   Убедиться, что программное обеспечение регулярно обновляется, есть защита от вредоносного кода, ведутся резервные копии критичных данных и хотя бы раз проверено восстановление.

4. Неделя 4: мониторинг и план реагирования

   Настроить оповещение о подозрительной активности (например, необычных входах), определить ответственных за инцидент и порядок действий при утечке или взломе, провести учебное упражнение.

5. Далее: реестр недостатков и регулярный пересмотр

   Вести реестр невыполненных мер с владельцами и сроками; пересматривать практики не реже раза в полгода и при смене поставщиков, систем и состава сотрудников; для официальных требований — сверяться с актуальным статусом программы.

Как реализовать этот план с помощью фрейма «Уровни зрелости кибербезопасности (CMMC 2.0)» в OrgDevTools

Фрейм «CMMC 2.0» в OrgDevTools помогает выбрать нужный уровень защиты и увидеть разрыв до него в цифрах. Требование засчитывается только тогда, когда оно подтверждено документами. Уровни идут строго по порядку: следующий не засчитывается, пока предыдущий не закрыт полностью. Фрейм бесплатный, это тренажёр для самооценки, а не сертификация. Во фрейме четыре вкладки.

Книги по теме

NIST SP 800-171 Rev. 2 — «Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations». Официальная публикация NIST с 110 требованиями безопасности в 14 семействах, лежащими в основе уровня 2 CMMC.

NIST SP 800-172 — «Enhanced Security Requirements for Protecting Controlled Unclassified Information». Усиленные требования, из которых выбраны 24 требования уровня 3.

Министерство обороны США — «CMMC Model Overview, Version 2.0» (2021). Описание уровней, практик и способов оценки; свободно доступно.

Министерство обороны США — «CMMC Assessment Guides» (уровни 1 и 2). Руководства оценщиков: цели оценки и примеры доказательств.