Собирательный пример из нескольких проектов по встраиванию CTEM в финансовых организациях. Автономная платформа за сутки просканировала порядка 14 000 хостов и вернула около 2 300 экспозиций. Ручная red team-проверка той же инфраструктуры за две недели обнаружила 9 подтверждённых цепочек с выходом на критические активы - платформа нашла 4 из них. Оставшиеся 5 потребовали vishing на helpdesk, эксплуатации бизнес-логики платёжного API и нестандартной AD-цепочки через промежуточные хосты с делегированием.
Четыре из девяти - это много или мало? Зависит от того, как на это смотреть. Платформа отработала за ночь то, что у живой команды заняло бы три дня только на разведку. Но пять цепочек она не увидела в принципе - и не увидит, пока не научится звонить в helpdesk и прикидываться новым сотрудником. Вопрос не в том, что лучше - автономная платформа или пентестер. Вопрос в том, как собрать из обоих непрерывный процесс, который Gartner обозначил аббревиатурой CTEM.
Программа CTEM: пять этапов и роль автономного пентеста в Validation
Программа CTEM пять этапов - Scoping, Discovery, Prioritization, Validation, Mobilization - описана в русскоязычных источниках подробно. Но почти все обходят стороной главный вопрос: что конкретно происходит на этапе Validation и чем его закрывать.Scoping определяет границы цикла и требует участия бизнеса - автоматизировать этот этап невозможно. Discovery хорошо закрывается ASM-инструментами и сканерами уязвимостей. Prioritization опирается на данные о критичности активов, threat intelligence и эксплуатируемость - автоматика помогает, но бизнес-контекст вносит человек. Mobilization - оркестрация исправлений через SOAR, тикет-системы и кросс-функциональное взаимодействие.
А вот Validation - этап, ради которого и существуют автономные платформы пентеста. Сканер говорит: «Есть CVE с CVSS 9.8». Validation отвечает на другой вопрос: «Можно ли через эту уязвимость реально дойти до платёжной системы?» По данным вендорских отчётов XM Cyber (конкретный отчёт и год публикации не верифицированы независимо), у крупных предприятий может быть более 250 000 открытых уязвимостей, при этом компании закрывают только около 10% из них. Лишь 2% ведут к критическим ресурсам. Эти цифры не подтверждены независимыми исследованиями - но даже если погрешность двукратная, масштаб понятен: закрывать всё подряд бессмысленно. Задача Validation - найти именно эти 2%.
Три подхода к Validation:
- Ручной пентест / red team - пентестер строит цепочку атаки вручную, комбинируя техники от initial access до цели. Долго, дорого, но покрывает то, что автоматика не видит.
- Автономные платформы пентеста (Pentera, Horizon3.ai NodeZero, RidgeBot) - автоматически эксплуатируют уязвимости в продуктивной среде и выстраивают цепочки атак без предопределённых сценариев.
- Breach and Attack Simulation (Cymulate, Picus, SafeBreach) - воспроизводят заранее заданные сценарии для проверки детектирующих контролей.
Автономные платформы пентеста vs ручной red team: непрерывная проверка защищённости
Что покрывают автономные платформы
Автономные платформы решают главную проблему классического подхода: периодичность. Ручной пентест проводится раз в квартал или раз в год. Между проверками инфраструктура живёт своей жизнью - появляются новые сервисы, уходят старые сотрудники вместе со знанием мисконфигураций, кто-то втихую открывает порт «на пять минут» и забывает закрыть. Автономная платформа запускается еженедельно или по событию (деплой, изменение сетевого сегмента, публикация критического CVE) - и закрывает этот frequency gap.По маркетинговому описанию Horizon3.ai, их платформа NodeZero «автономно принимает перспективу атакующего без заранее определённых скриптов или предположений», выстраивая цепочки через обнаруженные слабые места. На практике автономность ограничена базой известных эксплойтов и заложенными паттернами атак - по документам автономия, на практике всё-таки рельсы. Но рельсы хорошие. Вот что платформы этого класса покрывают уверенно:
- Network Service Discovery (T1046, Discovery) - обнаружение сервисов, портов, протоколов
- Vulnerability Scanning (T1595.002, Reconnaissance) - идентификация и верификация уязвимостей
- Brute Force (T1110, Credential Access) - перебор учётных данных на обнаруженных сервисах
- Exploit Public-Facing Application (T1190, Initial Access) - эксплуатация известных уязвимостей
- Exploitation of Remote Services (T1210, Lateral Movement) - боковое перемещение через стандартные эксплойты
Ограничения автоматики в валидации угроз безопасности
Самые разрушительные атаки строятся на том, что автономные платформы пока не умеют. И тут начинается самое интересное.Социальная инженерия. Ни одна автономная платформа не позвонит в helpdesk, не отправит фишинговое письмо с контекстом, не проведёт vishing. Техника Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation) в реальных инцидентах нередко начинается с социального вектора, а не технического. Автономная платформа может проверить слабые пароли, но не получит credentials через pretexting. (Здесь и далее маппинг конкретных техник ATT&CK на поведение платформ - авторская интерпретация, основанная на наблюдениях в проектах, а не официальная классификация вендоров.)
Бизнес-логические уязвимости. Если приложение позволяет перевести деньги с чужого счёта через манипуляцию параметров API - это не CVE и не мисконфигурация. Автономная платформа не знает, «как должно работать приложение», поэтому не обнаружит отклонения. На одном проекте мы нашли IDOR в платёжном API, который позволял менять получателя перевода подменой одного параметра. Ни один сканер этого не увидит - нужен человек, который понимает бизнес-процесс.
Сложные AD-цепочки. Kerberoasting → AS-REP Roasting → ACL abuse → DCSync - платформа может выполнить каждый шаг по отдельности, но сборка нестандартной цепочки через промежуточные хосты с учётом конкретной топологии AD требует человеческой креативности. Когда нужно прыгнуть через три хоста с constrained delegation, чтобы добраться до DC - это уже шахматы, а не перебор. [Применимо: внутренний пентест, AD-инфраструктура]
Эксплуатация 0-day и сложных N-day. Автономные платформы работают по базе известных эксплойтов. Если эксплойта нет в базе - уязвимость не будет провалидирована, даже если она критична. А в реальном пентесте бывает так: видишь нестандартное поведение сервиса, копаешь час - и находишь RCE, которого нет ни в одной базе.
Физический доступ и insider-сценарии. Подключение к сети через незащищённый порт в переговорной, USB-drop на парковке - за пределами автоматики.
Ниже - trade-off таблица по ключевым критериям. Данные основаны на маркетинговых материалах вендоров и практическом опыте интеграции, не на независимых бенчмарках.
| Критерий | Автономные платформы (Pentera, NodeZero, RidgeBot) | Ручной пентест / red team |
|---|---|---|
| Частота проверок | Еженедельно / по событию | Раз в квартал - раз в год |
| Время на полный цикл | Часы - сутки | Дни - недели |
| Покрытие известных CVE | Высокое (по базе эксплойтов) | Выборочное (пентестер приоритизирует) |
| Социальная инженерия | Нет | Да |
| Бизнес-логика | Нет | Да |
| Сложные AD-цепочки | Частично (стандартные паттерны) | Да (включая нестандартные) |
| Стоимость | Годовая лицензия, масштабируется по хостам | Проектная оплата, зависит от скоупа |
| Масштабируемость | Высокая (тысячи хостов параллельно) | Низкая (ограничена командой) |
| Интеграция в CI/CD | Нативно (API, webhooks) | Через отчёты и тикеты |
| Отчётность для руководства | Автоматизирована | Ручная |
Breach and Attack Simulation vs автоматизированный пентест в контексте CTEM
BAS и автономный пентест часто путают, но они решают разные задачи внутри программы CTEM. Путать их - всё равно что путать crash test и угон: оба про автомобиль, но вопросы задают разные.BAS (Cymulate, Picus, SafeBreach) - проверяет, сработают ли детектирующие контроли на известный сценарий. По терминологии ряда вендоров и аналитиков (в частности, Picus Security), технологии Adversarial Exposure Validation (AEV) комбинируют BAS и автоматизированный пентест для оценки эксплуатируемости и эффективности контролей. BAS задаёт вопрос: «Увидит ли SIEM/EDR атаку типа X?»
Автономный пентест задаёт другой вопрос: «Можно ли проникнуть в сеть и дойти до критических активов?» Платформа не знает заранее, каким будет путь - она выстраивает его сама на основе обнаруженных уязвимостей.
Ручной red team задаёт третий вопрос: «Что может сделать мотивированный злоумышленник с неограниченной креативностью?»
| Критерий | BAS | Автономный пентест | Ручной red team |
|---|---|---|---|
| Подход | Детерминированные сценарии | Автономная эксплуатация | Творческие цепочки атак |
| Цель | Проверка контролей (SIEM/EDR/WAF) | Доказательство эксплуатируемости | Полная имитация противника |
| Частота | Непрерывно | Еженедельно - ежемесячно | Раз в квартал - год |
| Безопасность для прода | Высокая (симуляция без эксплуатации) | Средняя (safe exploitation) | Контролируемая (по RoE) |
| Типичный результат | «Контроль X не сработал на технику Y» | «Цепочка атаки до актива Z подтверждена» | «Получен Domain Admin за 3 дня через SE» |
В зрелой программе CTEM все три подхода сосуществуют. BAS работает непрерывно и тестирует контроли. Автономный пентест запускается регулярно и подтверждает эксплуатируемость. Ручной red team закрывает сценарии, недоступные автоматике. Выкинуть любой из трёх - получить слепое пятно.
Приоритизация уязвимостей CTEM через покрытие MITRE ATT&CK
При внедрении continuous threat exposure management нужно понимать, какие техники атакующих покрываются автоматически, а какие требуют ручной валидации. Ниже - маппинг на основе наблюдаемого поведения платформ в реальных проектах. Это авторская интерпретация, а не официальная классификация вендоров - вендоры, понятное дело, нарисуют себе покрытие пошире.| Техника MITRE ATT&CK | Тактика | Автономная платформа | Ручной пентест | Комментарий |
|---|---|---|---|---|
| Active Scanning (T1595) | Reconnaissance | Полностью | Полностью | Базовая функция обоих |
| Vulnerability Scanning (T1595.002) | Reconnaissance | Полностью | Частично | Платформа сканирует весь скоуп, пентестер фокусируется |
| Exploit Public-Facing Application (T1190) | Initial Access | Частично | Полностью | Платформа ограничена базой эксплойтов |
| Network Service Discovery (T1046) | Discovery | Полностью | Полностью | Автоматика масштабируется лучше |
| System Information Discovery (T1082) | Discovery | Полностью | Полностью | Стандартная разведка |
| Valid Accounts (T1078) | Initial Access, Persistence, Priv Esc | Частично (через T1110 brute force как предпосылку; сама T1078 автономно не покрывается) | Полностью (включая SE) | Социальный вектор - только вручную |
| Brute Force (T1110) | Credential Access | Полностью | Частично | Платформа проверяет больше сервисов |
| Exploitation of Remote Services (T1210) | Lateral Movement | Частично | Полностью | Нестандартные цепочки - только руками |
Закономерность видна невооружённым глазом: автономные платформы сильны в Reconnaissance и Discovery, уверенно покрывают Credential Access через brute force, но для Initial Access через социальную инженерию и сложного Lateral Movement нужен пентестер. Приоритизация уязвимостей CTEM на основе этого маппинга позволяет точнее распределять ресурсы: автоматике - то, что она делает лучше и чаще, ручным проверкам - то, что требует контекста и креативности.
Управление поверхностью атаки: интеграция ASM, автономного пентеста и ручных проверок
Управление поверхностью атаки (ASM) отвечает на вопрос «что у нас есть». Автономный пентест - «что из этого эксплуатируемо». Ручная проверка - «что из этого приводит к реальному ущербу». Связка трёх компонентов закрывает этапы Discovery, Prioritization и Validation программы CTEM.Практическая архитектура:
- ASM-инструмент (Randori, CyCognito, или связка
nuclei+httpx+subfinderдля команд с ограниченным бюджетом) непрерывно обнаруживает внешние активы и передаёт результаты в CMDB или asset inventory. - Автономная платформа получает перечень активов через API и запускает валидацию по расписанию (еженедельно) или по триггеру (новый актив, публикация критического CVE - зависит от интеграций конкретного вендора). Результаты - подтверждённые цепочки атак - уходят в SIEM/SOAR.
- Ручной пентест / red team проводится по графику (раз в квартал для критичных сегментов) и по запросу (после крупных изменений в инфраструктуре). Фокус - социальная инженерия, бизнес-логика, сложные AD-цепочки.
Код:
index=ctem_findings source IN ("pentera", "nodezero", "manual_pentest")
| stats count as finding_count by source, severity, asset_criticality
| sort -finding_countjoin - она деградирует по производительности. Используйте stats + lookup или Data Model Acceleration. Для корреляции с asset inventory лучше работать через inputlookup с предварительно построенным CSV-кэшем из CMDB.Decision tree: когда автоматики достаточно для проверки киберзащищённости
Выбор подхода зависит от типа инфраструктуры и модели угроз:- Типовые сервисы (веб, почта, VPN, VDI). Автономная платформа достаточна для регулярной валидации. Ручной пентест - раз в полгода для подтверждения. [Применимо: внешний и внутренний пентест, modern-инфраструктура]
- Кастомные приложения (процессинг, ERP, внутренние API). Автономная платформа покрывает сетевой и инфраструктурный слой. Для прикладного уровня обязателен ручной пентест с фокусом на бизнес-логику. [Применимо: внутренний пентест, любая инфраструктура]
- AD-инфраструктура. Автономная платформа проверяет стандартные мисконфигурации - Kerberoasting, AS-REP Roasting, unconstrained delegation. Сложные ACL-цепочки, cross-forest атаки и сценарии с compromised credentials - ручной пентест. [Применимо: внутренний пентест, AD-окружение]
- Облачные среды (AWS / Azure / GCP). Автономная платформа + CSPM для конфигурационных проверок. IAM-цепочки и cross-account movement - ручная валидация. Тут автоматика пока откровенно слаба - слишком много вендор-специфичных нюансов.
- OT/SCADA-сегменты. Автономные платформы, как правило, не поддерживают промышленные протоколы (Modbus, DNP3) и не адаптированы для сред, где сканирование может вызвать остановку процесса. Только ручной пентест с согласованными RoE. Без вариантов.
Метрики при внедрении continuous threat exposure management
Отдельно про ROI: в маркетинговых материалах XM Cyber упоминаются вендорские TEI-отчёты о значительном снижении вероятности инцидентов и высоком ROI, однако существование и содержание конкретного отчёта Forrester TEI не верифицированы независимо - экстраполировать на весь класс автономных решений некорректно.
Два с половиной года я встраиваю автономные платформы в процессы CTEM у заказчиков и вижу одну и ту же ошибку. Организация покупает Pentera или NodeZero, запускает еженедельные сканы, получает красивые дашборды с confirmed attack paths - и искренне считает, что этап Validation закрыт. Risk Reduction Rate на графике растёт, всё зелёное, руководство довольно.
А потом приходит ручной red team и за неделю получает Domain Admin через цепочку, которую ни одна платформа не тестировала: vishing на helpdesk → сброс пароля сервисному аккаунту → VPN-доступ → ACL abuse в AD через промежуточный хост.
Всё красиво работает, пока атакующий играет по правилам, заложенным в базу платформы. Реальный злоумышленник по этим правилам не играет.
Это не значит, что автономные платформы бесполезны - они критически важны для закрытия frequency gap. Ежеквартальный ручной пентест оставляет 90 дней слепой зоны, автономная платформа сокращает её до недели. Но подменять одно другим - значит создавать иллюзию защищённости, которая хуже, чем честное «мы этот вектор не проверяли».
Зрелая программа CTEM - это не выбор между автоматикой и человеком. Это чёткое понимание: значительная часть экспозиций - тупики (по данным XM Cyber, в их отчётах фигурирует цифра 75% - это отдельная метрика от «2% ведут к критическим активам», характеризующая долю путей атаки, не достигающих ценных ресурсов). Автоматика находит тупики быстро. Пентестер находит пути, которых автоматика не видит. Попробуйте прогнать свою инфраструктуру через автономную платформу, а потом дайте те же хосты живой команде - разница в результатах покажет, где у вас слепые пятна. На WAPT эту связку разбирают в модулях по методологии с лабами на реальных конфигурациях.
