Компании не видят часть собственной поверхности атаки

Поверхность атаки компании давно перестала совпадать с привычным периметром. Помимо серверов, рабочих станций и сетевого оборудования в нее входят облачные инстансы, контейнеры, API, тестовые стенды, подрядчики, теневые IT-ресурсы, сервисные учетные записи и утекшие доступы. Часть этих активов может быть известна ИТ-департаменту. Часть появляется быстрее, чем успевает попасть в учет.

Именно эту проблему решает класс решений ASM, или Attack Surface Management. Его задача — не заменить сканеры уязвимостей, SIEM или EDR, а показать, что именно у компании вообще доступно для атаки. Классические средства защиты хорошо работают там, где актив уже известен, описан и подключен к мониторингу. Но если ресурс не попал в учет, он остается слепой зоной.

Мы в UDV Group видим, что такие слепые зоны часто возникают не из-за грубой ошибки, а из-за нормальной динамики бизнеса. Компания запускает новый сервис, подрядчик поднимает временный стенд, команда разворачивает облачный ресурс, DevOps публикует API, тестовая среда остается доступной после завершения проекта. Формально это может быть рабочая необходимость. Но для атакующего это еще одна точка входа.

Актуальность ASM растет именно из-за распределенных инфраструктур. Периметр постоянно меняется: часть сервисов находится в облаке, часть работает у подрядчиков, часть связана с внутренними системами через API и удаленный доступ. Разовый аудит в таких условиях быстро устаревает. Сегодня ресурс проверили, а через неделю появилась новая связка, новый домен или новая учетная запись.

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

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

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

В проектах UDV Group такие расхождения часто оказываются важнее самих отчетов об уязвимостях. Неучтенный актив может не иметь критической CVE прямо сейчас, но уже создает риск: непонятно, кто за него отвечает, как он обновляется, кто имеет к нему доступ и зачем он вообще доступен извне.

Отдельная задача — не утонуть в оповещениях. Если ASM превращается в поток сырых алертов, команда быстро перестает на них реагировать. Поэтому каждое срабатывание должно получать контекст: доступен ли актив из интернета, насколько он важен для бизнеса, есть ли известные способы эксплуатации, с какими системами он связан и кто отвечает за исправление.

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

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

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

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

Поэтому класс решений ASM важен не как еще один источник алертов. Его ценность в другом: он помогает компании увидеть реальную поверхность атаки и связать технические находки с управленческими решениями. Какие активы существуют? Какие из них доступны извне? Что появилось без согласования? Где есть слабые связи между системами? Кто должен устранить проблему?

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

Для нас в UDV Group главный вывод такой: ASM нужен бизнесу не ради красивой карты активов, а ради управляемости риска. Когда компания видит свои домены, облака, API, подрядчиков, тестовые стенды и связи между ними, она может не только находить уязвимости, но и быстрее закрывать реальные точки входа. Без такой видимости защита работает только в той части инфраструктуры, которая уже известна. А сегодня этого недостаточно.