Согласно недавнему исследованию, для 40% предприятий рост за счет слияний, поглощений и стратегических партнерств является главным приоритетом в 2026 году.
Каждое поглощение в одночасье добавляет поверхность атаки, которую приобретающая организация не проектировала, не инвентаризировала и не понимает в полной мере. Непрерывное управление рисками (CTEM) в масштабах предприятия должно учитывать поверхность атаки, которая появляется без предупреждения.
CTEM для 100 активов и CTEM для 100 000 активов — это принципиально разные операционные задачи. Пять этапов: определение области охвата (Scoping), обнаружение (Discovery), приоритизация (Prioritization), валидация (Validation) и мобилизация (Mobilization) остаются прежними. Модель управления, стек инструментов, требования соответствия и сложность мобилизации — нет.
Руководители служб безопасности предприятий понимают эту концепцию и должны внедрять ее в дочерних компаниях, объектах M&A, изолированных инженерных командах и глобальных регуляторных средах. То, что работает в таком масштабе, отличается от того, что работает в компании из 500 человек.
Почему CTEM в масштабах предприятия — это другая проблема
Сложность предприятия разрушает стандартные подходы к CTEM тремя конкретными способами:
1. Область охвата постоянно расширяется
В организации среднего бизнеса поверхность атаки в значительной степени познаваема. На предприятии новые активы постоянно попадают в область охвата различными способами:
- Облачная инфраструктура развертывается без проверки безопасности
- SaaS-инструменты внедряются отдельными командами
- Системы ИИ развертываются командами до того, как к ним обращаются специалисты по безопасности
- Объекты M&A приходят с целыми унаследованными поверхностями атаки
- Интеграции с поставщиками четвертого и пятого уровней продолжают расширять периметр
Этап определения области охвата для предприятия работает как задача непрерывного обнаружения, наложенная на проблему непрерывной уязвимости.
Рассмотрим только уровень цепочки поставок: согласно последнему отчету Hacker-Powered Security Report, в 2024–2025 годах количество подтвержденных отчетов об ИИ на платформе HackerOne, связанных с уязвимостями цепочки поставок (OWASP LLM05), выросло на 22%. В корпоративных средах уровень цепочки поставок поверхности атаки на порядки больше, чем уровень, находящийся под непосредственным управлением.
2. Мобилизация охватывает организационные границы
В стандартной программе CTEM мобилизация означает передачу результатов инженерам. На предприятии это означает передачу результатов нужной инженерной команде в десятках продуктовых линеек, географических регионов и бизнес-единиц, многие из которых вообще не подчиняются CISO.
Подтвержденная критическая находка в платежной системе дочерней компании должна дойти до нужного инженера с соблюдением нужного SLA и при поддержке организационных полномочий. Это фундаментально проблема управления, поэтому корпоративные программы все чаще направляют результаты через существующие инженерные инструменты, вместо того чтобы просить каждое бизнес-подразделение внедрять новый рабочий процесс.
Платформа H1 направляет результаты в Jira, ServiceNow и GitHub, где уже работают инженерные команды
3. Соответствие требованиям — это не один стандарт. Их много.
DORA применяется к финансовым услугам ЕС. NIS2 применяется к критической инфраструктуре ЕС. PCI DSS 4.0 применяется к средам платежных карт. Правила SEC по кибер-раскрытию применяются к публичным компаниям США.
Большинство предприятий сталкиваются с несколькими из них одновременно, в разных юрисдикциях, с разными требованиями к доказательствам и разными сроками. CTEM должен предоставлять непрерывные, проверяемые доказательства, выходящие далеко за рамки точечных оценок, на которые до сих пор опираются большинство программ соответствия.
Управление корпоративным CTEM: кто за что отвечает в масштабе
Стандартная модель владения CTEM — CISO, SecOps, наступательная безопасность, инженерия и риски — отлично работает в среде одной команды. На предприятии каждая из этих ролей распределяется между несколькими командами, бизнес-единицами и географическими регионами, а полномочия привлекать инженеров к ответственности за соблюдение SLA могут вообще отсутствовать на уровне команды безопасности.
Офис программы корпоративного CTEM
Уровень управления над командами безопасности бизнес-единиц при прямой поддержке руководства. Владеет определением мастер-области охвата для всех бизнес-единиц, структурой межбизнес-SLA для мобилизации, консолидированной отчетностью по метрикам для совета директоров и путем эскалации для находок, которые инженеры не устранили в рамках SLA.
Команды безопасности бизнес-единиц против центральной безопасности
Наиболее эффективная модель предприятия — федеративная. Центральная безопасность устанавливает стандарты, определяет область охвата и владеет уровнем валидации через программы bug bounty, тестирование на проникновение как услугу (PTaaS) и программы непрерывного тестирования, охватывающие все предприятие.
Команды безопасности бизнес-единиц отвечают за обнаружение и приоритизацию в пределах своего периметра. Ответственность за мобилизацию остается за инженерными руководителями бизнес-единиц, при этом SLA устанавливаются и обеспечиваются Офисом программы.
Когда центральная безопасность владеет валидацией
Валидация — самый сложный этап для федерализации. Bug bounty, PTaaS и другие мероприятия по непрерывному тестированию работают лучше как централизованно управляемые программы, чем как отдельные инициативы бизнес-единиц.
Helvetia Group предлагает реальную версию этой проблемы. По мере того как цифровое присутствие швейцарского страховщика росло в Германии, Австрии, Испании, Италии и Франции, тестирование на проникновение с фиксированным интервалом оставляло длинные окна, в течение которых вновь возникшие риски оставались незамеченными, а ограничения области охвата означали, что целые категории активов оставались вне регулярного контроля.
Переход к централизованно управляемой частной программе bug bounty в сочетании с ограниченными по времени всплесками тестирования вокруг крупных запусков дал руководству единое представление по всем юрисдикциям вместо пяти разрозненных.
Как Snap, Shopify и Helvetia достигли непрерывной валидации безопасности
CTEM и M&A: определение области охвата только что приобретенной поверхности атаки
Каждое поглощение приносит поверхность атаки, которую приобретающая организация не проектировала и не может полностью инвентаризировать в первый же день. Корпоративному CTEM нужен четкий протокол интеграции M&A.
Действия CTEM в первый день M&A
До завершения сделки поглощения закажите целевое мероприятие PTaaS или расширение области охвата bug bounty для внешней поверхности атаки цели. Это сфокусированное упражнение по обнаружению CTEM для выявления критических рисков, доступных извне, проводимое до закрытия сделки. Цель состоит в том, чтобы войти в период интеграции, уже зная, где находятся риски с самым высоким приоритетом, а не обнаруживать их через шесть месяцев после поглощения, когда они уже могут быть использованы.
Проблема определения области охвата при M&A
Приобретенные организации обычно приходят с теневыми ИТ и неуправляемыми активами, отсутствующими в инвентаризации, унаследованными системами, которые годами не обновлялись, инструментами разработчиков и CI/CD-конвейерами, работающими с разрешительными учетными данными, системами ИИ, развернутыми без проверки безопасности, и сторонними интеграциями, унаследованными от собственной сети поставщиков цели. Этап определения области охвата CTEM для приобретенной организации следует рассматривать как упражнение первого цикла. Предположите, что ничего не инвентаризировано, и начните с обнаружения внешних активов.
График интеграции
Рабочая поэтапная модель выполняется примерно с такой периодичностью:
- Дни с 1 по 30 охватывают обнаружение внешней поверхности атаки приобретенной организации.
- В период с 31-го по 90-й день приобретенные активы интегрируются в область действия корпоративной программы CTEM, после чего проводится первый этап приоритизации.
- Начиная с 91-го дня, охват валидации распространяется на приобретенные активы, а выявленные проблемы направляются через унифицированный рабочий процесс мобилизации.
CTEM и риски цепочки поставок: поверхность атаки, которую вы не контролируете
В корпоративных средах уровень цепочки поставок шире и сложнее для определения границ, чем уровень, находящийся под непосредственным управлением.
Корпоративная поверхность атаки цепочки поставок охватывает четыре уровня.
- Цепочка поставок программного обеспечения включает сторонние библиотеки, пакеты с открытым исходным кодом, ИИ-фреймворки и SaaS API.
- Сеть поставщиков охватывает поставщиков и партнеров, имеющих доступ к внутренним системам или данным.
- Риски четвертой и пятой сторон охватывают поставщиков ваших поставщиков.
- Цепочка поставок ИИ включает модели с открытыми весами, загруженные из публичных репозиториев, наборы данных для дообучения и фреймворки маршрутизации моделей.
Большинство корпоративных программ CTEM непоследовательно охватывают первый уровень и почти полностью игнорируют остальные три. Директива NIS2 и закон DORA требуют охвата рисков цепочки поставок как части непрерывного управления рисками, что делает это обязательством по соблюдению нормативных требований в рамках обеих структур.
Корпоративную цепочку поставок невозможно инвентаризировать один раз и оставить в покое. Новые зависимости появляются с каждым коммитом кода, каждым внедрением SaaS и каждым использованием инструментов ИИ.
Непрерывное обнаружение цепочки поставок с помощью инструментов SBOM, сканирования зависимостей и аудита ИИ-фреймворков должно напрямую интегрироваться в этап обнаружения CTEM, чтобы у предприятия было актуальное представление о том, от чего оно на самом деле зависит.
Программа H1 Bounty расширяет возможности обнаружения, проводимого исследователями, на этот уровень, наряду с данными SBOM и сканирования зависимостей.
Сопоставление корпоративного CTEM с нормативными базами
NIS2 (Критическая инфраструктура ЕС)
NIS2 требует, чтобы охваченные организации постоянно внедряли меры по управлению рисками безопасности, включая обработку уязвимостей, безопасность цепочки поставок и отчетность об инцидентах.
CTEM напрямую удовлетворяет требованию непрерывности. Этапы обнаружения и приоритизации предоставляют задокументированные доказательства управления рисками, которые ищут аудиторы NIS2, а этап валидации добавляет доказательства эффективности контроля, выходящие за рамки минимальных требований NIS2, предоставляя организациям доказательства для аудита, которые выдерживают реальную проверку.
DORA (Финансовые услуги ЕС)
Требования DORA по управлению ИКТ-рисками предписывают непрерывный мониторинг, управление уязвимостями и тестирование на устойчивость для финансовых организаций и их поставщиков ИКТ-услуг.
Цикл CTEM напрямую соотносится с этим: непрерывное обнаружение для мониторинга активов и уязвимостей, приоритизация для ранжирования ИКТ-рисков, валидация через PTaaS и состязательное тестирование для требований DORA по устойчивости, а также мобилизация для задокументированных рабочих процессов устранения, которые проверяют аудиторы DORA. DORA специально требует, чтобы сторонние поставщики ИКТ демонстрировали непрерывное управление рисками, что делает эту структуру напрямую применимой к организациям финансовых услуг, использующим CTEM.
PCI DSS 4.0
PCI DSS 4.0 ввел требования к непрерывному мониторингу, которые выходят за рамки старой модели ежегодной оценки. Требование 11.3 теперь предписывает проведение тестирования на проникновение среды данных держателей карт как минимум ежегодно и после значительных изменений, с непрерывным мониторингом между тестами.
CTEM удовлетворяет обе части: PTaaS обеспечивает структурированное тестирование на проникновение, а непрерывное обнаружение в рамках bug bounty закрывает пробелы между тестами.
Правила раскрытия информации о кибербезопасности SEC
Публичные компании обязаны сообщать о существенных инцидентах кибербезопасности в течение четырех рабочих дней и ежегодно раскрывать свои процессы управления рисками кибербезопасности.
CTEM создает задокументированные, непрерывные доказательства управления рисками, которые поддерживают ежегодное раскрытие информации. Данные о MTTR, уровне охвата и показателе снижения рисков из H1 Analytics & Intelligence формируют доказательную базу для отчетов SEC.
Как ИИ меняет область применения корпоративного CTEM
Корпоративная поверхность атаки ИИ растет быстрее, чем любая другая категория поверхности атаки. Только количество отчетов об инъекциях промптов выросло на 540% в 2025 году, а количество подтвержденных отчетов об уязвимостях, связанных с ИИ, увеличилось на 210% с 2024 года. Корпоративные организации, которые не включают ИИ-системы в область действия своего CTEM, создают «слепую зону», которую CTEM был призван устранить.
Для корпоративных организаций проблема заключается в том, что ИИ развертывается на уровне бизнес-подразделений, а не централизованно управляется службой безопасности.
Рассматривая ИИ-редтеминг как централизованную возможность валидации и привлекая глобальное сообщество исследователей через HackerOne, Snap обнаружила уязвимости, которые полностью пропустили состязательные наборы данных и автоматизированные инструменты, сгенерировав более 300 000 состязательных взаимодействий и, по словам Snap, доказав, что «человеческая изобретательность часто превосходит состязательные наборы данных или атаки, сгенерированные ИИ».
Та же модель федеративного управления, которая применяется к CTEM в целом, применима и к ИИ. Центральная служба безопасности устанавливает стандарты охвата ИИ и отвечает за ИИ-редтеминг как централизованную возможность валидации, в то время как бизнес-подразделения несут ответственность за декларирование своих развертываний ИИ перед Программным офисом.
CTEM для ИИ-систем: как применить 5-этапную структуру к вашей поверхности атаки ИИ
Зрелость CTEM в корпоративном масштабе: 5-уровневая модель
Трехуровневая модель «Начальный», «Развивающийся», «Зрелый» в полном руководстве по CTEM описывает зрелость отдельной программы. В корпоративном масштабе зрелость варьируется в зависимости от бизнес-подразделения. Подразделение финансовых услуг может находиться на уровне «Зрелый», в то время как недавно приобретенная дочерняя компания все еще находится на уровне «Начальный». Корпоративная задача состоит в том, чтобы устранить эти подразделения начального уровня, где бы они ни находились в организационной структуре, поскольку они представляют собой самые слабые звенья в общей поверхности атаки.
Именно для устранения этого разрыва предназначен пятый уровень. На 5-м уровне каждое бизнес-подразделение работает на уровне «Развивающийся» или выше, действует протокол интеграции M&A, цепочка поставок постоянно инвентаризируется, ИИ-системы включены в область охвата во всех подразделениях, доказательства соответствия требованиям генерируются автоматически на основе данных программы, а SLA мобилизации соблюдаются по всему предприятию с отчетностью на уровне совета директоров.
Для достижения этого требуется нечто большее, чем просто зрелая программа безопасности в центре. Требуется инфраструктура управления, которая распространяет непрерывную валидацию на каждый уголок предприятия, и организационная воля придерживаться этого стандарта во всем.
Сначала создайте фундамент: прочитайте Полное руководство по CTEM
