Управление поверхностью атаки

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

Редакция CISOCLUB поговорила с экспертами про управление поверхностью атаки. Какие задачи бизнеса реально закрывает ASM, на чём команды чаще всего спотыкаются в первые месяцы, с какими системами его интегрировать, кто в компании отвечает за поверхность атаки, когда встроенных инструментов перестаёт хватать, чем российские решения отличаются от зарубежных и доживёт ли ASM как отдельный класс до конца десятилетия. Своими наблюдениями и рекомендациями поделились:

• Артём Бруданин, руководитель направления кибербезопасности RTM Group.
• Дмитрий Казаков, руководитель отдела технического пресейла компании Axoft.
• Александр Краснов, ведущий технический специалист отдела сетевой безопасности и аудита компании Axoft.
• Андрей Никонов, заместитель директора ООО «Смартап» (Vulns.io VM).
• Никита Ильин, руководитель группы тестирования на проникновение, Triadix.
• Павел Туманов, исполняющий обязанности владельца продукта, отдел развития продуктов Angara MTDR.
• Георгий Чернышов, старший инженер направления автоматизации ИБ, УЦСБ.

Главное расхождение между экспертами не в том, нужен ли ASM, а в том, как именно он встроится в более широкую практику управления внешними рисками. Будущее отдельной «коробки» ASM в концепции CTEM (Continuous Threat Exposure Management — проактивный и системный подход к управлению киберрисками, который предполагает непрерывный мониторинг, оценку и устранение уязвимостей в цифровых активах организации) спикеры оценивают по-разному. Одни ждут поглощения её функций более крупными платформами, другие оставляют место за специализированными ASM для сложных инфраструктур. В одном их позиции совпадают: умение видеть периметр снаружи останется для ИБ обязательной частью работы.

Что ASM реально даёт бизнесу

ASM нужен бизнесу, чтобы подсветить то, что компания о себе не знает: забытые серверы, тестовые стенды, лендинги маркетинга и публично доступные сервисы, которые ИБ-служба не заводила и не контролирует.

Закрыть слепое пятно теневого ИТ

Артём Бруданин, руководитель направления кибербезопасности RTM Group, сравнивает функцию ASM со «слепым пятном»: «Бизнес всегда думает, что ИТ полностью контролирует инфраструктуру и внешний периметр. ASM же призвано закрыть слепое пятно — «теневое ИТ». Когда маркетинговое агентство подняло лендинг на забытом сервере, когда разработчики выкатили тестовый API без авторизации, сисадмин поднял личный сервер на свободном IP в обход IDPS — всё это оно. Инструмент даёт честную инвентаризацию активов, о которых ИБ-служба могла не подозревать или которые могла потерять».

Андрей Никонов, заместитель директора ООО «Смартап» (Vulns.io VM), на первое место ставит инвентаризацию активов: «Первостепенная задача — инвентаризация активов: необходимо определить, из каких точек собирается поверхность атаки. Даже в небольших инфраструктурах частой является ситуация, когда открывают доступы или заводят временные виртуалки в ходе рабочих процессов разработки или тестирования, а затем забывают привести всё в порядок. Чем больше размер инфраструктуры, тем больше риск появления подобных забытых активов и открытых доступов. Сюда же можно отнести теневые активы: в данном случае это сервисы на периметре, которые заведены осознанно, но без соответствующего согласования».

Никита Ильин, руководитель группы тестирования на проникновение, Triadix, разбирает кейс, в котором ДИБ (департамент информационной безопасности) теряет контроль над свежим тестовым стендом разработчика: «Главная причина, по которой такие инструменты полезны — компания чётко видит, что торчит наружу. Из практики, в крупных компаниях это всегда проблема. ДИБ может даже не знать о каком-то тестовом стенде, к которому разработчик открыл доступ для своего удобства. Причём такой стенд мог быть поднят вчера, вечером, а уже сегодня утром через свежую CVE на вашем сервере закрепился автоматизированный атакующий скрипт и вы стали частью чего-то ботнета или подарили доступ во внутреннюю инфраструктуру».

Лишить атакующего форы и работать на опережение

Артём Бруданин смотрит на ту же задачу со стороны атакующего: «Реальная задача здесь — лишить атакующего форы. Внешние злоумышленники всегда начинают с разведки, и если они находят забытый S3-бакет или брошенный сервер с кучей CVE быстрее вас, то инцидент это лишь вопрос времени. ASM позволяет сократить поверхность атаки до контролируемого минимума, тем самым снижая потенциальный ущерб от кибератак».

