Как в UDV Group предлагают искать слепые зоны в инфраструктуре
Эксперты UDV Group рассказали, как ASM помогает находить забытые активы, снижать число слепых зон и быстрее закрывать реальные риски.
По мере того как корпоративная инфраструктура становится все более распределенной, бизнесу все сложнее понимать, где на самом деле проходит его цифровой периметр. Облачные ресурсы, API, контейнеры, тестовые стенды, подрядчики, забытые домены и теневые IT-сервисы часто появляются быстрее, чем ИТ- и ИБ-команды успевают внести их в реестр активов.
В результате у компании может быть современный набор защитных решений, но при этом сохраняться «слепые зоны» — ресурсы, о которых внутри организации уже забыли или вообще не знают. Именно они нередко становятся удобной точкой входа для злоумышленников.
О том, какую задачу решает Attack Surface Management, почему классические инструменты не всегда видят реальную поверхность атаки и как выстроить процесс так, чтобы не захлебнуться в потоке алертов, рассказал Дмитрий Бабич, ведущий инженер отдела сопровождения информационных систем UDV Group.
— Дмитрий, когда говорят про ASM, часто звучит формулировка «управление поверхностью атаки». Но для бизнеса это может выглядеть довольно абстрактно. Если совсем приземлить: какую конкретную проблему решает ASM, которую не закрывают привычные инструменты ИБ?
Главная проблема, которую решает Attack Surface Management, — отсутствие у бизнеса полной и постоянно актуализируемой картины всех цифровых активов и точек входа для атак.
Классические средства защиты — сканеры уязвимостей, SIEM, EDR и другие инструменты — как правило, работают в пределах уже известного периметра. То есть они хорошо помогают там, где компания понимает, какие активы у нее есть и что нужно контролировать.
ASM закрывает другой слой задачи. Он помогает выявлять внешние и внутренние неучтенные активы и добавлять их в модель поверхности атаки. На практике это значит, что компания раньше замечает новые точки входа и может убрать «слепые зоны» до того, как ими воспользуется атакующий.
— То есть проблема не в том, что у компаний совсем нет средств защиты, а в том, что они не всегда понимают, что именно нужно защищать?
Да, именно. Можно иметь хороший стек ИБ-инструментов, но при этом не видеть часть реальной инфраструктуры. Например, забытый тестовый стенд, старый поддомен, облачный инстанс, поднятый под временную задачу, или ресурс подрядчика, который связан с основной инфраструктурой.
Мы в UDV Group видим, что актуальность ASM как раз и растет из-за быстрого развития распределенных инфраструктур. Периметр компании постоянно меняется и размывается, а статические инструменты и разовые аудиты за такими изменениями просто не успевают.
— Здесь сразу возникает болезненный вопрос: поверхность атаки сегодня включает облака, контейнеры, API, shadow IT, активы подрядчиков, утекшие учетные данные. Как вообще найти то, о чем ИТ-департамент может даже не знать?
Обнаружение неизвестных активов строится на непрерывном сборе данных из внешних и внутренних источников.
Снаружи анализируется все, что доступно публично: доменные зоны, DNS-записи, журналы сертификатов, открытые репозитории, утечки. С внутренней стороны используются данные из облачных платформ, систем виртуализации, сетевого оборудования, прокси и DNS, а также телеметрия с рабочих станций, мобильных устройств, контейнерных сред и других компонентов инфраструктуры.
Дополнительно могут использоваться данные из закупок и договоров — они помогают находить забытые стенды и активы подрядчиков. Все эти сведения сопоставляются в единой модели. В результате обнаруживаются ресурсы, которые влияют на безопасность, но находятся вне учета ИТ-департамента.
— Звучит так, будто ASM заставляет компанию посмотреть на себя глазами атакующего. В UDV Group вы именно так это формулируете?
Да, это близкая формулировка. ASM действительно помогает посмотреть на инфраструктуру не изнутри, по формальному реестру активов, а с точки зрения потенциального атакующего: что видно снаружи, какие сервисы доступны, какие связи можно использовать, где есть забытые или слабо контролируемые элементы.
Это важное отличие. Внутренние документы могут говорить, что ресурс уже выведен из эксплуатации, а снаружи он все еще доступен. Или команда может считать, что тестовый контур не связан с критичными системами, но фактически через него можно развить атаку дальше.
— Тогда с чего начинать инвентаризацию? Потому что если сразу пытаться найти все, есть риск утонуть в данных.
Начинать стоит с известных активов: доменов, диапазонов адресов, облачных аккаунтов, ключевых систем. Дальше от них нужно последовательно находить связанные ресурсы, которые раньше просто не попадали в поле зрения.
При этом важно не столько наличие единого реестра само по себе, сколько сведение данных из разных источников в общую модель. В ней должны быть видны связи между активами.
Наибольшую эффективность дает не отдельный инструмент, а автоматическая сверка информации из DNS, журналов выдачи сертификатов, систем управления конфигурациями, каталогов пользователей и логов. Именно расхождения между этими источниками часто указывают на неучтенные активы.
— То есть ценность появляется не просто в списке активов, а в связях между ними?
Да. Сам по себе список активов быстро устаревает. Сегодня ресурс есть, завтра его перенесли, послезавтра открыли новый тестовый стенд, а через неделю к нему появился внешний доступ.
Мы в UDV Group считаем, что ключевая ценность ASM — в динамической модели, которая показывает не только наличие актива, но и его контекст: где он расположен, кому принадлежит, как связан с другими системами, насколько доступен извне и какой риск создает для бизнеса.
— Хорошо, активы нашли. Но дальше начинается вторая проблема: алертов может быть слишком много. Как выстроить процесс так, чтобы команда не захлебнулась в оповещениях, но и не пропустила критичную уязвимость?
Процесс работы с уязвимостями нужно строить так, чтобы поток оповещений изначально был управляемым.
Для этого «сырые» алерты должны дополняться контекстом: учитывается доступность актива, его критичность для бизнеса, тип уязвимости и наличие известных способов эксплуатации. Автоматическое сканирование выполняет роль базового слоя — оно непрерывно фиксирует изменения и потенциальные проблемы.
Экспертный анализ подключается там, где требуется интерпретация: устранить ложные срабатывания, оценить реальные сценарии атаки, выделить действительно значимые риски.
— То есть автоматизация нужна, но полностью отдавать ей решение нельзя?
Да, баланс здесь принципиален. Массовые и типовые проверки нужно автоматизировать, иначе команда просто утонет в операционной рутине. Но все, что связано с критичными системами, цепочками атак и сложными инфраструктурными связями, должно разбираться специалистами.
В UDV Group мы исходим из того, что автоматизация должна не заменять эксперта, а освобождать его от шума. Тогда специалист тратит время не на просмотр сотен однотипных срабатываний, а на анализ тех рисков, которые действительно могут привести к инциденту.
— А как правильно расставлять приоритеты? Потому что в отчетах часто все выглядит критичным, но исправить все одновременно невозможно.
Приоритизация рисков в ASM строится на сочетании нескольких факторов: роли актива в инфраструктуре, его доступности, наличия эксплойтов и потенциального влияния на бизнес.
Наиболее опасны не просто уязвимости с высоким техническим рейтингом, а те, которые затрагивают публично доступные или слабо контролируемые сервисы с высокой связностью внутри инфраструктуры. Именно они формируют максимальный уровень риска.
Например, уязвимость на изолированном внутреннем сервисе и уязвимость на публичном API, связанном с критичной бизнес-системой, — это разные уровни приоритета, даже если формально оценка уязвимости похожа.
— Получается, ИБ-команда должна приходить к ИТ, DevOps или облачной команде не с абстрактным отчетом, а уже с понятным контекстом: что сломано, почему это важно и что делать?
Именно. Для быстрого устранения проблем важно заранее определить понятный процесс взаимодействия между ИБ и техническими командами.
Нужно закрепить ответственных за активы и передавать им найденные проблемы не в виде абстрактных отчетов, а с уже определенным контекстом и приоритетом. То есть не просто «у вас уязвимость», а «этот сервис доступен извне, связан с такой-то системой, для уязвимости есть эксплуатация, поэтому исправить нужно в такой-то срок».
Мы в UDV Group видим, что именно такой подход ускоряет реакцию. А когда роли, регламенты и сроки устранения заранее описаны, работа с уязвимостями становится частью нормального операционного процесса, а не авральной историей после очередного сканирования.
— То есть зрелый ASM — это уже не столько инструмент, сколько процесс управления изменяющимся периметром?
Да, это очень точное определение. ASM нельзя сводить только к покупке решения или запуску сканирования. Это постоянный процесс: обнаружение активов, актуализация модели, оценка рисков, приоритизация, передача задач владельцам систем и контроль устранения.
Поэтому в UDV Group мы рассматриваем ASM как элемент зрелого управления киберрисками. Он помогает не просто находить уязвимости, а понимать, как меняется реальная поверхность атаки компании и где нужно действовать в первую очередь.
— И если коротко сформулировать для бизнеса: почему с этим нельзя ждать?
Потому что атакующий не ждет, пока компания завершит инвентаризацию, согласует регламент или обновит реестр активов.
Если ресурс доступен извне, если он связан с корпоративной инфраструктурой и если о нем никто не помнит, он уже является частью поверхности атаки. Вопрос только в том, кто обнаружит его первым — защитники или злоумышленники.
Мы в UDV Group считаем, что именно поэтому ASM становится все более актуальным: он позволяет перейти от реактивной модели «нашли проблему после инцидента» к проактивной модели, где компания постоянно понимает, что у нее открыто, какие риски растут и какие точки входа нужно закрывать в первую очередь.
