EASM и Vulnerability Management: совместный процесс

Почему EASM и VM работают эффективнее вместе

Vulnerability Management — зрелая дисциплина. Компании умеют сканировать известную инфраструктуру, получать CVE-отчёты, расставлять приоритеты по CVSS и закрывать тикеты на патч-установку. Проблема в слове «известную». Программы сканирования работают только с тем, что есть в реестре активов. А что попало в реестр — то и проверяется.

EASM (External Attack Surface Management) решает ровно ту часть задачи, которую VM не покрывает: непрерывное обнаружение активов, которые вы не знали, что у вас есть. Забытые субдомены, тестовые стенды с открытыми портами, облачные бакеты без аутентификации, сторонние сервисы с устаревшим сертификатом — всё это существует за пределами вашего реестра и, соответственно, за пределами вашего сканера уязвимостей.

Когда EASM и VM работают порознь, результат предсказуем: VM методично устраняет уязвимости в известном периметре, пока атакующий эксплуатирует забытый dev-стенд, который никогда не попадал ни в один реестр. Именно поэтому интеграция двух процессов — не опциональное улучшение, а необходимое условие реальной защиты внешнего периметра.

Что делает каждый инструмент: зоны ответственности

EASM: видимость внешней поверхности атаки

EASM смотрит на вашу организацию глазами атакующего: снаружи, без предварительного знания о том, что внутри. Инструмент начинает с минимального сид-набора — корневых доменов, диапазонов AS-номеров, названия компании — и через DNS-перебор, анализ сертификатов, пассивные источники (Shodan, Censys, Certificate Transparency Logs) выстраивает граф всего, что доступно извне. Результат — непрерывно обновляемая карта внешней поверхности атаки: домены, поддомены, IP-адреса, открытые порты и сервисы, облачные ресурсы, технологический стек каждого актива.

EASM не копает вглубь уязвимостей: его задача — обнаружить и категоризировать. Некоторые решения делают поверхностную оценку рисков (устаревший TLS, CVE по баннеру сервиса), но полноценного CVE-анализа с эксплойт-проверкой — не проводят. Это осознанная граница: EASM передаёт обогащённые данные об активах туда, где ими займутся специалисты VM.

Vulnerability Management: приоритизация и устранение

VM-процесс — это жизненный цикл от обнаружения уязвимости до её верификации после устранения. Он включает аутентифицированное и неаутентифицированное сканирование, сопоставление результатов с базами CVE, приоритизацию по CVSS, EPSS и KEV, назначение тикетов на исправление, контроль сроков и повторное сканирование для подтверждения закрытия. В отличие от EASM, VM работает с известным реестром: именно поэтому расширение этого реестра через данные EASM напрямую увеличивает покрытие VM-программы.

Где заканчивается EASM и начинается VM

Граница между двумя процессами — это момент, когда неизвестный актив становится известным и попадает в реестр. До этой точки работает EASM: обнаружение, атрибуция (кому принадлежит актив?), первичная категоризация риска. После этой точки — VM: аутентифицированное сканирование, CVE-анализ, приоритизация, устранение.

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

Совместный процесс: как выстроить интеграцию

Шаг 1 — Обнаружение активов через EASM

EASM запускается с сид-данными: корневые домены, диапазоны IP, названия дочерних компаний и брендов, ASN. Инструмент строит граф смежности: DNS-записи → поддомены → IP → открытые порты → технологический стек. Важно настроить регулярность обнаружения: внешняя поверхность атаки меняется постоянно — разработчики поднимают новые окружения, появляются новые API, поглощения добавляют чужую инфраструктуру. Оптимальная частота — непрерывный мониторинг или как минимум ежедневный. Каждое изменение фиксируется как событие: новый актив, изменение открытых портов, новый сертификат, смена технологического стека.

Шаг 2 — Передача активов в VM-реестр

Это ключевой технический шов между двумя процессами. Новые активы из EASM должны попадать в CMDB или напрямую в VM-платформу (Tenable, Qualys, Rapid7) — либо через API-интеграцию, либо через экспорт в CMDB с последующей синхронизацией. На этом шаге важна атрибуция: актив должен быть привязан к владельцу (команде или подразделению), иначе устранять уязвимость будет некому. Автоматическая атрибуция через DNS-зоны, теги облачных ресурсов и WHOIS-данные — это минимальный уровень зрелости; лучший вариант — CI/CD-теги и связь с командами через ServiceNow или аналог.

Шаг 3 — Сканирование и приоритизация уязвимостей

После попадания актива в реестр VM запускает сканирование — как минимум неаутентифицированное (для внешних активов), желательно аутентифицированное (для получения полного CVE-профиля). Результаты сканирования приоритизируются по комбинированной метрике: базовый CVSS, эксплойт-зрелость через EPSS, факт активной эксплуатации через KEV (CISA Known Exploited Vulnerabilities), а также бизнес-критичность актива — публичный веб-сервис важнее внутреннего инструмента. Контекст из EASM обогащает приоритизацию: если EASM видит, что этот актив обнаруживается из 15 разных поисковых индексаторов и имеет открытый порт 22 — это повышает риск выше, чем просто CVSS-балл уязвимости.

