?Это часть 17 серии “Управление уязвимостями для самых маленьких” - практического руководства по VM с нуля. Главы самостоятельны, но если хочется по порядку, оглавление и все части серии тут.

Эта глава связывает воедино все, о чем говорили раньше. Управление активами, поиск уязвимостей, приоритизация, EASM, автопентест - все эти кусочки складываются в одну картину под названием CTEM. Gartner называет ее одним из главных трендов, и это, пожалуй, самый современный взгляд на то, как должна быть устроена безопасность.

Эволюция: от сканера к управлению экспозицией

Откуда взялся CTEM, видно по тому, как менялся сам подход к управлению уязвимостями.

Первое поколение, традиционное управление уязвимостями (в РФ примерно до 2020 года): запустили сканер по расписанию, получили список уязвимостей с баллами CVSS, отдали в ИТ. Просто, но неэффективно: список огромный, приоритеты непонятны, контекста нет.

Второе поколение, риск-ориентированное управление уязвимостями, RBVM (в РФ примерно с 2020 года и по сей день). Пришло понимание, что патчить все подряд невозможно. Стали учитывать эксплуатируемость (EPSS), бизнес-контекст активов, реальную опасность. Это уже то, чему мы учили в главе про приоритизацию. Большой шаг вперед, но все еще в рамках одних только CVE.

Третье поколение, управление экспозицией, CTEM (с 2026 года). Безопасность перестает быть только про уязвимости (CVE) и начинает охватывать все способы, которыми вас можно атаковать: уязвимости, мисконфиги, слабые пароли, избыточные права, открытые сервисы, забытые активы. Все это вместе называется экспозицией (exposure), подверженностью угрозам.

Логика простая: злоумышленнику все равно, через что вас ломать. Ему не важно, CVE это с красивым номером или просто открытая база данных с паролем “123456”. Поэтому и защищаться нужно не от “уязвимостей”, а от всех путей атаки сразу.

Что такое CTEM

CTEM (Continuous Threat Exposure Management) - непрерывное управление подверженностью угрозам. Термин ввел Gartner в 2022 году [1]. Это не продукт, который можно купить, а программа, методология: непрерывный цикл из пяти этапов, который постоянно крутится в организации.

CTEM - “зонтик” над всем, чему мы учились в предыдущих главах. Управление активами, VM, EASM, автопентест - инструменты внутри CTEM. CTEM задает рамку, в которой они работают согласованно.

CTEM, CAASM, ASM: в чем разница

Еще три аббревиатуры постоянно путают между собой и с CTEM. ASM (Attack Surface Management) - зонтичный термин Gartner для управления поверхностью атаки в целом, внутри него три категории технологий: EASM, CAASM и DRPS (Digital Risk Protection Services) [4]. EASM (External Attack Surface Management) мы уже разобрали, но для полной картинки: Gartner выделил его в отдельную категорию рынка в 2021 году, он смотрит на компанию “глазами атакующего” и ищет внешние, обращенные в интернет активы, включая забытые и теневые. CAASM (Cyber Asset Attack Surface Management) обозначен Gartner тогда же, но устроен иначе: не сканирует активно, а строит единую картину активов через интеграции с уже имеющимися системами (EDR, CMDB, сканеры уязвимостей, IAM), охватывая и внутренние, и внешние активы.

CTEM же - не инструмент и не категория рынка, а программа целиком, представленная Gartner в 2022 году. Она использует EASM, CAASM и DRPS как источники данных для этапов Scoping и Discovery, “что у нас вообще есть и выглядит уязвимым”. А дальше добавляет то, чего сами инструменты ASM не делают: Prioritization по бизнес-риску, Validation через автопентест и BAS, Mobilization - организационную часть по устранению. ASM-инструменты отвечают на вопрос “что у нас есть снаружи и как это выглядит для атакующего”, CTEM - на вопрос “что из этого реально опасно и что мы с этим делаем”, и данные ASM для него один из источников на входе.

Пять этапов CTEM

Scoping, определение периметра. Сначала решаем, что вообще защищаем. Не “всю инфраструктуру вообще” (это утопия), а конкретные бизнес-критичные активы и системы. Здесь мы возвращаемся к недопустимым событиям из самых первых глав: что для бизнеса смертельно, то и в фокусе. Это управленческое решение, а не техническое.

