Attack Surface Management (ASM): как управлять поверхностью атак организации

07.07.2026

Алексей Мишаев

Автор

В современных инфраструктурах поверхность атаки растёт быстрее, чем компании успевают её контролировать. От маркетинговых кампаний остаются неучтённые поддомены. Разработчики забывают о развёрнутых тестовых стендах. Бывает даже, что без ведома ИБ-службы в прод попадают API. Данные и сервисы «размазаны» по публичным и частным облакам, CI/CD-пайплайнам. Каждый новый микросервис, каждая интеграция с партнёром, провайдером или подрядчиком добавляют новые точки входа.

Именно поэтому бизнесу нужны решения, которые устраняют угрозы неизвестных активов и неконтролируемой поверхности атаки. В этом материале Кибер Медиа с экспертами обсудит, как такой класс технологий работает в нынешних условиях.

Содержание

Что такое ASM на верхнем уровне

Attack Surface Management (ASM) — это непрерывный процесс обнаружения, классификации, приоритизации и мониторинга всех цифровых активов организации, которые доступны потенциальному атакующему из внешней или внутренней среды. Ключевое слово здесь — «непрерывный». ASM представляет собой постоянный цикл: сканирование, обнаружение, верификация, приоритизация, устранение и повторное сканирование.

Сама по себе поверхность атаки объединяет все точки взаимодействия, через которые злоумышленник может попытаться проникнуть в инфраструктуру. Сюда входят API, веб-формы, облачные бакеты, репозитории кода, DNS-записи, SSL-сертификаты, а также человеческий фактор (учётные записи сотрудников, подрядчиков и т.д.).

Дмитрий Бабич

Ведущий инженер отдела сопровождения информационных систем UDV Group

Актуальность ASM сегодня обусловлена быстрым ростом распределенных инфраструктур, что приводит к тому, что периметр компании постоянно меняется и размывается. В таких условиях статические инструменты и разовые аудиты не успевают за изменениями.

Традиционная инвентаризация (CMDB, Excel, ручной ввод) смотрит на инфраструктуру изнутри. Данные поступают из ручного добавления, агентов или интеграций с облачными API, поэтому покрываются только зарегистрированные и внесённые в учёт активы. Актуальность такой инвентаризации зависит от периодичности обновления — недели или даже месяцы. Бизнес-контекст часто отсутствует или устарел.

ASM же смотрит на инфраструктуру глазами атакующего — «что видно из интернета». Источником данных становится пассивная разведка в сочетании с активным сканированием. Благодаря этому ASM обнаруживает все активы, которые можно найти извне, включая теневые ИТ, которые никогда не попадали в официальные реестры. Мониторинг ведётся непрерывно, с актуализацией в течение часов, если не минут.

Именно такая перспектива делает ASM не просто «ещё одним сканером уязвимостей», который проверяет известный ему список IP-адресов. ASM сначала этот список находит — в том числе те адреса, о которых сама компания могла забыть.

Какие задачи решает Attack Surface Management

Зрелая реализация ASM образует замкнутый цикл, который включает в себя три ключевых направления.

Первая задача — инвентаризация активов. Нужно обнаружить все цифровые активы организации, доступные из внешней сети. В скоуп входят домены и поддомены, в том числе делегированные подрядчикам и неиспользуемые; IP-адреса и подсети; открытые порты и сетевые сервисы; облачные инстансы и бакеты; API-эндпоинты; SSL-сертификаты и DNS-записи; репозитории кода; приложения и сервисы. Результатом становится единая карта, где каждый актив привязан к бизнес-подразделению, команде или конкретному владельцу.

