Привет, Хабр. Меня зовут Илья Самылов, я работаю вNGENIXи отвечаю за сопровождение сервисов информационной безопасности, анализ веб-атак и бот-активности.
За последние пару лет ИИ в кибербезопасности стал универсальным объяснением всего. Любая сложная атака — «это нейросеть». Любой аккуратный фишинг — «генеративный ИИ». Я же предпочитаю разделять маркетинг и реальность. Но реальность в том, что профиль атак действительно изменился. И это видно не в презентациях, а в логах.
Сегодня расскажу, как ИИ реально чувствует себя в веб-безопасности и как влияет на борьбу атакующих и защитников.
Что именно изменилось в атаках из-за ИИ
Если смотреть на классы атак, ничего революционного не появилось. Те же credential stuffing, те же атаки на API, те же обходы бизнес-логики, тот же фишинг. Изменился не класс, а поведение.
Раньше существовало жесткое разделение. Массовая атака была дешевой и примитивной. Целевая — дорогой и штучной. Если злоумышленник хотел качественную кастомизацию, ему нужно было тратить время: изучать компанию, адаптировать payload, проверять гипотезы. Сейчас это ограничение исчезло.
В одной кампании мы можем видеть десятки тысяч запросов, которые формально не похожи друг на друга. Разные структуры, разные параметры, разная последовательность действий. User-Agent согласован с TLS-профилем. Accept-Language соответствует географии IP. Тайминги выглядят «человеческими». Даже навигационная модель по сайту выглядит правдоподобно. Это не просто рандомизация, как было раньше для обхода примитивных фильтров. Это генерация под контекст конкретного ресурса. МL-модель анализирует публичные данные: структуру фронта, особенности API, типовые сценарии использования. После этого формируется нагрузка, которая не выглядит инородной.
Если раньше защита опиралась на повторяемость структуры, то теперь повторяемость ушла на уровень смысла. Снаружи — хаос. Внутри — единая цель.
Второй сдвиг — исчезновение типичных маркеров вредоносности. Мы десятилетиями привыкли к «грязным» атакам: странные заголовки, несоответствие TLS и user-agent, грамматические ошибки в письмах, очевидные аномалии в запросах. Сегодня на L7 мы видим атаки, где HTTP-трафик практически неотличим от легитимного: правильные заголовки Accept-Language соответствуют GeoIP, TLS-отпечатки совпадают с заявленными браузерами, даже поведенческие паттерны имитируют человека. Конечно, в этом случае классические эвристики перестают работать, и защите нужно адаптироваться к более сложным поведенческим и контекстным моделям.
Третий момент — скорость. Раньше между разведкой и эксплуатацией был зазор. Сейчас весь цикл — от сканирования поверхности до генерации адаптированной нагрузки — автоматизирован. Мы видим сценарии, где изменения тактики происходят в пределах часов, а иногда и десятков минут. Если ваш цикл «обнаружили — разобрали — написали правило» занимает сутки, вы уже отстали.
Как по телеметрии понять, что перед вами не просто «умный бот»
Слово «ИИ» сейчас используют слишком широко. Поэтому вопрос, который действительно важен: можно ли технически обосновать, что атакующий использует генеративные или обучаемые механизмы, а не просто хорошо написанный скрипт?
Есть несколько признаков, которые сложно объяснить классической автоматизацией.
Первый — полиморфизм при сохранении семантики. Обычный бот меняет параметры по шаблону. Структура запроса остаётся предсказуемой. В генеративной атаке структура может меняться кардинально, но конечное действие остается тем же.
В моей практике был кейс, где при атаке на API мы видели более 10 000 формально разных запросов. Они не группировались сигнатурно: разные пути, разные комбинации параметров, разные тела запросов. Однако если смотреть на бизнес-уровень, все они приводили к одному типу действия над объектом. Когда мы сделали кластеризацию не по структуре, а по эффекту и контексту выполнения, вся эта «разнообразная» масса легла в один сценарий.
Второй индикатор — аномально высокий уровень контекста. В фишинге это использование реальных проектов и терминологии компании. В веб-атаках — корректная работа с токенами, правдоподобная навигация, соблюдение бизнес-логики. Не просто перебор эндпоинтов, а осмысленные переходы. Человек способен сделать это вручную. Но когда такой уровень проработки масштабируется на тысячи сессий, речь идет уже не о скрипте с жесткой логикой.
Третий признак — адаптивность в реальном времени. Классический бот при получении 403 либо повторяет попытки, либо останавливается. В адаптивных атаках мы видим смену тактики: изменение набора заголовков, перераспределение нагрузки, переход на альтернативные точки входа, варьирование таймингов. Это выглядит как механизм принятия решений, а не как заранее зашитый сценарий.
Иногда встречаются и косвенные следы — характерные артефакты генерации или инфраструктурные признаки использования ML-инструментов. Но они вторичны. Главный маркер — поведение.
Кто проигрывает первым
ИИ-атаки выигрывают не потому, что они «умные», а потому что они быстрые и вариативные. Проигрывают не продукты, а подходы, которые выбирают некоторые спецы.Во-первых, в зоне риска команды, которые строят защиту вокруг статичных правил как основного механизма. Я называю их «хранители статичных правил». Если каждая новая волна атак генерируется заново, правило начинает работать только на прошлую версию сценария. Пока вы анализируете инцидент и добавляете новую сигнатуру в WAF, следующая итерация уже выглядит иначе. Сигнатуры не исчезают. Но если они — фундамент, а не вспомогательный слой, вы находитесь в постоянном догоняющем режиме.
Вторая уязвимая модель — команды, выбирающие стратегию быть «тушителями пожаров». Сначала появляется алерт, только потом начинается разбор инцидента. Да, когда-то эта схема может сработать, но благодаря ИИ атаки разворачиваются за минуты, масштабируются на сотни и тысячи целей и при этом адаптируются в процессе. Пока «тушитель пожаров» вручную разбирается с первым эпизодом, атака может завершиться на десятках других объектов.
И третий тип — команды, которые делают упор на защиту сетевого уровня, но плохо контролируют L7. Хорошая защита на L3–L4 сегодня обязательна, но недостаточна. Современные атаки все чаще используют валидный HTTPS, корректную аутентификацию и внешне нормальный трафик. Без анализа логики приложения и поведенческих паттернов на L7 компрометация может происходить тихо и незаметно.
Если говорить в целом, то с ИИ-атаками проблемы возникают, в первую очередь, у команд с медленным циклом реакций и недостаточной автоматизацией процессов. В новой реальности защитникам нужно учиться быть намного быстрее атакующих.
Как изменить подход к детектированию, чтобы не пропускать ИИ-атаки
Теперь давайте поговорим о практике. Что сделать уже сегодня, чтобы не пропускать атаки, созданные с помощью ML. Начать нужно с корректного детектирования. Раньше, когда вы обнаруживали атаку, ее нужно было проанализировать и создать под нее правило. После этого защита обновлялась. Сколько занимал этот процесс? Часы или даже дни. Но, как я говорил выше, при атаках с использованием ИИ весь жизненный цикл часто укладывается в минуты, и к моменту, когда сигнатура готова, атака либо уже завершена, либо изменилась.
Теперь главная задача перейти от анализа отдельных событий к анализу поведения. Отдельный запрос все чаще бесполезен как единица детектирования. Он может быть идеальным с точки зрения синтаксиса. Но последовательность действий в рамках сессии формирует паттерн. Поэтому анализируется не только содержание запроса, но и его место в цепочке, тайминги, распределение интервалов, соответствие типичной пользовательской модели.
Еще один важный аспект — использовать метрики скорости изменений. Фиксированный порог «N запросов в секунду» сегодня легко обходится. Гораздо информативнее смотреть на резкие отклонения: рост нагрузки на сотни процентов за короткий промежуток времени для конкретного источника, сессии или идентификатора. Такой подход ускоряет детектирование автоматизированных атак.Здесь будет уместно упомянуть скоринговую модель, которая дает дополнительную гибкость анализу. Вы можете скомбинировать несколько слабых сигналов: нетипичные отпечатки клиентов, использование прокси-инфраструктуры, аномальные тайминги, история поведения источника. При достижении определенного суммарного порога система принимает решение о блокировке. Это поможет снизить количество ложных срабатываний и позволит лучше адаптироваться к изменяющимся атакам.
Как должна выглядеть эффективная защита против ИИ-автоматизации у атакующих
Важно навести порядок в данных и процессах. Конечно, главным приоритетом является качество данных. Без них не будут работать ни правила, ни ML-модели. Займитесь нормализацией и обогащением информации: не только IP-адрес, но комбинация IP/ASN, геолокация, репутация и история активности; не только user-agent, но отпечаток клиента, консистентность с заголовками. Логировать необходимо и легитимный трафик, иначе у моделей будут некорректное понимание, что является нормой, а что отклонением. Мы на своей практике видим, что инвестирование в качество данных дает мгновенный эффект: меньше ложных срабатываний у ML, даже простые правила работают эффективнее.
Когда с качеством данных разобрались, можно переходить к переобучению моделей на собственных инцидентах. Модели, дообученные на данных конкретного клиента, позволяют снизить количество ложных срабатываний на 40–50% при сохранении чувствительности. И не забывайте про пересборку и ревизию правил. Это гигиена защиты. Не игнорируйте ее.Использование ИИ защитниками
Если атакующие уже используют автоматизацию и генеративные механизмы для масштабирования атак, может ли защита позволить себе оставаться полностью ручной? Очевидно, нет. Человек физически не успевает реагировать на сценарии, которые развиваются в течение минут и генерируют тысячи вариаций запроса. В какой-то момент автоматизация становится не опцией, а необходимостью.
Проблема в другом. В отличие от атакующего, защитник несет ответственность за инфраструктуру и пользовательский опыт. Если атакующий ошибся — у него просто не сработала атака. Если ошиблась система защиты — вы можете сами же заблокировать легитимных пользователей, партнеров или платежные операции.
Поэтому ключевой вопрос сегодня — не «автоматизировать или нет». Вопрос — как сделать это так, чтобы алгоритмы действовали быстро, но не ломали инфраструктуру и не создавали новых рисков.
Автоматизация в веб-защите — это всегда баланс между скоростью реакции и контролем. С одной стороны, чем быстрее система реагирует на аномалию, тем меньше окно для атаки. С другой — чем агрессивнее автоматические действия, тем выше риск ложных блокировок. Поэтому в зрелых системах защиты автоматизация не работает на автопилоте, а встраивается в многоуровневый контур с ограничениями.
Первый принцип — автоматическое реагирование только на явно подозрительные события.
Есть события, по которым практически не возникает сомнений. Например, известные эксплойты, очевидно вредоносные IP-адреса или атаки, которые можно отсеять с помощью rate limiting. Такие сценарии обычно реализуются на уровне WAF и других сигнатурных средств защиты. Но большая часть современного трафика находится в «серой зоне». Это сценарии, которые выглядят подозрительно, но не дают стопроцентной уверенности. Например, нетипичная навигация по API, нестандартная плотность запросов, странные комбинации заголовков. Если такие сессии блокировать мгновенно, неизбежно начнут страдать реальные пользователи. Поэтому вместо немедленной блокировки используются механизмы усложнения поведения. Это может быть дополнительная проверка клиента, JavaScript-челлендж или CAPTCHA. С точки зрения пользователя это выглядит как небольшая дополнительная проверка, а с точки зрения системы — как способ отделить автоматизированный трафик от живого.
Второй принцип — тестирование новых правил и моделей в «прокси-режиме».
Одна из самых частых ошибок при внедрении ML-моделей в защиту — попытка сразу включить их в режиме принятия решений. На практике это почти всегда заканчивается всплеском ложных срабатываний. Поэтому новые модели сначала запускаются в так называемом «теневом» или прокси-режиме. Они анализируют трафик, рассчитывают скоринг, определяют подозрительные сессии — но их решения не применяются к пользователям. Система лишь фиксирует, что произошло бы, если бы автоматизация была активна. За время обучения становится видно, где модель слишком агрессивна, какие сценарии она интерпретирует неправильно и какие параметры нужно скорректировать. Только после этого ее можно постепенно включать в контур реального реагирования.
Третий принцип — ограничение масштаба автоматических действий.
Любая автоматическая система должна иметь встроенные «предохранители». Например, лимит на долю трафика, которую она может заблокировать за определенный интервал времени. Если этот порог превышен, система автоматически прекращает блокировки и передает управление человеку. На практике это выглядит как аварийный рубильник для автоматизации. Он защищает от ситуаций, когда модель или правило начинают работать некорректно — например, из-за изменения пользовательского поведения, ошибки в данных или неожиданного всплеска легитимного трафика.
Наконец, еще один практический принцип — возможность мгновенного отката. Любая автоматическая блокировка должна быть обратимой за секунды. Возможность быстро снять блокировку с IP-диапазона, ASN или конкретного клиента — обязательное требование для продакшн-систем. Иначе даже небольшая ошибка может привести к длительной недоступности сервиса для части пользователей.
Как изменится рынок ИБ в ближайшие годы
Если собрать все сказанное выше, становится понятно, что ИИ меняет не только характер атак и архитектуру защиты. Он постепенно перестраивает сам рынок информационной безопасности — и это уже отражается на людях, процессах и технологиях.
Исторически большая часть операционной работы в ИБ строилась вокруг ручного анализа событий. Аналитики SOC просматривали алерты, сопоставляли логи из разных систем, проверяли IP-адреса, смотрели репутацию инфраструктуры, пытались понять, является ли событие реальной атакой или очередным ложным срабатыванием. Это трудоемкая работа, но при этом значительная ее часть достаточно рутинная.
Рутинный слой – обогащение алертов, корреляция телеметрии, первичный триаж – автоматизируется первым. Системы сами подтягивают контекст, связывают события в цепочки и формируют предварительное расследование.
Это не означает, что аналитики SOC исчезнут как класс. Но их роль будет меняться. Вместо ручного разбора каждого алерта фокус будет смещаться на работу с более сложными сценариями: интерпретацию выводов моделей, поиск нетипичных угроз, анализ сложных атак, которые не укладываются в известные шаблоны. Все больше времени будет уходить на Threat Hunting — поиск аномалий в массиве телеметрии с использованием автоматизированных инструментов.
Одновременно возрастет спрос на специалистов, которые находятся на стыке нескольких дисциплин. Системы защиты становятся все более зависимыми от данных и моделей, поэтому командам нужны люди, которые понимают и архитектуру безопасности, и принципы работы машинного обучения. По сути, формируется новая гибридная роль: инженер безопасности, который умеет работать с данными, настраивать модели, оценивать качество обучения и понимать ограничения алгоритмов.
При этом ценность опытных senior-специалистов только растет. Парадоксально, но чем больше автоматизации появляется в системе, тем важнее становится экспертная оценка. Именно senior-эксперты формируют обучающие выборки, определяют корректные признаки для моделей, принимают решения в пограничных ситуациях и валидируют работу автоматических механизмов. Без этой экспертизы любые модели довольно быстро начинают деградировать.
Про процессы
Изменения коснутся и процессов внутри команд безопасности. Если раньше многие механизмы защиты обновлялись эпизодически — например, при появлении новой сигнатуры или после крупного инцидента, — то с появлением ML-моделей процессы становятся непрерывными. Модели требуют постоянного переобучения, правила постепенно адаптируются под новые сценарии, а анализ телеметрии превращается в непрерывный цикл улучшений. Это меняет и операционную работу. Значительная часть рутинных операций — обогащение событий, первичный анализ, сопоставление источников — будет выполняться автоматически. В некоторых сценариях автоматизация уже сейчас закрывает большую часть первичного расследования. Человек все чаще подключается не на этапе сбора информации, а на этапе интерпретации и принятия решений.
По мере роста зрелости таких систем доля автоматизированных операций может достигать до 80% от общего объема операционной работы. Но финальный контроль, особенно в чувствительных сценариях, останется за людьми. Без этого автоматизация в защите просто слишком рискованна.Про технологии
Наконец, изменения затронут и технологический ландшафт. Чем больше данных используется в защите, тем сложнее становится работать с набором разрозненных инструментов. Корреляция телеметрии, обучение моделей, обработка больших объёмов трафика требуют плотной интеграции. Поэтому рынок постепенно смещается в сторону платформенных решений, где аналитика, детектирование и автоматизация объединены в единую систему. В выигрыше здесь оказываются игроки, которые уже работают с большими потоками трафика и могут использовать их для обучения моделей. Платформы доставки и защиты трафика — CDN, WAF-провайдеры и облачные системы защиты — постепенно начинают интегрировать все больше ML-функциональности прямо в инфраструктуру. Отдельные узкоспециализированные утилиты при этом либо становятся частью более крупных платформ, либо остаются нишевыми инструментами для специфических задач.
Если смотреть на горизонт двух-трех лет, можно ожидать довольно простую вещь: базовые системы защиты без элементов машинного обучения будут восприниматься так же устаревшими, как сегодня веб-сайт без HTTPS. Вопрос будет уже не в том, использовать ли ИИ в защите, а в том, насколько глубоко он встроен в процессы, данные и архитектуру системы. И, пожалуй, это главный вывод. ИИ радикально увеличивает скорость и масштаб как атак, так и защиты. А значит, выигрывать будут те команды и платформы, которые научатся использовать эту скорость, не теряя контроля над системой.