Георгий Чернышов, старший инженер направления автоматизации ИБ, УЦСБ, отмечает: «Одна из основных задач ASM — показать компании её реальный внешний периметр, а не тот, который считается известным», и добавляет про приоритизацию: «ASM добавляет контекст: где находится актив, доступен ли он извне, есть ли владелец, насколько он критичен и есть ли признаки интереса со стороны атакующих».

Павел Туманов, исполняющий обязанности владельца продукта, отдел развития продуктов Angara MTDR, приводит цифру из расследований 2025 года: «По нашей статистике расследованных инцидентов 2025 года, более 35% кибератак начинались именно с компрометации публично доступных серверов». По Туманову, точкой входа становятся не только уязвимости, но и сервисы, публикация которых в интернет «вовсе не планировалась».

Что бизнес видит про себя со стороны

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

Дмитрий Казаков, руководитель отдела технического пресейла компании Axoft, поднимает тему защиты учётных данных: «Инструменты ASM защищают от компрометации учётных данных пользователей организации, осуществляют мониторинг появления паролей сотрудников в различных базах распространённых паролей».

На чём команды спотыкаются в первые месяцы работы с ASM

В первые месяцы ASM легко превращается в генератор отчётов и тысяч находок без владельцев и приоритетов, по которым никто не работает.

ASM не волшебная кнопка

Артём Бруданин называет главную причину ошибок: «Наверное, это попытка объять необъятное без правильно выстроенных процессов. Команды запускают сканирование, получают простыню из тысячи ассетов и не знают, с чего начать. Ступор и непонимание. Это не волшебная кнопка «сделать хорошо», а генератор задач».

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

Никита Ильин дополняет: «При плохо выстроенных процессах и отсутствии закреплённых владельцев конкретных активов непонятно кому назначать задачу, как контролировать её выполнение. В отдельных ситуациях ASM становится ещё одной системой, которая просто существует в компании для галочки». На старте Ильин советует: «Провести полную инвентаризацию находок; найти неизвестные внешние активы, где неясно, кто их контролирует и зачем они в инфраструктуре; наладить контроль за поддоменами».

Никто не отвечает за актив

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

Павел Туманов фиксирует ту же ловушку со стороны заказчика: «Отсутствие закреплённой зоны ответственности за актив со стороны Заказчика: найденный риск есть, но непонятно, кто должен его подтверждать и устранять».

Тысячи находок без приоритизации

Третья типовая ловушка — устранять всё подряд без приоритизации. Артём Бруданин отмечает: «Ещё одна грабля — отсутствие приоритезации. Начинаем патчить всё подряд, тратя ресурсы на некритичные тестовые стенды в DMZ, пока реально опасная точка входа остаётся открытой. Без понимания бизнес-логики и чёткого разграничения зон ответственности ASM быстро превращается в очередную дорогую игрушку».

Георгий Чернышов обращает внимание на объём находок: «ASM часто показывает неприятную реальность: поверхность атаки больше, чем ожидалось. Если команда пытается одновременно разобрать все находки, она быстро тонет в объёме».

Павел Туманов называет третью ошибку: «Третья ошибка — смотреть только на сам факт доступности актива из интернета, а не на его значимость для бизнеса. В результате команда получает длинный список находок, но не понимает, что устранять в первую очередь и как довести работу до реального снижения риска». После внедрения у заказчика появляются метрики: «ASM помогает навести порядок: он структурирует находки по критичности, типам активов и зонам ответственности, за счёт чего у Заказчика появляются понятные метрики — сколько выявлено внешних активов, сколько из них неучтённые, сколько содержат критичные проблемы и как меняется общий уровень риска».

С чем интегрировать, чтобы ASM работал, а не жил сам по себе

Сам по себе ASM — продвинутый поисковик: его ценность появляется, когда у каждой находки есть владелец и срок устранения в рабочем процессе. Конкретный контур интеграций с CMDB (Configuration Management Database — база данных управления конфигурациями), SIEM (Security Information and Event Management — система управления событиями информационной безопасности), VM (Vulnerability Management — управление уязвимостями) и тикет-системой команды собирают по своим приоритетам.

Базовая связка: CMDB, SIEM, тикет-система