Discovery, обнаружение. Находим все, что относится к выбранному периметру: активы, уязвимости, мисконфиги, открытые сервисы, учетки с избыточными правами. За это отвечают инструменты управления активами и EASM, о которых мы говорили. Цель - полная картина, включая то, о чем вы не знали.

Prioritization, приоритизация. Ранжируем обнаруженное по реальному риску для бизнеса. Не по голому CVSS, а по совокупности факторов: эксплуатируемость, контекст актива, возможные пути атаки. Это ровно то, чему была посвящена глава про приоритизацию (CVSS, EPSS, KEV, методика ФСТЭК).

Validation, валидация. Вот это новый этап, и без него вся конструкция не работает. Мы проверяем: действительно ли найденную проблему можно эксплуатировать именно в нашей среде? Доберется ли злоумышленник до цели? В дело вступают автопентест и BAS из предыдущей главы, а также отдельные продукты класса EM с верификацией путей достижимости и применимости угроз для целевых систем. Валидация отсекает теоретические риски и оставляет реальные. Зачем тратить силы на “критическую” уязвимость, до которой атакующий физически не может дотянуться?

Mobilization, реализация. Превратить выводы в действия: передать задачи на устранение, автоматизировать процесс, снять организационные барьеры между ИБ и ИТ. Помните все наши разговоры про SLA, коммуникацию между командами и “телепатов нет”? Вот это оно и есть. Самый частый провал CTEM - именно здесь: нашли, приоритизировали, провалидировали, а устранить не смогли, потому что ИТ и ИБ не договорились.

И цикл повторяется. Снова и снова, непрерывно. Отсюда и слово Continuous в названии.

Сквозной пример: как это выглядит на практике

Пять этапов легко читаются как абстракция, поэтому проследим их на одном конкретном недопустимом событии: “утечка базы клиентов с данными карт” у среднего интернет-магазина.

На Scoping совет директоров и ИБ договариваются: именно утечка базы клиентов - то, что убьет бизнес репутационно и по штрафам. Периметр - все системы, которые хранят или обрабатывают эти данные: сайт, платежный шлюз, CRM, бэкапы, партнерские интеграции. Внутренний тестовый стенд бухгалтерии, у которого нет доступа к этим данным, вне периметра, и это нормально.

На Discovery инвентаризация и EASM находят неожиданное: забытый тестовый стенд CRM на поддомене с копией боевой базы, открытый на внешний периметр, плюс избыточные права у части сотрудников поддержки.

На Prioritization из десятков находок реальную опасность несет именно забытый стенд: у него известная CVE с публичным эксплойтом, высокий EPSS и прямой сетевой доступ к базе. Устаревшие библиотеки на внутреннем сервере без внешнего доступа уходят в конец очереди: тот же CVSS, но совсем другой риск.

На Validation автопентест подтверждает: со стенда действительно можно дотянуться до боевой базы через общий бэкенд-сервис. Путь атаки не теоретический, а реальный и работающий здесь и сейчас. Решение класса EM собирает все данные воедино и подтверждает, что хакер пройдет от точек входа до целевой системы.

На Mobilization задача уходит в ИТ с четким SLA: раз путь атаки подтвержден, счет идет на часы, а не на недели. Стенд либо патчат, либо изолируют от продовой сети. Отдельно проговаривают, кто отвечает за то, чтобы тестовые окружения не плодились бесконтрольно, иначе через месяц история повторится с другим забытым стендом.

Дальше цикл идет на новый круг: Discovery снова ищет пути к тому же недопустимому событию, только уже без найденного и закрытого стенда.

Типичные ошибки при внедрении CTEM

