К третьему или четвертому прогону автоматизированный пентест обычно находит все меньше новых проблем. На бумаге это выглядит как зрелость процесса, а для руководства часто и вовсе как признак того, что с безопасностью все уже более-менее в порядке. Проблема в том, что «стабильный» отчет и реальная защищенность инфраструктуры — совсем не одно и то же, и для российских ИБ-команд это довольно узнаваемый сценарий.
Об этом пишет The Hacker News, а поводом стал совместный вебинар издания с Picus Security. В сессии участвуют Autumn Stambaugh и Can Yuceel, модератором заявлен James Azar. Главная мысль проста и неприятна: если отчет от инструмента перестал пополняться новыми находками, это может говорить не о том, что среда стала безопасной, а о том, что система проверки дошла до предела собственной видимости.
Это важное уточнение, потому что во многих компаниях автоматизированный пентест постепенно начинает восприниматься как почти универсальный способ валидации защиты. Логика понятна: инструмент регулярно запускается, что-то эксплуатирует, строит маршрут атаки, показывает, где злоумышленник может пройти дальше. Если находок становится меньше, значит, команда закрыла дыры и движется в правильную сторону. Но у такого подхода есть неприятный побочный эффект: он создает иллюзию полноты картины. На деле инструмент отвечает лишь на один вопрос — существует ли проходимый путь для атаки. На многие другие вопросы он не отвечает вообще.
Picus Security предлагает смотреть на security validation шире и делит ее на шесть поверхностей проверки. Автоматизированный пентест в этой модели покрывает только одну — attack path, то есть возможность перемещения атакующего по среде через уязвимые или слабо защищенные точки. За пределами этой проверки остаются как минимум еще пять зон: правила детектирования, облачные конфигурации, идентификационные и привилегированные контроли, а также guardrails для ИИ-систем. И здесь начинается самое интересное. Даже хорошо настроенный инструмент не может превратиться из теста на проходимость атаки в полноценную проверку SIEM, EDR, облачной безопасности или качества сигналов для SOC. Подкрутить параметры сканирования можно. Отменить ограничения класса инструмента — нет.
Особенно болезненный разрыв проявляется на стыке offensive- и defensive-практик. Если средство автоматического пентеста успешно имитирует credential dumping, lateral movement или другую технику, оно доказывает лишь то, что такой сценарий возможен. Но оно не сообщает, сработало ли правило в SIEM, поднял ли тревогу EDR, было ли событие корректно залогировано и хватило ли сигналов аналитикам SOC, чтобы заметить атаку вовремя. Иначе говоря, команда получает подтверждение существования маршрута, но не получает ответа на более дорогой вопрос: «А мы вообще увидели бы реального злоумышленника на этом этапе?» Именно в этой точке чистый отчет начинает быть опасным. Он снимает напряжение там, где его, возможно, как раз нужно повышать.
Отсюда вытекает и проблема приоритизации. Если инструмент показал эксплуатируемый путь, но реальные защитные контроли уже надежно блокируют или хотя бы уверенно детектируют соответствующее поведение, срочность такой находки будет одной. Если тот же путь проходит тихо, без срабатываний и без достаточного контекста для SOC, это уже совсем другой уровень риска. Без проверки контролей команда ранжирует проблемы примерно с половиной исходных данных. В результате в один список попадают вещи, которые красиво выглядят в отчете, но не несут немедленной угрозы, и вещи, которые можно эксплуатировать практически бесшумно. Для бизнеса разница критична: в первом случае есть окно на плановое исправление, во втором — риск, который уже живет в инфраструктуре и не особенно собирается ждать квартального комитета.
Для разработчиков, платформенных инженеров и ИТ-руководителей из этого следует довольно прагматичный вывод. Автоматизированный пентест полезен, когда нужно быстро и регулярно понимать, насколько атакуемы реальные маршруты внутри среды. Но он не заменяет проверку того, как работают защитные механизмы в бою. Если компания строит программу валидации защиты только вокруг attack-path-логики, она почти неизбежно начинает путать «эксплуатируемо» и «опасно прямо сейчас». А это уже ошибка уровня управления риском, а не просто технический недосмотр. Тем более что в гибридных инфраструктурах с облаком, федерацией доступов, сервисными учетками и ИИ-инструментами поверхность атаки давно шире классического набора из уязвимости, хоста и бокового перемещения.
Для рынка это еще один сигнал, что эпоха универсальных серебряных пуль в ИБ, кажется, снова откладывается. Offensive-инструменты становятся удобнее и регулярнее, но defensive-слой от этого автоматически не проверяется. А значит, зрелым командам придется сводить вместе как минимум две перспективы: может ли атакующий пройти и увидим ли мы его, пока он идет. Пока эти два ответа живут в разных отчетах, любой слишком чистый отчет о пентесте стоит читать с легкой профессиональной подозрительностью.