Георгий Чернышов формулирует базовый принцип: «ASM не должен быть отдельной системой, в которую иногда заходят посмотреть карту активов. Его ценность появляется тогда, когда данные из ASM попадают в рабочие процессы ИБ и ИТ», и приводит формулу связки CMDB, SIEM, тикет-системы и SOAR (Security Orchestration, Automation and Response — система организации безопасности, автоматизации и реагирования): «Хорошая связка выглядит так: ASM находит риск, CMDB помогает определить владельца, SIEM показывает активность вокруг этого риска, тикет-система ставит задачу, SOAR ускоряет обработку и контроль».

Артём Бруданин сравнивает ASM с продвинутым поисковиком: «ASM сам по себе просто продвинутый поисковик. Для правильного результата его нужно подружить с CMDB». VM эксперт относит к обязательной части контура: «Обязательна связка с менеджментом уязвимостей: ASM находит актив, а VM проверяет его на конкретные CVE». Без автоматизации, по словам Бруданина, реакция страдает: «Без автоматизации передачи данных между инструментами защиты и таск-трекерами админов, реакция на новые угрозы будет занимать недели».

Павел Туманов дополняет список интеграций ITSM (IT Service Management — управление ИТ-услугами) и IAM (Identity and Access Management — управление идентификацией и доступом): «Минимально полезны интеграции с CMDB, чтобы понимать, какой актив компании принадлежит и кто за него отвечает; со сканерами уязвимостей, чтобы связывать внешний актив с техническими проблемами; с ITSM, чтобы ставить задачи на устранение; с SIEM, чтобы сопоставлять внешнюю экспозицию с событиями безопасности. Также важны интеграции с DNS, облачными платформами, EDR, IAM».

Андрей Никонов перечисляет три интеграции — с VM, SIEM и сервисами оповещений: «Целесообразно увязывать результаты мониторинга со следующими системами: 1) VM — для того, чтобы дополнить сведения об активе на периметре сведениями о его уязвимостях; 2) SIEM — для поиска индикаторов компрометации в данных об активе и его уязвимостях (хотя сам факт появления нового актива уже стоит рассматривать как индикатор); 3) Сервисы оповещений — тикет-системы или иные уведомления, которые использует компания. В идеале генерировать тикет с закреплением ответственного лица».

Управление доступом и пароли при утечках

Александр Краснов, ведущий технический специалист отдела сетевой безопасности и аудита компании Axoft, называет три обязательных решения для интеграции. SIEM — для связи внешних находок с внутренними журналами: «Это позволит объединять внешние данные с внутренними журналами работы серверов и сетевого оборудования, видеть полную картину и не пропустить развитие атаки». База управления конфигурациями и активами — чтобы вернуть в учёт забытое: «Здесь ASM найдёт то, о чём ИТ/ИБ-специалисты забыли или не знали: заброшенные поддомены, тестовые стенды. Эти активы будут автоматически переданы в базу, к ним назначится ответственное подразделение/сотрудник, а значит — будет шанс вовремя закрыть найденную дыру». Средства управления доступом — для блокировки и смены пароля при утечках: «Не будем забывать и про средства управления доступом и учётными записями — для блокировки или смены пароля учётной записи пользователя, чьи данные утекли в открытый доступ».

Особое мнение: не во все системы, а в трекер с владельцами

Никита Ильин возражает против широкого списка интеграций: «Можно придумывать много всего: SIEM, SOAR, CMDB. Это всё отлично, но это не первостепенная задача. Мне кажется куда важнее интегрироваться с Jira/Naumen или любым другим вашим трекером, чтобы сразу же начать выстраивать чёткий контроль за находками. Важно сразу фиксировать владельца актива, делать его ответственным по задаче, ставить чёткие сроки исправления. Чёткие процессы куда важнее на первых этапах, чем интеграция во все системы».

Кто отвечает за поверхность атаки и почему на самом деле никто

Поверхность атаки оказывается общей зоной, где формальный круг ответственных широк — ИТ, ИБ, DevOps, облачная команда, маркетинг и подрядчики, а на практике не отвечает никто.

Формально — за ИБ. Фактически — ни за кем

Никита Ильин отмечает: «Формально — за ИБ. Фактически — ни за кем. ИБ обычно не владеет системами. А реальные владельцы размазаны между ИТ, DevOps и другими отделами». Корень проблемы он видит в разрыве между внешним и внутренним взглядом: «Атакующий видит всё это как единую поверхность, а внутри компании это разбито по бюджетам, командам и зонам ответственности».

