EASM vs vulnerability management vs пентест: разбор

Понедельник, 09:15. Дашборд SOC финтех-компании - ноль критических алертов. VM-сканер штатно молотит: 14 000 активов в скоупе, SLA по критическим CVE выдерживается. Пентест полугодовой давности закрыт отчётом без критичных findings. К 09:40 уже поднята команда incident response: вектором входа оказался забытый dev-поддомен с Jenkins без аутентификации. Хост не существовал ни в CMDB, ни в скоупе сканера, ни в скоупе пентеста - его подняли для одного спринта три месяца назад и забыли. Атакующие нашли его через Certificate Transparency Logs - техника Search Open Technical Databases (T1596, Reconnaissance) по MITRE ATT&CK. Три инструмента работали параллельно, и ни один не закрыл этот gap.

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

Три подхода к управлению поверхностью атаки​

Вопрос "EASM или VM?" или "зачем пентест, если есть сканер?" - категорийная ошибка. Это не конкурирующие инструменты. Каждый подход отвечает на структурно другой вопрос, и отсутствие любого из них оставляет не уменьшенное покрытие, а конкретную слепую зону, которую оставшиеся два не закроют. Точка. Подробнее - в нашем руководстве по asset management пентест.

Scope сравнения - три базовых метода управления киберрисками, формирующих основу контроля внешней экспозиции. За рамками остаются смежные категории: CAASM (внутренняя корреляция активов), BAS (breach and attack simulation), CSPM (cloud security posture management). Они дополняют тройку, но не заменяют ни один из компонентов.

EASM - обнаружение внешней поверхности атаки​

EASM смотрит на организацию снаружи, глазами атакующего. Инструмент начинает с минимального seed-набора - корневые домены, ASN, название компании - и через DNS-перебор, анализ сертификатов, пассивные источники (Shodan, Censys, Certificate Transparency Logs) строит граф всего, что торчит наружу.

Ключевой вопрос: что существует? Не какие уязвимости на конкретном хосте, а какие хосты принадлежат организации и видны из интернета. Некоторые EASM-платформы (Censys ASM, CyCognito, Detectify, Microsoft Defender EASM) делают поверхностную оценку - CVE по баннеру, устаревший TLS, открытые панели управления - но аутентифицированного CVE-анализа не проводят. Это осознанная граница: EASM передаёт обогащённые данные об активах туда, где ими займётся VM.

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

• M&A: при поглощении компании наследуется вся её инфраструктура - misconfigurations, забытые dev-среды, просроченные сертификаты. В CMDB это попадёт через недели. EASM увидит в первый день.
• Облачная миграция: новые инстансы, storage buckets, API появляются быстрее, чем security-команда их каталогизирует. По данным CrowdStrike Global Threat Report 2025, число cloud intrusion случаев выросло на 26% год к году - и облачные активы чаще всего оказываются именно в зоне, не покрытой CMDB.
• Ребрендинг: legacy-домены и маркетинговые микросайты остаются в DNS после смены бренда. Их почти никогда не удаляют - они просто валяются в инфраструктуре мёртвым грузом.

С точки зрения MITRE ATT&CK, EASM воспроизводит фазу Reconnaissance атакующего: Active Scanning (T1595), Scanning IP Blocks (T1595.001), Gather Victim Network Information (T1590), Gather Victim Host Information (T1592), Search Open Technical Databases (T1596). Разница - EASM делает это непрерывно и в интересах защиты.

Когда EASM отсутствует, VM и пентест наследуют неполный скоуп. Сканер методично закрывает CVE в известном периметре, пока атакующий эксплуатирует забытый dev-стенд, не попавший в реестр. По данным Verizon DBIR 2025, 68% утечек связаны с человеческим фактором - и "забыли внести актив в CMDB" это ровно тот human error, который EASM предотвращает.

Бесплатная точка входа: subfinder + httpx + nuclei community templates дают базовый continuous attack surface management процесс для команд без бюджета. Для начала хватит за глаза.

Vulnerability Management - сканирование уязвимостей и приоритизация​

