По данным IBM X-Force Threat Intelligence Index 2025, среднее время между публикацией CVE и её устранением в организации - 29 месяцев. Два с половиной года. За это время атакующий проходит от эксплуатации публичного сервиса - Exploit Public-Facing Application (T1190, Initial Access) - до lateral movement в среднем за 62 минуты. Рекорд 2024 года по данным CrowdStrike Global Threat Report 2025 - 51 секунда. Vulnerability management на периодическом сканировании и CVSS-сортировке этот разрыв не закроет. Физически не успеет. Continuous threat exposure management (CTEM) переформулирует задачу: не «закрой максимум CVE», а «сократи validated attack paths к тому, что действительно критично для бизнеса».
Почему CVE-гонка не снижает реальный риск
Стандартный VM-процесс выглядит знакомо: сканер нашёл 40 000 CVE, команда сортирует по CVSS, создаёт тикеты на critical и high, патчит по расписанию. Формально CIS Control 7 (Continuous Vulnerability Management) выполнен. На практике - три проблемы, и каждая ломает модель.CVSS - это severity, не risk. CVSS описывает техническую серьёзность уязвимости вне контекста конкретной среды. CVE с CVSS 9.8 на изолированном тестовом сервере за двумя сегментами и ACL - одна история. CVE с CVSS 6.5 на интернет-экспонированном identity-сервисе с публичным PoC и без WAF - совсем другая. Когда приоритизация сводится к сортировке по числу, результат предсказуем: команда перегружена, а реальный риск снижается непоследовательно.
75% атак используют валидные credentials, а не эксплойты. CrowdStrike Global Threat Report 2025: 75% вторжений в 2024 году шли через действительные учётные данные для initial access, 79% детекций - malware-free. Verizon DBIR 2025 фиксирует 38% утечек через кражу credentials и 68% инцидентов с участием человеческого фактора. Скомпрометированный легитимный хост или insider с valid credentials - экспозиция, которую VM не видит в принципе. Нет CVE - нет аномалии для сканера. Утечки API-ключей, избыточные OAuth-разрешения в SaaS, orphaned DNS-записи - всё это экспозиции без CVE-идентификатора, и VM-процесс о них даже не подозревает.
VM-скоуп покрывает меньше, чем кажется. По оценке Cymulate, лишь 17% организаций способны идентифицировать большинство своих активов. Теневые облачные ресурсы, забытые поддомены разработчиков, интеграции третьих сторон через API - всё за пределами видимости VM-программы. С введением оборотных штрафов за утечки персональных данных в России финансовая цена этого разрыва стала вполне конкретной: регулятору недостаточно отчёта «мы запатчили 95% critical CVE», если утечка произошла через вектор, которого не было в scope.
| Критерий | Vulnerability Management | CTEM |
|---|---|---|
| Scope | CVE в известных активах | Полная поверхность атаки: CVE + identity + misconfig + supply chain |
| Частота | Периодические сканы | Непрерывный мониторинг |
| Приоритизация | CVSS, иногда EPSS/KEV | Эксплуатируемость + бизнес-контекст + attack path |
| Валидация | Ресканирование | BAS, adversary emulation, purple teaming |
| Метрики | Количество закрытых CVE, SLA | Сокращение validated attack paths к critical assets |
| Non-CVE экспозиции | Вне scope | Credential leaks, misconfig, identity, brand surface |
| Результат для бизнеса | «Запатчили N тикетов» | «Сократили M attack paths к системе платежей» |
CTEM программа: пять стадий как операционный цикл
CTEM - не продукт и не лицензия на платформу. Это операционная модель, которую Gartner представил в 2022 году и формализовал в 2023. По прогнозу Gartner, организации с CTEM-программой к 2026 году в три раза реже будут жертвами успешных breaches. Согласно их же опросу, 71% организаций могут извлечь пользу из CTEM-подхода, а 60% уже реализуют или рассматривают такую программу. Пять стадий - scoping, discovery, prioritization, validation, mobilization - но отличие от «ещё одного фреймворка» в непрерывности цикла и привязке к бизнес-контексту на каждом этапе.Scoping и discovery: определяем границы и находим неизвестное
Scoping начинается не с IP-диапазонов, а с бизнес-функций. Вопрос не «какие серверы сканировать», а «какие бизнес-процессы критичны и какие активы их обеспечивают». Для небольшой команды - scope по подразделению (финансы, продажи). Для крупной - по бизнес-функции (кредитный конвейер, процессинг платежей, клиентский портал).Gartner рекомендует включать в scope не только серверы и рабочие станции, но и корпоративные аккаунты в соцсетях (brand attack surface), код-репозитории (GitHub, GitLab - утечки секретов), интеграции supply chain и внешнюю поверхность атаки - то, что видит атакующий снаружи.
Discovery в CTEM - не только vulnerability scan. Это построение карты всех экспозиций в определённом scope: уязвимости, misconfigurations, identity-проблемы (учётные записи без MFA на critical systems, service accounts с избыточными привилегиями), утечки credentials в публичных репозиториях. Стек инструментов: EASM-платформы (Cortex Xpanse, Censys) для внешней поверхности, CSPM для облачных конфигураций, сканеры уязвимостей (Tenable.io, Qualys) для внутренних активов, secrets-сканеры для репозиториев кода.
CVE приоритизация через бизнес-контекст и attack paths
Приоритизация - сердце CTEM-программы. Задача: не ранжировать 40 000 CVE, а ответить на вопрос «какие экспозиции материально увеличивают вероятность бизнес-импактного инцидента и что закрывать первым».Три сигнала, которые улучшают приоритизацию даже в традиционном VM:
- CISA KEV (Known Exploited Vulnerabilities) - курируемый каталог уязвимостей с подтверждённой эксплуатацией in the wild. CVE в KEV - закрывать вне очереди, без обсуждений.
- FIRST EPSS (Exploit Prediction Scoring System) - вероятностная модель, оценивающая likelihood эксплуатации в ближайшие 30 дней. Разделяет «теоретически опасное» и «операционно срочное».
- SSVC (Stakeholder-Specific Vulnerability Categorization) - decision-tree методология привязки решений к stakeholder impact.
Decision tree для приоритизации экспозиций:
- CVE в CISA KEV? Да - немедленное закрытие, вне очереди.
- EPSS > 0.1 (top ~10% по percentile)? Да - high priority, вне зависимости от CVSS.
- Экспозиция доступна из интернета? Да - приоритет повышается на уровень.
- От экспозиции до critical asset менее 2 hops? Да - critical.
- Публичный PoC существует? Да - приоритет повышается.
- Компенсирующие контроли на месте (WAF, сегментация, MFA)? Да - допустимо отложить при отсутствии других факторов.
Валидация и мобилизация: от находки до закрытия
Валидация - этап, который отличает CTEM от «улучшенного VM». Это не ресканирование. Это проверка: может ли экспозиция быть реально эксплуатирована в вашей среде и детектируют ли контроли такую попытку.Инструменты валидации: BAS-платформы (Cymulate, AttackIQ, SafeBreach) для автоматизированного тестирования контролей, purple teaming для совместной проверки detection capability силами red и blue team, целевой пентест для глубокой, но point-in-time валидации attack paths. Результат - не список «что найдено», а ответ: «что реально эксплуатируемо, что детектируется, что нет».
Мобилизация - координация закрытия. Не «создать тикет в Jira с номером CVE», а обеспечить: ответственный владелец актива получает remediation plan с бизнес-контекстом, SLA привязан к risk tier, отчётность понятна и CISO, и бизнесу. Звучит банально, но на практике именно здесь всё буксует - между «нашли» и «починили» проходят те самые 29 месяцев.
Ограничения CTEM-подхода. CTEM не заменяет VM - он надстраивается над ним. Без базового VM-процесса (сканирование, патчинг, SLA) CTEM-программа не заработает. CTEM требует кросс-функционального взаимодействия - security, IT operations, бизнес - что создаёт организационные барьеры. В организации с командой менее 3 человек в security полный CTEM-цикл нереалистичен: начните с обогащения VM-приоритизации через KEV и EPSS и EASM для внешней поверхности. Это уже даст ощутимый сдвиг.
Управление поверхностью атаки на практике: сценарий vs detection
Понедельник, 9:15 утра. SOC получает алерт от SIEM: аномальные POST-запросы на dev.company.ru с exploit-сигнатурами в payload. К 9:40 forensics-команда видит - foothold установлен, lateral movement через SMB уже идёт. К 10:00 атакующий добрался до сервера с базой PII. Знал ли VM-сканер об уязвимости на dev.company.ru? Нет - потому что поддомен не был в scope. Это не гипотетический сценарий - это паттерн из множества постмортемов, где initial access шёл через forgotten asset.Разберём цепочку через MITRE ATT&CK.
Цепочка атакующего:
- Vulnerability Scanning (T1595.002, Reconnaissance) - сканирует внешний периметр, находит устаревший сервис на забытом поддомене.
- Acquires Exploits (T1588.005, Resource Development) - находит публичный PoC.
- Exploit Public-Facing Application (T1190, Initial Access) - получает foothold.
- Network Service Discovery (T1046, Discovery) - сканирует внутреннюю сеть, находит SMB-шары и RDP.
- Exploitation of Remote Services (T1210, Lateral Movement) - перемещается к серверу с базой данных.
- Exploitation for Privilege Escalation (T1068, Privilege Escalation) - повышает привилегии.
Что видит CTEM: scoping через EASM обнаружил бы dev.company.ru как часть внешней поверхности; discovery нашёл бы уязвимость и отсутствие WAF; приоритизация подняла бы приоритет - интернет-экспонированный хост, 2 hops до базы PII; валидация через BAS проверила бы detection capability на этом хосте.
Detection-чеклист для SOC по этому сценарию:
| TTP (MITRE ATT&CK) | Что детектировать | Источник данных | Правило корреляции |
|---|---|---|---|
| T1595.002 Vulnerability Scanning | Массовые запросы к публичным сервисам с одного IP | WAF, IDS, Netflow | Более 100 запросов/мин к более 5 URI с одного source IP |
| T1190 Exploit Public-Facing Application | Аномальные POST-запросы с exploit payload | WAF logs, access logs | Payload-сигнатуры + нестандартный User-Agent + HTTP 200 в ответе |
| T1046 Network Service Discovery | Внутреннее сканирование портов | EDR, firewall internal logs | Один хост обращается к более 20 уникальным IP на портах 445, 3389, 22 за 5 мин |
| T1210 Exploitation of Remote Services | Нетипичные SMB/RDP-аутентификации | Windows Security Log (4624, 4625), EDR | Logon Type 3 или 10 с хоста, не включённого в baseline для этого сервера |
| T1068 Privilege Escalation | Модификация привилегированных групп | Windows Security Log (4720, 4728, 4732) | Добавление учётной записи в Domain Admins или локальную группу Administrators |
Непрерывное управление уязвимостями: 90-дневный план перехода
Переход к CTEM не требует одномоментной замены всего стека. Начните с пилота на одном бизнес-критичном scope.Требования к окружению:
- Действующая VM-программа (Tenable.io, Qualys, Rapid7 или аналог)
- Доступ к SIEM (Splunk, Elastic, MaxPatrol SIEM) для настройки detection-правил
- EASM-инструмент: Cortex Xpanse, Censys для enterprise-уровня, или бесплатный OWASP Amass для обнаружения субдоменов
- Минимум 1 FTE (security engineer с доступом к asset inventory и SIEM) на 90 дней
Дни 30-60: Приоритизация + валидация. Интегрируйте CISA KEV и EPSS в процесс приоритизации (для Tenable - встроенный VPR, для Qualys - TruRisk). Постройте attack paths от обнаруженных экспозиций к critical assets - вручную или с помощью инструментов attack path management (XM Cyber, если есть бюджет). Проведите целевой пентест или purple team exercise на двух-трёх критичных attack paths. Настройте detection-правила в SIEM для TTP из таблицы выше.
Дни 60-90: Мобилизация + метрики. Настройте remediation workflow: от обнаружения через приоритизацию к тикету с бизнес-контекстом и ответственным владельцем актива. Внедрите метрики первого цикла: mean-time-to-remediate по risk tier, количество validated attack paths к crown jewels, coverage gap между EASM-результатами и VM-inventory. Подготовьте отчёт для руководства: не «закрыто 500 CVE», а «сокращено 3 из 7 валидированных attack paths к системе обработки платежей».
Чеклист перехода от реактивного патчинга к CTEM
Exposure management - не следующая итерация vulnerability management, а принципиально другой процесс. VM отвечает на вопрос «какие CVE у нас есть». CTEM отвечает на вопрос «какие экспозиции приведут к инциденту, если их не закрыть». Разница - как между списком запчастей и диагностикой машины перед рейсом.
В организациях, где я выстраивал этот переход, главное сопротивление шло не от бюджета и не от инструментов. Оно шло от привычки мерить работу количеством закрытых CVE. Команда, которая закрывает 2000 CVE в квартал, выглядит продуктивной в отчётах. Команда, которая закрыла 40 CVE, но сократила validated attack paths к crown jewels с 12 до 3, - выглядит «ленивой» в старой системе координат. CTEM-программа не взлетит, пока руководство не начнёт оценивать reduction in exposure, а не reduction in backlog.
По данным Mandiant M-Trends 2025, медианное время обнаружения атакующего в сети - 11 дней, исторический минимум. Окно для remediation сужается с двух сторон: атакующие быстрее эксплуатируют, detection улучшается. Вопрос - используете ли вы это окно для валидации реальных attack paths или продолжаете гнать CVSS-бэклог. Если у вас другой стек детекции и хочется обсудить, как адаптировать приоритизацию экспозиций и detection-правила под конкретный SIEM, - на codeby.net есть тред, где коллеги делятся опытом перехода от VM к exposure management.