Поверхность размазана между ИТ, ИБ, DevOps и маркетингом

Георгий Чернышов обозначает формальный круг владельцев: «Формально поверхность атаки затрагивает сразу несколько зон: ИБ, инфраструктуру, сеть, разработку, DevOps, облака, владельцев бизнес-систем. Но на практике нередко оказывается, что за неё «целиком» не отвечает никто». Типовой сценарий поиска владельца на находке ASM: «Типовая ситуация: ASM находит неизвестный поддомен со старой административной панелью. Доступ открыт из интернета, версия ПО устаревшая, риск очевидный. SOC фиксирует проблему и начинает искать владельца. Сетевики говорят: «Такого IP у нас в актуальной документации нет». Разработчики говорят: «Это был временный стенд, его давно должны были отключить». Инфраструктура говорит: «Мы это не сопровождали». Бизнес-владелец вообще не знает, что такой сервис существует». Итог Чернышов формулирует так: «ASM почти всегда вскрывает более глубокую проблему — слабое управление активами. Без связки актив — владелец — критичность — срок устранения система будет только показывать хаос».

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

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

Что мешает наладить ответственность

Артём Бруданин разбирает три причины, по которым ответственность не закрепляется. Первая — страх перед legacy (унаследованными системами): «Никто не хочет брать ответственность за старые legacy-системы, которые страшно трогать, чтобы ничего не развалилось». Вторая — пробелы в регламентах: «Иногда зону некому защищать просто потому, что в регламентах не прописано, кто именно должен следить за внешним периметром». Третья — иллюзия стабильности периметра: «Пока реального инцидента (или подзатыльника) нет, то периметр воспринимается как некая статичная данность, хотя на самом деле он меняется ежедневно».

Георгий Чернышов формулирует правило для каждого актива: «Правильный подход — заранее определить правило: каждый найденный внешний актив должен получить владельца и статус». Если владельца нет, актив попадает в отдельный процесс разбирательства, а для критичных случаев допустимо ограничение доступа или временная изоляция до выяснения: «Не обязательно сразу «рубить всё через 48 часов», но правило должно быть жёстким: бесхозный интернет-доступный актив не может бесконечно оставаться без решения».

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

Когда встроенных инструментов перестаёт хватать и компания приходит к ASM

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

Когда пора переходить: рост, облака, подрядчики, слияния

Павел Туманов обозначает рубеж выхода за пределы базовых средств: «Когда компания начинает быстро расти, работать через подрядчиков, открывать филиалы или проходить через слияния и поглощения компаний, встроенные инструменты начинают видеть только отдельные куски картины. Они показывают то, что уже известно внутри, но плохо выявляют забытые, неучтённые и спорные активы. В этот момент появляется потребность в отдельном ASM-решении: не как в ещё одном сканере, а как в механизме постоянного внешнего обзора, обнаружения активов и контроля изменений внешнего периметра во времени».

Георгий Чернышов выделяет четыре признака утраты контроля: «Компания приходит к ASM, когда понимает, что обычных сканеров, ручного учёта и периодических проверок уже недостаточно». Первый — компания теряет контроль над активами: «Документы утверждают одно количество серверов и доменов, но в реальности во внешнем периметре существуют старые поддомены, временные стенды, забытые API, тестовые панели, открытые облачные хранилища и давно заброшенные сервисы». Второй — инфраструктура меняется быстрее, чем её проверяют: «Если сканирование проводится раз в месяц или раз в квартал, оно не отражает реальную картину. За это время разработчики могут поднять новый стенд, открыть порт, изменить DNS, опубликовать API или создать облачный ресурс. Для современной инфраструктуры периодической проверки мало — нужен постоянный мониторинг изменений». Третий — рост числа облачных хранилищ подрядчиков и внешних интеграций: «Когда часть сервисов находится в облаке, часть у подрядчиков, часть связана через внешние домены и API, внутренний взгляд перестаёт быть достаточным. Атакующий смотрит на компанию снаружи. ASM нужен именно для такого взгляда: что реально видно из интернета, какие связи между активами существуют, где есть ошибки публикации и какие точки входа выглядят наиболее привлекательными». Четвёртый — сложность приоритизации: «У компании уже есть сканеры уязвимостей, но они дают слишком много находок. ASM помогает добавить внешний контекст и понять, что действительно опасно прямо сейчас».