VM работает с известным реестром активов. Сканер проверяет список целей на наличие известных уязвимостей - версионные отпечатки, уязвимые конфигурации, пропущенные патчи. Коммерческие решения: Tenable, Qualys, Rapid7; из российских - MaxPatrol VM, R-Vision VM, ScanFactory VM, Vulns.io VM.

Ключевой вопрос: что сломано? Какие из известных активов имеют известные уязвимости и в каком порядке их устранять. Приоритизация строится на CVSS, EPSS (вероятность эксплуатации в ближайшие 30 дней), KEV (CISA Known Exploited Vulnerabilities) и бизнес-критичности актива.

EPSS меняет правила игры: вместо статического CVSS-балла (одинакового для всех организаций) EPSS показывает вероятность эксплуатации конкретной CVE в реальном мире. На практике CVE с CVSS 9.8, но EPSS 0.01 можно отложить в пользу CVE с CVSS 7.5 и EPSS 0.95 - потому что вторую уже эксплуатируют. Я видел команды, которые месяцами гасили "девятки" по CVSS, пока через "семёрку" с высоким EPSS уже ходили.

Масштаб проблемы: по данным FIRST, в 2026 году количество CVE может превысить 50 000 - при 39 000 в 2025. По совместному исследованию BI.ZONE и Сбера, Time-to-Exploit сократился в 20 раз за 2,5 года и составляет менее 40 дней. Отчёт Банка России фиксирует: около 28% эксплуатаций в финансовых организациях происходят в первые 24 часа. При этом, согласно IBM X-Force Threat Intelligence Index 2025, среднее время устранения CVE в организациях - 29 месяцев. Разрыв между 24 часами до эксплуатации и 29 месяцами до патча - вот зачем нужна risk-based приоритизация. Без неё VM превращается в бесконечный бэклог, который никто не разгребёт.

Процесс VM в российском контексте опирается на методический документ ФСТЭК РФ от 17.05.2023, определяющий пять этапов: мониторинг уязвимостей -> оценка применимости -> определение методов и приоритетов устранения -> устранение -> контроль. Большинство отечественных VM-платформ выстроены по этой схеме.

Чего VM не делает: не обнаруживает активы за пределами скоупа (хост не в списке - невидимка), не цепляет уязвимости в attack path, не подтверждает реальную эксплуатируемость.

Бесплатная точка входа: OpenVAS (Greenbone Community Edition).

Пентест - валидация через эксплуатацию​

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

С точки зрения MITRE ATT&CK, пентест валидирует переход от Reconnaissance к Initial Access, в частности Exploit Public-Facing Application (T1190). По данным Mandiant M-Trends 2025, exploits - наиболее распространённый вектор начального доступа (38% расследований 2024 года), и именно пентест показывает, какие из обнаруженных CVE реально складываются в attack path до production data.

Continuous pentest сокращает разрыв между проверками с 11 месяцев до непрерывного цикла, но human-led характер ограничивает масштаб: пентест не покроет 50 000 активов с той же экономикой, что автоматический сканер. Это нормально - он и не должен.

Чего пентест не делает: не масштабируется на весь скоуп, не работает непрерывно, устаревает между engagement'ами - CVE, опубликованная через неделю после пентеста, останется непроверенной.

Сравнение подходов: EASM, VM и пентест по ключевым параметрам​

Как три подхода кормят SOC: detection и корреляция​

Для Blue Team ценность каждого подхода определяется не "наличием", а тем, какие данные он отдаёт в SIEM и как их коррелировать. Этот аспект в большинстве сравнительных статей отсутствует полностью, а зря - именно здесь рождается (или умирает) реальная эффективность связки.

EASM -> SIEM: алерты о новых активах, изменениях DNS-записей, открытии портов, смене сертификатов. Корреляционный сценарий: EASM обнаружил новый поддомен - в течение 24 часов EDR зафиксировал сетевую активность с этого IP. Без EASM этот поддомен не попал бы ни в один лог, и алерт EDR остался бы без контекста. Пример правила в Sigma-формате:
VM -> SIEM: приоритизированные CVE с контекстом EPSS и KEV. Корреляция: VM нашёл критическую CVE с EPSS > 0.9 на public-facing активе + в TI-фиде появился exploit для этой CVE -> эскалация без ожидания стандартного SLA. Нюанс, о который спотыкаются многие: если VM не передаёт EPSS-скор в SIEM (а большинство out-of-the-box интеграций этого не делают), такая корреляция невозможна. Проверьте, что реально прилетает в ваш SIEM от VM - там может быть сюрприз.

