Компания может не знать, что уже открыла дверь атакующему

У многих компаний поверхность атаки растет не после большого ИТ-проекта, а почти незаметно.

Маркетинг запускает лендинг и забывает поддомен. Разработчики поднимают тестовый стенд и не выключают его после релиза. Подрядчик получает доступ к сервису, но его учетная запись остается жить дольше самого проекта. В облаке появляется бакет, в Git - токен, на нестандартном порту - панель, о которой никто из ИБ уже не помнит.

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

И вот здесь появляется неприятный разрыв. Компания думает, что управляет инфраструктурой. А атакующий видит больше, чем сама компания.

Периметр больше не похож на забор

Раньше периметр можно было представить почти физически: офис, серверная, межсетевой экран, VPN, несколько внешних сервисов. Сейчас инфраструктура размазана по облакам, подрядчикам, SaaS, CI/CD, внешним API, мобильным приложениям и временным стендам. Новая точка входа может появиться не потому, что бизнес принял стратегическое решение, а потому что команде нужно было быстро проверить гипотезу.

ASM, или Attack Surface Management, как раз появился из этой реальности. Его задача - постоянно смотреть на инфраструктуру глазами атакующего и находить все, что может стать точкой входа. Не один раз в квартал, не перед аудитом, не после инцидента, а в режиме постоянного цикла: обнаружить, проверить, оценить риск, назначить владельца, устранить проблему и снова проверить.

«Актуальность ASM сегодня обусловлена быстрым ростом распределенных инфраструктур, что приводит к тому, что периметр компании постоянно меняется и размывается. В таких условиях статические инструменты и разовые аудиты не успевают за изменениями», - отметил Дмитрий Бабич, ведущий инженер отдела сопровождения информационных систем UDV Group.

Это важный сдвиг. Проблема уже не только в уязвимости как таковой. Проблема в том, что компания может даже не знать о существовании актива, на котором эта уязвимость живет.

Инвентаризация изнутри не показывает всю картину

Классическая инвентаризация смотрит на инфраструктуру изнутри. Что внесли в CMDB, что добавили вручную, что увидели агенты, что передали облачные API, то и считается активом. Такой учет полезен, но он зависит от дисциплины людей и процессов. Если тестовый сервер не зарегистрировали, он может выпасть из поля зрения.

ASM действует иначе. Он начинает не с вопроса «что у нас записано», а с вопроса «что можно найти извне». Проверяются домены и поддомены, DNS-записи, SSL-сертификаты, открытые порты, сетевые сервисы, облачные ресурсы, API, репозитории кода, публичные утечки учетных данных и другие следы присутствия компании в сети.

Именно поэтому ASM не стоит путать с обычным сканером уязвимостей. Сканер проверяет известный ему список адресов. ASM сначала ищет сам список, включая то, что не попало в учет или давно считалось выключенным.

На практике это меняет порядок разговора внутри компании. Уже нельзя ограничиться фразой «у нас все активы учтены». Нужно показать, что внешняя картина совпадает с внутренней. Если ASM нашел домен, IP или сервис, которого нет в CMDB, это не просто техническая находка. Это сигнал, что процесс учета дал сбой.

Опаснее всего не самая высокая оценка CVSS

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

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

«Приоритизация рисков в ASM строится на сочетании роли актива в инфраструктуре, его доступности, наличия эксплойтов и потенциального влияния на бизнес. Наиболее опасны не просто критические уязвимости, а те, что затрагивают публично доступные или слабо контролируемые сервисы с высокой связностью внутри инфраструктуры. Именно они формируют наибольший уровень риска», - пояснил Дмитрий Бабич, ведущий инженер отдела сопровождения информационных систем UDV Group.

Здесь ASM становится не столько инструментом поиска, сколько инструментом выбора. Он помогает понять, что нужно закрыть в ближайшие часы, что можно вынести в плановое окно, а что сначала требует владельца и бизнес-контекста.

Бесхозный актив - это не мелкая проблема учета

У любой найденной точки входа должен быть владелец. Кто отвечает за домен? Какая команда подняла сервер? Для какого процесса работает API? Кто согласует закрытие порта? Можно ли выключить сервис прямо сейчас или он связан с клиентским процессом?

Если этих ответов нет, ИБ-команда оказывается в странном положении. Она видит риск, но не может его устранить. Сервер может принадлежать разработчикам, подрядчику, маркетингу, региональному подразделению или вообще давно уволившемуся сотруднику, который когда-то поднимал стенд для демонстрации.

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

Иначе система будет производить не безопасность, а красивые отчеты. Активы найдены, риски описаны, но открытый RDP, тестовая панель и старый API продолжают жить, потому что никто не считает их своими.

Автоматизация не отменяет здравый смысл

ASM хорошо работает в связке с другими системами. С VM - чтобы проверять найденные активы на уязвимости. С SIEM, EDR или XDR - чтобы обогащать события контекстом. С SOAR или Service Desk - чтобы автоматически создавать задачи на устранение. С CMDB - чтобы связывать найденный актив с владельцем и бизнес-процессом. С Threat Intelligence - чтобы понимать, какие уязвимости прямо сейчас эксплуатируются в реальных атаках.

Но полностью автоматическое устранение здесь опасно. Если система нашла открытый сервис, это еще не значит, что его можно тут же выключить. Он может быть частью клиентского процесса, интеграции с партнером или временного, но критичного проекта. Поэтому автоматизация должна помогать создавать задачи, уведомлять владельцев, собирать данные и контролировать сроки. Финальное решение по критичным активам все равно остается за людьми, которые понимают бизнес-контекст.

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

Зрелость здесь измеряется не количеством найденных проблем, а временем от обнаружения критичного риска до его устранения.

Управлять нужно не уязвимостями, а изменениями

Поверхность атаки растет каждый раз, когда в компании что-то меняется. Появился новый сервис. Подключили подрядчика. Перенесли часть системы в облако. Запустили интеграцию. Открыли API. Добавили домен для рекламной кампании. Развернули стенд для тестирования.

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

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

Для руководителя по ИБ это особенно полезно. Вместо абстрактного «у нас большая поверхность атаки» появляются измеримые вопросы: сколько неизвестных активов обнаружено, как быстро они появляются в учете, сколько времени живут без владельца, какая доля критичных сервисов доступна из интернета, сколько уязвимостей с активной эксплуатацией не закрыто в срок.

Атакующий не ждет следующего аудита

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

Атакующий работает именно с текущей реальностью. Ему не важно, что написано в CMDB, какие активы были в скоупе аудита и кто должен был закрыть старый сервер. Он ищет то, что доступно сейчас.

Поэтому управление поверхностью атаки - это не проект на внедрение платформы и не еще один сканер в арсенале ИБ. Это постоянная дисциплина: знать, что видно снаружи, понимать, кому это принадлежит, оценивать реальный риск и закрывать опасные точки быстрее, чем их найдет атакующий.

Компания может иметь хорошие средства защиты, сильную команду и правильные регламенты. Но если снаружи у нее торчит забытый сервис с уязвимой версией, именно он станет самым удобным входом. Не потому, что атакующий умнее всех. А потому, что он смотрит на инфраструктуру такой, какая она есть, а не такой, какой она записана в документах.