Когда о новом сервере узнают из письма хакера

Артём Бруданин даёт конкретный численный порог перехода: «Пока работает три сервера и один корпоративный портал, за глаза хватит бесплатного Nmap и периодических заходов на Shodan. Но как только инфраструктура начинает расползаться по разным хостингам или облакам, компания активно создаёт обособленные команды вместе с их «зоопарком» технологий, ручной контроль умирает. Переход к выделенному ASM случается в точке, когда количество внешних активов переваливает за сотню, а ИБ-команда тратит больше времени на выяснение «чей это сервак?», чем на саму защиту. Если вы узнаете о появлении нового веб-интерфейса из электронного письма хакера-самоучки (в лучшем случае) — пора задуматься о нормальном решении».

Два типа ASM-решений

Александр Краснов называет похожую причину перехода: «Компании начинают задумываться об ASM, когда замечают, что обычные средства не поспевают за постоянными изменениями и не видят «теневые» ИТ активы», и разграничивает сам класс решений: «Сами ASM-решения бывают двух типов: сканеры, которые точно находят технические уязвимости, и платформы для сбора внешней киберразведки. Возможна также их комбинация».

Чем российские ASM отличаются от зарубежных, которые пришлось заменить

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

Локальный контекст, регуляторы и киберразведка

Георгий Чернышов предостерегает от лобовых сравнений: «Здесь важно не скатываться в простое сравнение «наши хуже» или «наши лучше». Всё зависит от конкретного продукта, зрелости команды вендора и задач заказчика», и перечисляет сильные стороны российских решений: «Российские ASM-решения чаще лучше адаптированы под локальный рынок: российские облака, особенности инфраструктуры заказчиков, требования регуляторов, локальную эксплуатацию, импортозамещение и работу внутри ограниченного контура».

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

Артём Бруданин главным отличием называет качество Threat Intelligence (киберразведки): «Главное отличие сегодня — в качестве Threat Intelligence. Российские разработчики быстрее получают данные о специфических угрозах, актуальных именно для нашего региона». Обратная сторона импортозамещения, по словам Бруданина, техническая: «Зарубежные сканеры начали часто выдавать пустые отчёты или вовсе блокировать доступ по геолокации: не только они нас, но и мы их».

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

Где западные ASM пока сильнее: масштаб и интеграции

Георгий Чернышов выделяет сильные стороны западных решений: «Зарубежные ASM-решения исторически сильны в масштабируемости, большом количестве готовых интеграций. Они хорошо работают с глобальной инфраструктурой, популярными облаками, внешними источниками данных, сертификатами, DNS, публичными репозиториями и разными типами активов. Сильная сторона зрелых зарубежных решений — скорость обнаружения, качество корреляции и развитая экосистема интеграций».

Артём Бруданин приводит примеры провайдеров: «Западные продукты традиционно более удобны в плане UX и интеграций с глобальными облачными провайдерами вроде AWS или Azure, различными схожими сервисами по API».

Павел Туманов соглашается: «Зарубежные решения традиционно были сильны в глобальном охвате, зрелых механизмах корреляции и развитии платформ класса управление экспозицией, то есть совокупным доступным для атаки риском».

ASM — это не Threat Intelligence и Digital Risk Protection

Георгий Чернышов проводит границу с соседними классами: «Есть нюанс: часть функций, которые иногда пытаются отнести к ASM, на самом деле, относится к соседним классам решений. Например, мониторинг утечек, каналов-мессенджеров, даркнета, скомпрометированных учётных данных и упоминаний бренда — это ближе к Threat Intelligence или Digital Risk Protection (защита от цифровых рисков). Хорошо, если ASM-вендор это поддерживает, но не стоит ожидать от ASM такой же глубины, как от полноценной TI/DRP-платформы». Зрелая команда, по словам Чернышова, использует несколько источников: «На практике зрелая команда может использовать несколько источников данных: ASM, сканеры уязвимостей, CMDB, SIEM, TI/DRP и ручную валидацию критичных находок. Один инструмент редко закрывает всю задачу полностью».

Доживёт ли ASM как отдельный класс или его поглотят соседние направления

На горизонте нескольких лет ASM всё реже встречается как отдельный продукт и всё чаще как часть платформ VM, XDR и CTEM; внешний обзор инфраструктуры остаётся обязательной задачей, а часть экспертов переносит акцент с поиска активов на измеримое сокращение векторов атак.