Вторая задача — обнаружение уязвимостей и небезопасных конфигураций (Exposure Assessment). После того как активы найдены, ASM оценивает их с точки зрения безопасности. Проверяются известные уязвимости (CVE) — сканирование на наличие эксплуатируемых уязвимостей с привязкой к версиям ПО. Выявляются небезопасные конфигурации: публичные панели администратора, ненужные сервисы (FTP, Telnet), слабые протоколы шифрования. ASM проверяет, не фигурируют ли email-адреса сотрудников или хеши паролей в публичных утечках. Ищутся публично доступные секреты — API-ключи, токены, пароли, случайно отправленные в Git-репозитории. Анализируются открытые порты и сервисы, определяются лишние точки входа. Компания получает оценку каждого актива: насколько он открыт для атак и какие векторы атаки существуют.

Николай Клендар

Директор по информационной безопасности Бастиона

Для сбора информации об активах используются разные методы. Во-первых, ручной ввод диапазонов IP-адресов, чтобы не тратить много времени на сканирование. Во-вторых, трансфер внешней DNS-зоны, который позволяет получить точную картину публично доступных интернет-ресурсов компании. Кроме того, важно отслеживать регистрацию DNS-записей, соответствующих маскам корпоративных доменных имен, а также анализировать TLS-сертификаты с именами, похожими на корпоративные. Все это позволяет обнаружить забытые, устаревшие или скрытые серверы, которые злоумышленники будут искать в первую очередь.

Третья задача — приоритизация и устранение. Это самая критичная задача, отделяющая зрелый ASM: найденные уязвимости и проблемы ранжируются не только по CVSS, но и с учётом эксплуатируемости. Учитывается критичность актива для бизнеса, а также какую информацию содержит актив — персональные данные, коммерческую тайну, банковские реквизиты. Анализируется возможность эскалации: может ли компрометация этого актива привести к захвату других систем (например, сервер доменной аутентификации).

В экосистеме ASM существует несколько подвидов и смежных концепций. EASM (External Attack Surface Management) фокусируется на внешней поверхности атаки — видимой из интернета: обнаружение поддоменов, открытых портов, публичных облачных ресурсов, теневых ИТ. CAASM (Cyber Asset Attack Surface Management) занимается внутренней поверхностью атаки, объединяя данные из существующих систем — CMDB, EDR, облачных контроллеров — в единую базу активов. DRPS (Digital Risk Protection Services) обеспечивает мониторинг внешних угроз: даркнет, Telegram-каналы, фишинговые домены, поиск упоминаний бренда в утечках и скомпрометированных учётных данных. Наконец, CTEM (Continuous Threat Exposure Management) — это процессная надстройка над EASM, CAASM и системами управления уязвимостями, которая организует непрерывный цикл обнаружения, верификации, приоритизации и устранения экспозиции.

При выборе решения ASM нужно смотреть на способность решать три описанные задачи в непрерывном режиме — и интегрироваться с Threat Intelligence, CMDB и системами управления инцидентами.

ASM в экосистеме кибербезопасности

Максимальная эффективность ASM достигается только при интеграции с другими системами кибербезопасности. Самая очевидная — с системами управления уязвимостями (Vulnerability Management, VM). Классический сканер уязвимостей работает по предоставленному ему списку активов. Если актива в списке нет, он его не проверит. ASM решает эту проблему, поставляя в VM-систему актуальный и постоянно обновляемый перечень всех внешних (и внутренних) активов. В обратную сторону VM-система возвращает детальные данные об уязвимостях на этих активах: CVE, CVSS-оценки, наличие эксплойтов, возможные векторы атак. В результате ASM получает не просто «актив есть», а «актив есть, и вот его проблемы».

Вторая критическая интеграция — с SIEM, XDR или EDR. Интеграция с ASM обогащает события безопасности контекстом о поверхности атаки. Например, SIEM видит подозрительный трафик на IP-адрес, который не числится в CMDB, но ASM подтверждает, что это легитимный тестовый сервер разработчиков. Тогда аналитик SOC получает критически важную информацию для принятия решения. И наоборот — если ASM обнаруживает новый неизвестный актив, это само по себе может быть триггером для создания инцидента в SIEM.