Спотыкаются на каждом из этапов. На Scoping пытаются с порога “покрыть всю инфраструктуру”, вместо того чтобы отталкиваться от 2-3 недопустимых событий: фокус размывается, программа стартует и тонет в объеме. На Discovery экономят на инвентаризации активов, и в итоге картина замусорена теневыми и забытыми системами, которые никто не может ни объяснить, ни быстро закрыть. На Prioritization откатываются к голому CVSS вместо контекста бизнеса и эксплуатируемости: тысячи “критических” находок, и снова непонятно, за что хвататься первым. Validation пропускают целиком, чаще всего из-за нехватки ресурсов на пентест каждой находки, и силы уходят на теоретические риски, недостижимые для атакующего. На Mobilization находки копятся в беклоге без ответственных и сроков, а ИБ с ИТ бесконечно спорят, чья это задача.

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

Знаменитый прогноз Gartner и реальность

Gartner сделал громкое заявление: организации, которые приоритизируют инвестиции в безопасность на основе программы CTEM, к 2026 году будут в три раза реже становиться жертвами взломов [1]. Эта цитата кочует по всем презентациям.

Этот прогноз - скорее стратегическое допущение Gartner, чем измеренный факт. Независимых исследований, которые бы строго сравнили частоту взломов у тех, кто внедрил CTEM, и у остальных, не опубликовано. Более того, по данным на 2025-2026 годы, лишь около 16% организаций реально довели CTEM до операционного внедрения, хотя важность концепции признают 87% [2]. Концепцию все хвалят, но мало кто доводит до конца.

Значит ли это, что CTEM - пустой хайп? Нет. Это значит, что путь к зрелой безопасности долгий, и большинство застревает на полпути. Сама логика CTEM здравая: непрерывно, по всем типам угроз, с проверкой боем, с фокусом на бизнес-критичное. Просто внедрить это целиком трудно.

Косвенное подтверждение зрелости концепции: в ноябре 2025 года Gartner выпустил первый в истории Magic Quadrant для платформ оценки экспозиции (Exposure Assessment Platforms), оценив 20 вендоров. В квадрант лидеров вошли как минимум Tenable, Qualys и Rapid7 [3]. Когда у класса решений появляется свой Magic Quadrant, рынок созрел и технология перешла из разряда новинок в мейнстрим. Было и исследование IDC по этому классу, и в него попала российская компания Positive Technologies.

CTEM для “самых маленьких”: с чего начать

CTEM звучит масштабно и может напугать небольшую компанию. Но начать можно без дорогих платформ, методология тут важнее инструментов. Определите 2-3 недопустимых события: что вас реально убьет? Остановка касс? Утечка клиентской базы? Кража денег? Найдите активы, через которые это может случиться, тем, что есть: сканером, ручной разведкой периметра, инвентаризацией. Приоритизируйте по реальному риску, а не по количеству: один путь к недопустимому событию важнее тысячи мелких уязвимостей в тестовом сегменте. Проверьте, реален ли путь атаки, даже простой пентест критичного сценария лучше, чем ничего. Устраните, договорившись с ИТ о сроках. И повторяйте регулярно.

Все это - то, чему вы уже научились в книге. CTEM не требует начинать с нуля. Он помогает собрать разрозненные практики в осмысленную непрерывную программу с правильным фокусом: на том, что реально опасно для бизнеса.

Российский контекст

В России термин CTEM пока менее распространен, чем на Западе, но движение в ту же сторону очевидно. Концепция результативной кибербезопасности, о которой мы говорили в самом начале книги (определение недопустимых событий, проверка через киберучения и багбаунти), по сути очень близка к CTEM: тот же фокус на бизнес-критичном и та же проверка боем. А появление российских EASM-платформ, автопентеста и зрелых VM-решений дает весь инструментарий для CTEM-программы на отечественном стеке.

Так что, даже если слово “CTEM” вам непривычно, его идеи вы, скорее всего, уже применяете.

А как у вас?

На каком из пяти этапов CTEM вы сильнее всего, а где проседаете? Моя ставка - на “реализации”, то есть на устранении и стыке ИБ-ИТ. А у вас? И не кажется ли вам CTEM просто красивой оберткой для того, что хорошие команды и так делали?

Навигация по серии: ⬅️Предыдущая: Гл. 16. Проверка боем · ?Оглавление серии · Следующая: Гл. 18. Почему обычный сканер пасует в Kubernetes➡️

Если у вас в инфраструктуре что-то устроено иначе - расскажите в комментариях. Зашло - подписывайтесь, чтобы не пропустить следующую часть.