• Главная
• Технологии
• ИИ против ИИ

ИИ против ИИ

Как машины воюют и почему человек проигрывает в скорости принятия решений

Автор: эксперт в области информационной безопасности, руководитель Target Information Security Лаура Тлепина

Забудьте про статистику - лучше ответьте на один вопрос. Сколько времени и сил нужно, чтобы одновременно атаковать девять государственных систем, хранящих сведения о сотнях миллионов граждан, написать под каждую цель отдельный эксплойт, проанализировать архитектуру 305 внутренних серверов и автоматизировать вывод данных? Пару недель?

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

Это не гипербола, а операционная реальность, которую индустрия кибербезопасности пока не успела осознать в полной мере. В этой колонке я расскажу, как она устроена.

Как это выглядит изнутри?

Разберем реалистичный сценарий, основанный на задокументированных паттернах атак. Атакующий - назовем его оператор - не является техническим гением. У него есть базовые знания о компьютерных сетях, понимание того, что такое уязвимость, да и вообще доступ к ИИ-ассистенту для написания кода. Такой профиль сегодня описывает миллионы людей по всему миру. Оператор начинает с разведки. Он просит ИИ-агента проанализировать публичную информацию о компании - технологический стек, используемые фреймворки, версии ПО, упоминания в репозиториях. ИИ возвращает структурированный отчет за минуты. Раньше этот этап у опытного аналитика занимал несколько дней. Затем шел поиск входной точки. Оператор сообщает агенту известные версии найденного ПО. ИИ сопоставляет их с базами уязвимостей, предлагает кандидатов, ранжирует по вероятности успеха и сложности эксплуатации.

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

Все меняет скорость! Штатная команда безопасности работает линейно: обнаружила аномалию, эскалировала, проанализировала, приняла решение. Атакующий с ИИ на вооружении работает параллельно: пока одна часть атаки развивается, он уже готовит следующую стадию.

Почему это системная проблема

При анализе подобных инцидентов я неизменно натыкаюсь на один и тот же управленческий рефлекс: навести справки по конкретной точке отказа и исправить ее. Обновить ПО. Обогатить мониторинг. Переобучить сотрудников. Эти шаги правильные. Но это описание симптомов, не болезни. Системная проблема как раз в том, что архитектура большинства корпоративных систем безопасности строилась под угрозы, которые движутся с человеческой скоростью. Аналитик в SOC (Центре управления безопасностью) получает алерт, оценивает его приоритет, принимает решение. Этот цикл измеряется минутами и часами. Он эффективен, только пока противник играет по тем же правилам.

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

Как должна выглядеть защита?

Но вернемся к нашему оператору. Что произойдет, если на другой стороне баррикад его встретит организация, которая подготовилась к такому сценарию заранее?

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

Этот подход принципиально меняет логику защиты: вместо «знаем плохое, блокируем его» - «знаем нормальное, все остальное проверяем». В мире, где каждая ИИ-атака уникальна, это единственная архитектура, которая не устаревает.

Второй рубеж - нулевое доверие к авторизации. В описанном сценарии оператор получил доступ к множеству систем, воспользовавшись скомпрометированными учетными данными одного администратора. Это классический каскадный сценарий: одна точка входа открывает множество дверей. Архитектура нулевого доверия (Zero Trust) строится на принципе, противоположном предыдущему: каждый запрос к каждому ресурсу проверяется отдельно от предыдущих и независимо от источника. Пользователь уже за периметром? Не важно. Пользователь пришел из-за периметра? Не важно. Запрос на конкретную систему идет с доверенного устройства? Не важно. Важно только то, кто именно обращается к системе прямо сейчас и совпадает ли это с его историческим паттерном активности. ИИ-агент, получивший украденные учетные данные, ведет себя иначе, чем человек. Мониторинг эту странность в поведении сразу увидит.

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

Четвертый рубеж - ограничение радиуса взрыва. Даже самая лучшая защита рано или поздно будет пройдена. Поэтому ключевой вопрос не в том, как бесконечно сдерживать такой натиск. Вопрос в другом: сколько ущерба нанесет враг, если все-таки сумеет войти? Минимизация ущерба, минимизация последствий - это принцип наименьших привилегий, жесткая сегментация данных, шифрование в покое. Это не паранойя. Это управление последствиями.

Ключевой урок, который не очевиден

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

Вопрос, который стоит задать уже сейчас

Вопрос «Защищены ли мы от ИИ-атак?» - тупиковый. Ответ на него всегда один: «Недостаточно». Правильный вопрос звучит иначе: если атака идет внутри нашей сети прямо сейчас - через сколько минут мы об этом узнаем? И через сколько минут после этого она будет остановлена? Если ответ на первый вопрос измеряется часами, а на второй - требует участия аналитика в рабочее время - это и есть реальная поверхность уязвимости. Не техническая, а процессная.

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

При работе с материалами Центра деловой информации Kapital.kz разрешено использование лишь 30% текста с обязательной гиперссылкой на источник. При использовании полного материала необходимо разрешение редакции.

Вам может быть интересно

Читайте Kapital.kz в