Шаг 4 — Устранение и верификация

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

Технические точки интеграции

Интеграция EASM и VM технически реализуется через несколько возможных точек. Выбор зависит от зрелости инфраструктуры и наличия CMDB.

API-интеграция напрямую. EASM-платформа экспортирует обнаруженные активы через REST API в VM-платформу (Tenable.io, Qualys VMDR, Rapid7 InsightVM). Новые активы автоматически добавляются в цели сканирования. Это наиболее чистая архитектура, доступная у большинства зрелых платформ: Censys ASM → Tenable, CyCognito → Qualys. Минус — требует настройки маппинга полей и управления дублями.

Через CMDB как единый реестр. EASM пишет в CMDB (ServiceNow, Axonius, Lansweeper), VM читает из него. CMDB становится единым источником правды об активах: EASM добавляет внешние активы, внутренние инструменты добавляют внутренние, а VM получает полный консолидированный список. Это лучший подход с точки зрения операционной зрелости, но требует настроенного CMDB — что само по себе нетривиально.

Через SIEM или платформу оркестрации. Если в организации используется SIEM (Splunk, Microsoft Sentinel, KUMA) или SOAR, EASM-события о новых активах могут триггерить playbook: автоматически добавить актив в очередь сканирования VM и создать тикет с атрибуцией. Это увеличивает скорость реакции до часов вместо ручных дней.

Инструменты для связки EASM + VM

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

EASM-инструменты: Censys ASM, CyCognito, Detectify, Mandiant ASM, Outpost24, BI.ZONE Attack Surface Management (для российского рынка). Каждый отличается глубиной пассивной разведки, качеством атрибуции и наличием готовых интеграций с VM-платформами.

VM-платформы: Tenable.io / Tenable One, Qualys VMDR, Rapid7 InsightVM, Wiz (для облачных сред), MaxPatrol VM (российский рынок, сертифицирован ФСТЭК). Все ведущие платформы имеют API для импорта активов и поддерживают интеграцию с внешними источниками данных.

Платформы, совмещающие EASM и VM: Tenable One, Qualys TotalCloud, Palo Alto Cortex Xpanse (EASM) + XSOAR (оркестрация) стремятся закрыть весь цикл в рамках одного вендора. Это упрощает интеграцию, но создаёт vendor lock-in. Для организаций, только начинающих путь, имеет смысл — для зрелых ИБ-команд часто предпочтительнее лучший-в-классе подход с открытыми API.

Метрики совместного процесса

Измерение эффективности интеграции EASM и VM — отдельная задача, которую часто игнорируют. Когда метрик нет, непонятно, работает ли связка или просто создаёт иллюзию покрытия.

Asset Discovery Rate — доля активов внешнего периметра, обнаруженных EASM и отсутствовавших в исходном реестре VM. Растёт на старте, стабилизируется при зрелом процессе. Резкий скачок — сигнал о расширении периметра (новое облако, поглощение, большой деплой).

Time-to-Scan (TtS) — время от обнаружения актива в EASM до первого сканирования в VM. Целевой показатель для критичных активов — менее 24 часов. Если TtS превышает неделю, интеграция де-факто не работает.

External Coverage Gap — процент активов, видимых EASM, которые не включены в регулярное VM-сканирование. Это прямой показатель слепых пятен. Цель — стремиться к нулю; реалистичный ориентир для зрелых команд — менее 5%.

Mean Time to Remediate External Vulnerabilities (MTTREV) — среднее время от обнаружения уязвимости на внешнем активе (найденном EASM) до подтверждённого устранения. Сравнивается с общим MTTR по всему реестру — если MTTREV выше, значит внешние активы обрабатываются медленнее, что особенно опасно.

Роли и ответственность в процессе

Один из главных организационных барьеров совместного процесса — разная «прописка» двух функций. EASM нередко живёт у команды threat intelligence или у red team, VM — у blue team или у IT-операций. Когда нет явного владельца точки интеграции, данные теряются именно на стыке.

Владелец EASM-процесса отвечает за актуальность сид-данных, регулярность обнаружения и качество атрибуции активов. Обычно это специалист по vulnerability management или TI-аналитик с расширенными задачами. Владелец VM-процесса принимает активы из EASM и обеспечивает их включение в цикл сканирования. Владельцы активов (DevOps, инфраструктурные команды) отвечают за устранение в рамках согласованных SLA. Роль CISO — обеспечить, чтобы все три роли были назначены и ответственность не размывалась.

В небольших командах одна и та же команда нередко владеет обоими процессами — это упрощает интеграцию, но требует явной регламентации: иначе EASM и VM де-факто работают как две отдельные задачи одного человека, а не как единый процесс. Совместный процесс хорошо вписывается в рабочую модель внедрения VM с нуля — особенно если EASM внедряется параллельно с VM, а не после.

Читайте также:

• EASM: что это и как работает управление поверхностью атаки
• CVSS, EPSS и KEV: как правильно приоритизировать уязвимости
• Как внедрить Vulnerability Management в компании