Идём дальше — интеграция с SOAR (оркестрация и автоматизация реагирования). ASM плохо подходит для автоматического устранения уязвимостей. SOAR же может принимать данные от ASM и запускать плейбуки: например, при обнаружении открытого RDP-порта на критическом сервере автоматически создать тикет в Service Desk, отправить уведомление владельцу актива и инициировать проверку конфигурации firewall. Без SOAR вся эта рутина ложится на плечи ИБ-специалистов.

Дмитрий Бабич

Ведущий инженер отдела сопровождения информационных систем UDV Group

Приоритизация рисков в ASM строится на сочетании роли актива в инфраструктуре, его доступности, наличия эксплойтов и потенциального влияния на бизнес. Наиболее опасны не просто критические уязвимости, а те, что затрагивают публично доступные или слабо контролируемые сервисы с высокой связностью внутри инфраструктуры. Именно они формируют наибольший уровень риска.

Важно обеспечить обмен данными с CMDB и системами управления активами. Если ASM находит актив, которого нет в CMDB, это означает, что процесс учёта активов дал сбой. CMDB предоставляет ASM критически важный бизнес-контекст: какой актив относится к какому подразделению, кто его владелец, насколько он критичен для бизнес-процессов. Без этого приоритизация, про которую мы говорили раньше, невозможна.

Следующая интеграция — для зрелых организаций, использующих Threat Intelligence (TI). TI-платформы поставляют данные об актуальных угрозах: какие уязвимости сейчас активно эксплуатируются, какие индикаторы компрометации (IP, домены, хеши) связаны с действующими кампаниями атакующих. ASM использует эту информацию, чтобы приоритизировать угрозы: уязвимость, по которой есть эксплойт в дикой природе, получит высший приоритет независимо от её CVSS. Кроме того, ASM может использовать TI для проверки найденных активов на признаки компрометации — например, не замечен ли данный IP в недавних атаках.

Наконец, последний тип важных интеграций — с GRC-системами (Governance, Risk, Compliance). Для ИБ-руководителей важна не столько техническая детализация, сколько доказательства контроля над поверхностью атаки. ASM поставляет объективные, измеримые метрики: количество обнаруженных неизвестных активов, время от появления нового актива до его обнаружения ASM, доля активов, не прошедших сканирование на уязвимости. Эти данные можно использовать для внутренних и внешних аудитов, а также для отчётности перед регуляторами (например, по требованиям к защите ПДн или критической информационной инфраструктуры).

Практика ASM: неочевидные тонкости

На бумаге ASM выглядит как логичный и прозрачный процесс: система сканирует, находит активы, проверяет уязвимости, выдаёт приоритеты, команда устраняет. Однако на практике внедрение и эксплуатация ASM полны нюансов, которые могут свести на нет весь ожидаемый эффект.

Базовый функционал любого ASM-решения — это пассивный сбор данных из открытых источников: WHOIS, DNS-записи, SSL-сертификаты, поисковые системы, публичные API, данные о регистрации доменов. Пассивный метод даёт значительную часть картины, однако этого хватает только при первом приближении.

До 40% активов могут остаться незамеченными при пассивном подходе: бэкенд-сервис без публичного DNS-имени, но с доступным из интернета IP-адресом, тестовый API, веб-интерфейс на нестандартном порту. Чтобы обнаружить такие активы, необходимо активное сканирование — система сама инициирует запросы к инфраструктуре организации, проверяя диапазоны IP, перебирая порты, анализируя ответы на HTTP-запросы.

Николай Клендар

Директор по информационной безопасности Бастиона

Для быстрого старта следует проанализировать все DNS-записи, доступные во внешней DNS-зоне, а также диапазоны IP-адресов, закрепленные за организацией. Также с помощью базового сетевого сканирования нужно выявить службы, доступные из интернета. Уже на этом этапе можно выявить критические сервисы, которых там быть не должно: интерфейсы удаленного управления, например, SSH и RDP, СУБД, NoSQL-хранилища или серверы кеширования. При оценке критичности обнаруженной уязвимости необходимо учитывать, насколько важен данный ресурс для бизнеса, как он связан с другими системами, есть ли готовый эксплоит для этой уязвимости. Также нужно оценить потенциальные действия, которые злоумышленник может совершить после ее обнаружения. Чтобы процесс инвентаризации прошел эффективно, необходимо заранее согласовать с ИТ-отделом допустимые сроки устранения уязвимостей, а также подготовить набор компенсационных мер на случай, если не удается быстро закрыть уязвимость.