Функция останется, отдельный класс растворится в платформах

Артём Бруданин прогнозирует поглощение ASM в VM, XDR (Extended Detection and Response — расширенное обнаружение и реагирование) и CTEM: «Как самостоятельное «коробочное решение» ASM обречён на поглощение. Мы уже видим, как его функции активно затягивают в себя платформы управления уязвимостями (те самые VM) и XDR. Рынок движется в сторону концепции CTEM — непрерывного управления воздействием угроз, где ASM является лишь одним из модулей. Глупо держать отдельный софт только для внешней инвентаризации, если эти данные нужны всем остальным инструментам защиты».

Георгий Чернышов связывает прогноз с управлением экспозицией: «ASM как функция точно не исчезнет. Но как отдельный класс решений он будет меняться. Сейчас рынок движется от простой идеи «найти внешние активы» к более широкому подходу — управлению экспозицией и рисками».

Павел Туманов соглашается: «С высокой вероятностью ASM сохранится как важная функция, но всё реже будет существовать как полностью отдельный класс решений. Рынок движется к объединённым платформам, где ASM становится частью более широкой модели».

Никита Ильин говорит короче: «Скорее всего, как функция точно доживёт; как отдельная коробка — не у всех». С ссылкой на материал Tenable по EASM, где EASM описан как важная часть концепции CTEM, Ильин заключает: «ASM частично растворится в CTEM / Exposure Management системах, но сама функция внешней инвентаризации, мониторинга и приоритизации никуда не исчезнет».

Где специализированный ASM сохранится

Павел Туманов уточняет, что изменится для покупателей: «Сама задача никуда не исчезнет: компаниям по-прежнему нужно понимать, что видно о них извне и где у них слабые места. Но покупать будут не просто «систему поиска внешних активов», а платформу, которая умеет делать обнаружение, приоритизацию, назначение ответственности и устранение выявленных проблем».

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

Что важнее, чем найти актив

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

Артём Бруданин завершает практическим тезисом: «Однако сам подход «взгляда на сеть извне, глазами хакера» никуда не денется — это фундамент для проактивной защиты».

Заключение

Действие для CISO в первые недели после внедрения ASM — получить от системы список внешних активов, который не сводится к данным CMDB и реестру ИТ-службы. Если такой список не появляется, инструмент не закрывает ту проблему, ради которой его покупали. Особый класс — теневые активы, заведённые осознанно, но без согласования с ИБ, — выделяет Андрей Никонов (Смартап). К базовой инвентаризации Дмитрий Казаков (Axoft) добавляет смежную задачу мониторинга паролей сотрудников в утечках. Цифра для разговора с бизнесом приходит от Павла Туманова (Angara MTDR): по данным расследований 2025 года, более 35% кибератак начинались с компрометации публично доступных серверов.

Перед запуском пилота CISO стоит зафиксировать три KPI: процент находок с закреплённым владельцем, среднее время от обнаружения до устранения и долю активов, по которым выставлены сроки в тикет-системе. Без этих метрик пилот покажет только объём обнаруженного, но не реальное снижение риска. Конкретный диагноз — отсутствие владельцев у новых находок — фиксирует Георгий Чернышов (УЦСБ). Павел Туманов добавляет ошибку фокуса: команда смотрит на сам факт доступности актива из интернета, а не на его значимость для бизнеса. Артём Бруданин (RTM Group) описывает стартовый ступор с другой стороны: команды получают простыню из тысячи ассетов и не знают, с чего начать.

Критерии приёмки пилота ASM по интеграциям для CISO: данные о новой находке доходят до закреплённого владельца; тикет автоматически создаётся в Jira/Naumen с проставленным сроком устранения; история находок видна в SIEM как хроника, привязанная к конкретному внешнему активу; для случаев утечки учётных данных контур включает блокировку и смену пароля учётки. Стартовый приоритет — интеграция с трекером и закреплённый владелец по каждой находке, на этом настаивает Никита Ильин (Triadix). Остальной контур (CMDB, SIEM, VM, ITSM, IAM) команда добирает по мере роста зрелости. Управление учётными записями для блокировки и смены пароля при утечке добавляет Александр Краснов (Axoft). Список заявленных коннекторов на слайде вендора сам по себе ни о чём не говорит.