Пентест → SIEM: ретроспективная настройка detection. Каждый шаг зафиксированного attack path должен получить правило корреляции. Если пентестер прошёл цепочку A -> B -> C, а SOC не сгенерировал ни одного алерта - это gap в detection, не провал пентестера. По данным Mandiant M-Trends 2025, медианное время обнаружения атакующего - 11 дней. Пентест-отчёт, превращённый в detection rules, сокращает это время.

Операционный шов - CTEM: Continuous Threat Exposure Management задаёт последовательность для трёх подходов вместо трёх отдельных строк бюджета: discovery (EASM) -> scoping (новые активы -> CMDB -> VM) -> prioritization (VM + EPSS + KEV) -> validation (пентест / automated exposure validation) -> mobilization (тикеты с SLA). Без формализованного CTEM три подхода генерируют три отдельных отчёта со своими метриками и SLA, а output одного не становится input следующего. Три отчёта - три отдельных мира.

Интеграция реализуется через API (Censys ASM -> Tenable), через CMDB (ServiceNow, Axonius), или через SOAR-playbook, где EASM-алерт автоматически добавляет цель в VM-очередь. Минимально жизнеспособная интеграция - еженедельный CSV-экспорт из EASM в VM. Да, CSV. В 2025 году. Но это лучше, чем ничего.

Скомпрометированные легитимные хосты - общая слепая зона​

Сценарий, не покрываемый ни одним из трёх подходов: легитимный хост из CMDB, прошедший VM-сканирование, включённый в скоуп пентеста - но уже содержащий implant. EASM видит его как "свой", VM показывает "пропатченный", пентестер проверяет уязвимости, а не ищет следы компрометации. Все три говорят "чисто", а внутри уже сидят.

Этот gap закрывает EDR/XDR с поведенческой аналитикой и continuous security validation. Согласно IBM X-Force Threat Intelligence Index 2025, 70% атак затрагивают критическую инфраструктуру - и часть проходит через ранее скомпрометированные легитимные точки входа. 11 дней медианного dwell time по Mandiant - это окно, пока скомпрометированный хост выглядит "чистым" для всех трёх подходов.

Порядок внедрения: чеклист для выбора решения по управлению уязвимостями​

Шаг 4. Свяжите с бизнес-метриками. MTTD (время обнаружения) и MTTR (время устранения) - единственные метрики, которые оправдывают бюджет перед руководством. Согласно IBM Cost of a Data Breach Report 2026, средняя стоимость утечки достигла $4.99M. Регуляторный контекст усиливает аргумент: процесс VM в российских организациях регулируется методическим документом ФСТЭК от 17.05.2023, а оборотные штрафы за утечки персональных данных превращают MTTR из технической метрики в финансовый риск.

Большинство дискуссий об EASM vs vulnerability management vs пентест сводятся к вендорским матрицам фич. На практике проблема в другом: даже при наличии всех трёх подходов между ними нет операционного шва. EASM находит 200 поддоменов - они неделями не попадают в VM. VM генерирует 3 000 тикетов - команда тонет без понимания реальной эксплуатируемости. Пентест проводится раз в год по скоупу, согласованному за два месяца до старта.

Из IR-кейсов, которые я разбирал за последние пару лет, в каждом втором проблема была не в отсутствии инструмента, а именно в этих швах. Данные EASM не доходили до VM, результаты VM не учитывались при определении скоупа пентеста, а findings пентеста не превращались в detection rules для SOC. Шов между подходами - самое недооценённое место для инвестиции и времени, и бюджета. Если в вашей команде стыковка EASM с VM-платформой устроена иначе - на codeby.net есть тред, где обсуждают конкретные схемы интеграции и типовые грабли при маппинге активов.