Следующая важная деталь связана с приоритизацией. Многие решения выдают список уязвимостей с CVSS-оценками и предлагают «закрыть всё, что выше 7.0». На практике это приводит к перегрузке команды. Грамотные специалисты по безопасности понимают, что не каждая уязвимость с высоким CVSS реально опасна в их конкретном контексте. И наоборот, уязвимость с CVSS 5.5 с активной эксплуатацией может быть критичной.

Зрелая ASM-практика использует комбинированную приоритизацию, учитывающую реальную эксплуатируемость, контекст угроз, критичность актива. Итоговая приоритизация — это всегда взвешенное решение, в котором ASM предоставляет данные и рекомендации, но окончательный вердикт остаётся за командой безопасности, знающей бизнес-контекст.

Как и с любыми другими средствами мониторинга и реагирования, в ASM есть проблема ложных срабатываний. В качественных ASM-решениях с ручной настройкой и постоянной обратной связью от операторов доля ложных срабатываний снижается до приемлемого уровня за первые несколько недель эксплуатации. Но гораздо коварнее проблема избыточных истинных срабатываний, которые сигнализируют о малозначительных проблемах.

ASM может найти сотни реальных недостатков: открытый порт 8080 на тестовом сервере, устаревшая библиотека на лендинге отдела маркетинга, самоподписанный сертификат на внутреннем wiki-сервере. Всё это действительно проблемы, но если команда будет пытаться закрыть их все, она никогда не дойдёт до действительно критических рисков. Решением будет научиться фильтровать информацию. Для этого в ASM-практике должны быть чётко определены пороги: какие активы считаются критическими, какие уязвимости требуют немедленного реагирования (например, наличие публичного эксплойта и доступность из интернета), а какие могут быть занесены в план технического обслуживания на квартал.

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

Это означает, что процесс внедрения ASM должен идти рука об руку с процессом управления активами: для каждого найденного домена, IP-диапазона, облачного бакета должен быть назначен владелец. Если владельца нет, актив подлежит выводу из эксплуатации или передаче на баланс ИТ-команды как бесхозный. Роль ИБ-команды в этом цикле — эскалация и контроль сроков устранения.

Заключение

ASM становится драйвером изменений в процессах управления конфигурациями, управлением изменениями и реагирования на инциденты. Эти решения позволяют посмотреть на инфраструктуру глазами атакующего. Что важнее всего, они помогают расставить приоритеты: что требует закрытия в ближайшие часы, а что может подождать до следующего планового патча.

Эволюция ASM прошла путь от примитивных сканеров портов до зрелых платформ, интегрированных с Threat Intelligence, SIEM, SOAR и CMDB. Сегодняшний уровень зрелости таков, что управлять поверхностью атаки больше не считается «продвинутой практикой». Это базовый стандарт гигиены для любой организации, которая серьёзно относится к своей кибербезопасности.

Для компаний, которые только начинают смотреть в сторону ASM, путь выглядит так. Начать стоит с пилотного проекта для внешней поверхности атаки и оценить масштаб проблемы: сколько неизвестных доменов и IP, какие открытые порты, какие устаревшие сервисы. На основе пилота формируется бизнес-кейс для полноценного внедрения. Следующим шагом нужно наладить интеграции: с системой управления уязвимостями, чтобы закрыть цикл «обнаружение — сканирование — отчёт», с CMDB, чтобы начать процесс назначения владельцев активов, с SOAR или Service Desk, чтобы автоматизировать создание задач на устранение. Параллельно обязательно внедрить регламент: кто отвечает за активы, в какие сроки должны устраняться проблемы разного приоритета, как эскалируется бездействие владельца.

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