Организационное решение, которое CISO стоит принять до запуска ASM — назначить владельца самого процесса разбирательства с находками, описать SLA по реагированию на бесхозный интернет-доступный актив и зафиксировать, что делать с legacy-системами и подрядчиками. Без такой рамки управления результат ASM зависает на этапе «нашли, но не знаем, чьё». Короткой формулой диагноз ставит Никита Ильин: формально — за ИБ, фактически — ни за кем. Три причины, по которым ответственность не закрепляется, разбирает Артём Бруданин: страх трогать legacy, пробелы в регламентах и иллюзия стабильности периметра. Формулу для CISO-политики даёт Георгий Чернышов: «Бесхозный интернет-доступный актив не может бесконечно оставаться без решения»; для критичных случаев — ограничение доступа или временная изоляция до выяснения.

Чек-лист CISO для перехода от встроенных средств к выделенному ASM: количество внешних активов вышло за сотню; документация по периметру расходится с реальной картиной; периодичность сканирований ниже скорости изменений; растёт доля сервисов у подрядчиков, в облаках и дочерних обществах; новые активы появляются после M&A и открытия филиалов; объём находок превышает возможности приоритизации. Численный ориентир в сотню активов и характерный признак (о новом веб-интерфейсе ИБ узнаёт из письма хакера-самоучки) приводит Артём Бруданин. Полный набор четырёх практических признаков потери контроля разворачивает Георгий Чернышов. Триггеры роста — подрядчики, филиалы, слияния и поглощения — перечисляет Павел Туманов. Александр Краснов делит сам класс на два типа: точные сканеры и платформы внешней киберразведки.

Чек-лист CISO для выбора между российским и зарубежным ASM: соотносится ли модель угроз заказчика с теми регионами, которые покрывает киберразведка вендора; есть ли поддержка российских облаков и регуляторных требований; насколько готовы интеграции с CMDB/SIEM/VM в типовой российской инсталляции; не блокирует ли зарубежный поставщик доступ по геолокации; экономика владения с учётом импортозамещения. От лобового сравнения «наши лучше / наши хуже» сразу предупреждает Георгий Чернышов: всё зависит от конкретного продукта и задач заказчика. Качество киберразведки в пользу российских решений и тот факт, что зарубежные сканеры всё чаще блокируют доступ по геолокации, отмечает Артём Бруданин. Павел Туманов указывает на сервисную модель и экспертный сервис как сильные стороны российских решений; Александр Краснов — на их экономическую привлекательность и фокус на адаптацию к российским реалиям. Отдельная оговорка Георгия Чернышова: мониторинг утечек, даркнета и упоминаний бренда — это территория Threat Intelligence и Digital Risk Protection, и не стоит ждать от ASM такой же глубины, как от полноценной TI/DRP-платформы.

Действие для CISO в горизонте нескольких лет — оценивать вендора не по «отдельному сканеру внешнего периметра», а по способности встроить блок ASM в общий процесс обнаружения, приоритизации и устранения. Конкретные сигналы для проверки: куда вендор движется по продуктовой стратегии (поглощение в VM, XDR или CTEM либо удержание специализированного ASM), остаётся ли у него экспертиза для сложной инфраструктуры с большим числом доменов, облаков и подрядчиков. Категоричный прогноз по поглощению ASM-коробок в VM, XDR и CTEM даёт Артём Бруданин; ссылку на материал Tenable, где EASM описан как часть CTEM, приводит Никита Ильин. Оговорка Георгия Чернышова: специализированные решения сохранятся там, где сложная инфраструктура с большим числом доменов, облаков, подрядчиков и дочерних обществ требует глубокого внешнего анализа.

Тема, проходящая через все семь вопросов: управление поверхностью атаки как функция важнее, чем ASM как отдельный продукт. Эксперты возвращаются к ней в формулировках о генераторе отчётов без процесса, об отсутствии владельцев у активов, о необходимости встраивать ASM в рабочий контур из CMDB, SIEM, тикет-системы и SOAR, о переходе к платформам управления экспозицией. ASM подсвечивает главную проблему — слабое управление активами и размытую ответственность за внешний периметр, но не закрывает её сам по себе. Покупка инструмента без выстроенного процесса даёт информационный шум вместо снижения риска.

Практический вывод для CISO: при выборе вендора смотреть не на красивый список активов на демо, а на то, как ASM встроен в процесс — кому система ставит задачу, по каким срокам и как измеряется снижение риска.