CTEM для крупного бизнеса: масштабирование непрерывного управления воздействием угроз

Согласно недавним исследованиям, для 40% крупных компаний рост за счет слияний, поглощений и стратегических партнерств является главным приоритетом в 2026 году.

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

CTEM для 100 активов и CTEM для 100 000 активов — это принципиально разные операционные задачи. Пять этапов (определение области, обнаружение, расстановка приоритетов, валидация и мобилизация) остаются прежними. Модель управления, стек инструментов, обязательства по комплаенсу и сложность мобилизации — нет.

Руководители корпоративной безопасности понимают эту структуру и должны внедрить ее в работу дочерних компаний, объектов M&A, изолированных инженерных команд и в различных глобальных регуляторных средах. При этом то, что работает в таких масштабах, отличается от методов работы в компании с 500 сотрудниками.

Почему CTEM в масштабах предприятия — это совсем другая задача

Корпоративная сложность нарушает стандартные подходы CTEM тремя конкретными способами:

1. Область применения постоянно расширяется

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

• Облачная инфраструктура развертывается без проверки безопасности.
• SaaS-инструменты внедряются отдельными командами.
• Системы искусственного интеллекта развертываются командами до того, как специалисты по безопасности успевают их проконсультировать.
• Объекты M&A привносят с собой целые устаревшие поверхности атак.
• Интеграции с поставщиками четвертого и пятого уровней продолжают расширять периметр.

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

Рассмотрим только уровень цепочки поставок: согласно последнему отчету Hacker-Powered Security Report, количество действительных отчетов об уязвимости цепочки поставок OWASP LLM05 на платформе HackerOne выросло на 22% в период с 2024 по 2025 год. В корпоративных средах уровень цепочки поставок на поверхности атаки на порядки превосходит уровень, находящийся под прямым управлением.

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 и риски цепочки поставок: поверхность атаки, которой вы не владеете

В корпоративных средах уровень цепочки поставок шире и сложнее для охвата, чем непосредственно управляемый уровень.

Поверхность атаки корпоративной цепочки поставок охватывает четыре уровня.

• Цепочка поставок программного обеспечения включает сторонние библиотеки, пакеты с открытым исходным кодом, фреймворки искусственного интеллекта и API SaaS.
• Сеть вендоров охватывает поставщиков и партнеров, имеющих доступ к внутренним системам или данным.
• Риски четвертых и пятых сторон охватывают вендоров ваших вендоров.
• Цепочка поставок ИИ охватывает модели с открытыми весами из публичных репозиториев, наборы данных для дообучения и фреймворки маршрутизации моделей.

Большинство корпоративных программ CTEM непоследовательно охватывают первый уровень и практически полностью игнорируют остальные три. Директива NIS2 и регламент DORA требуют учета рисков цепочки поставок в рамках непрерывного управления рисками, что делает это обязательным требованием комплаенса в рамках обеих концепций.

Корпоративную цепочку поставок невозможно проинвентаризировать один раз и оставить в покое. Новые зависимости появляются с каждым коммитом кода, каждым подключением SaaS и каждым внедрением инструментов ИИ.

Непрерывное обнаружение элементов цепочки поставок с помощью инструментов SBOM, сканирования зависимостей и аудита ИИ-фреймворков должно напрямую поступать на этап обнаружения (Discovery) 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 обеспечивает структурированное тестирование на проникновение, а непрерывное обнаружение через баунти-программы закрывает пробелы между тестами.

Правила SEC в отношении киберотчетности

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

CTEM создает задокументированные, непрерывные свидетельства управления рисками, которые подкрепляют ежегодное раскрытие информации. Данные о MTTR, коэффициенте покрытия и показателе снижения уровня экспозиции из H1 Analytics & Intelligence формируют доказательную базу для текстов раскрытия информации по стандартам SEC.

Как ИИ меняет сферу применения корпоративного CTEM

Поверхность атаки корпоративного ИИ растет быстрее, чем любая другая категория поверхностей атаки. Только количество отчетов о промпт-инъекциях подскочило на 540% в 2025 году, а количество действительных отчетов об уязвимостях, связанных с ИИ, увеличилось на 210% по сравнению с 2024 годом.1 Корпоративные организации, которые не включают ИИ-системы в область действия CTEM, создают «слепую зону», для устранения которой и был создан CTEM.

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

Рассматривая ред-тиминг ИИ как централизованную возможность валидации и привлекая глобальное сообщество исследователей через HackerOne, Snap обнаружила уязвимости, которые полностью упустили из виду состязательные наборы данных и автоматизированные инструменты, сгенерировав более 300 000 состязательных взаимодействий и, по словам Snap, доказав, что «человеческая изобретательность часто превосходит состязательные наборы данных или атаки, сгенерированные ИИ».

Та же модель федеративного управления, которая применяется к CTEM в целом, применима и к ИИ. Центральная безопасность устанавливает стандарты области применения ИИ и владеет ред-тимингом ИИ как централизованной возможностью валидации, в то время как бизнес-подразделения несут ответственность за декларирование своих развертываний ИИ Офису программы.

CTEM для систем ИИ: как применить 5-этапную модель к поверхности атаки ИИ

Зрелость CTEM в корпоративном масштабе: 5-уровневая модель

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

Именно этот пробел призвана закрыть пятая ступень. На уровне 5 каждое бизнес-подразделение работает на развитом уровне или выше, действует протокол интеграции M&A, цепочка поставок инвентаризируется непрерывно, системы ИИ охвачены во всех подразделениях, данные комплаенса генерируются автоматически на основе данных программы, а соглашения об уровне обслуживания (SLA) по мобилизации соблюдаются на уровне всего предприятия с отчетностью перед советом директоров.

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

Создайте фундамент в первую очередь: прочтите полное руководство по CTEM

1. Отчет о безопасности на основе хакеров за 2025 год: Восход бионического хакера

Методология исследования: HackerOne и UserEvidence провели опрос 99 представителей клиентов HackerOne в период с июня по август 2025 года. Респонденты представляли организации из различных отраслей и с разным уровнем зрелости, в том числе 6% компаний из списка Fortune 500, 43% крупных предприятий, а 31% занимали должности в исполнительном или высшем руководстве. Параллельно HackerOne провела опрос 1825 активных исследователей HackerOne, который проводился в период с июля по август 2025 года. Полученные данные были дополнены информацией с платформы HackerOne за период с 1 июля 2024 года по 30 июня 2025 года, охватывающей все активные программы клиентов. Анализ полезной нагрузки: HackerOne также проанализировала более 45 000 сигнатур полезной нагрузки из 23 579 отредактированных отчетов об уязвимостях, поданных за тот же период.