Дежурный аналитик видит необычную цепочку: пользовательский процесс обращается к внешним AI API, после этого запускает скриптовый интерпретатор, проверяет окружение и меняет сетевое поведение. По отдельности события похожи на шум, но вместе они могут показывать новый класс вредоноса, где AI используется как логика выбора следующего шага.
В такой атаке модель не обязательно генерирует весь вредоносный код. Она может оценивать окружение, выбирать вариант обхода, помогать классифицировать найденные данные или решать, стоит ли продолжать. Для SOC это меняет привычную картину: часть решений переносится из статического кода во внешние ответы модели.
Защитная задача — увидеть связь между обращением к модели и последующим действием на рабочей станции. Если организация разрешает AI-сервисы только в управляемых инструментах, любой непонятный процесс с такими запросами уже должен повышать риск события.
Разбор важно строить без попытки повторять вредоносную цепочку. Достаточно описать телеметрию, слабые места и технические барьеры, которые мешают вредоносу использовать модель как советчика.
Какие признаки искать в телеметрии
Первый слой признаков — сетевой. Вредоносный процесс может обращаться к модельным API, прокси, необычным доменам или инфраструктуре, где раньше не было трафика. Второй слой — локальные действия после ответа: запуск интерпретатора, чтение профиля браузера, просмотр окружения, проверка защитных служб.
Наиболее ценный сигнал появляется при корреляции. Если обращение к AI API само по себе разрешено, но сразу после него процесс меняет поведение, создаёт новый файл или открывает соединение к неизвестному адресу, событие должно попасть в охоту.
- процесс без бизнес-назначения обращается к AI API;
- после ответа запускается интерпретатор или системная утилита;
- появляются короткие серии разведочных команд;
- процесс читает переменные окружения и профили браузера;
- в трафике видны повторяющиеся небольшие запросы;
- EDR фиксирует смену дочерних процессов;
- пользователь не работает с разрешённым AI-инструментом.
Как ограничить AI-канал для вредоноса
Главная защита — не пытаться угадывать все варианты ответов модели, а ограничить сам канал. Рабочие станции не должны свободно обращаться к произвольным AI API, если для этого нет утверждённого бизнес-процесса. Разрешённые инструменты проходят через управляемый прокси с журналированием и проверкой источника.
Дополнительно нужно защищать ключи. Если вредонос получает токен к корпоративному AI-сервису, он может выглядеть как легитимный клиент. Поэтому токены должны быть привязаны к устройству, роли и приложению.
- использовать фильтрацию исходящих соединений по категориям сервисов;
- разрешать AI API только через управляемый шлюз;
- привязывать токены к устройству и приложению;
- запрещать хранение ключей в профиле пользователя;
- создать алерт на новый AI-домен с рабочей станции;
- сравнивать процесс-инициатор с разрешённым списком;
- ротировать ключи после подозрительного обращения.
Как внедрить контроль без шума
Контроль должен начинаться с режима наблюдения. Команда собирает события, проверяет ложные срабатывания и только потом включает блокировку. Такой подход особенно важен для AI-сценариев, где сигнал часто распределён между сетью, приложением, учётной записью и рабочим местом.
После запуска нужно заранее определить владельца каждого правила. Иначе сработавший детект будет висеть в очереди, а исключение быстро превратится в постоянную дыру.
- описать допустимые действия и источники данных;
- включить сбор событий до включения блокировки;
- разделить правила предупреждения и остановки;
- назначить владельца исключений;
- проверять правила на старых инцидентах;
- фиксировать версию модели, политики и набора признаков;
- проводить еженедельный разбор шумных срабатываний.
Минимальные поля журналирования
Расследование не должно зависеть от памяти аналитика. В событии должны быть видны пользователь, устройство, процесс, сетевое направление, источник контекста, принятое решение и причина этого решения. Если модель или AI-сервис участвовали в цепочке, важно сохранить не только ответ, но и безопасный краткий отпечаток запроса.
Для чувствительных данных лучше сохранять не полный текст, а хеш, метку класса, источник и решение фильтра. Это снижает риск повторной утечки во время расследования.
- user_id и роль пользователя;
- device_id и доверенность устройства;
- имя_процесса и путь запуска;
- целевой_домен и категория назначения;
- model_version и режим применения;
- policy_id и причина решения;
- risk_score и список главных признаков;
- action_type и итог операции.
План проверки после публикации
После внедрения контроля нужна проверка на безопасных сценариях. Команда создаёт несколько имитаций: нормальный рабочий процесс, подозрительную активность, попытку обойти правило и аварийный откат. Если контроль видит только один сценарий, он не готов к промышленной эксплуатации.
Отдельно проверяется реакция людей. Оповещение должно объяснять, что произошло, какие доказательства уже собраны, какое действие разрешено и где граница самостоятельного решения аналитика.
- проверить нормальный сценарий без блокировки;
- проверить подозрительный сценарий с предупреждением;
- проверить критичный сценарий с остановкой;
- убедиться, что есть процедура отката;
- проверить качество описания алерта;
- сохранить доказательства для аудита;
- обновить контрольный лист после теста.
Карта ответственности
Чтобы контроль не остался набором рекомендаций, у каждого действия должен быть владелец. SOC отвечает за обнаружение и корреляцию, AppSec — за проверку кода и зависимостей, владелец продукта — за допустимый сценарий, команда инфраструктуры — за ключи, сеть и журналы. Если роли не указаны заранее, инцидент превращается в обмен сообщениями без решения.
Для каждой системы полезно хранить короткую карточку: какие данные обрабатываются, какие AI-сервисы используются, какие ключи применяются, где расположен журнал, кто имеет право остановить процесс и как быстро это должно быть сделано. Такая карточка помогает провести расследование без долгого поиска владельцев.
- SOC собирает события и определяет приоритет;
- AppSec проверяет код, зависимости и настройки;
- владелец данных оценивает чувствительность контекста;
- инфраструктурная команда отзывает ключи и меняет сеть;
- юридическая функция оценивает уведомления и последствия;
- руководитель риска утверждает исключения и сроки.
Метрики качества защиты
После внедрения контроля нужно измерять не количество созданных правил, а их пользу. Хорошая метрика показывает, стал ли инцидент заметнее, сократилось ли время реакции, уменьшилось ли число ручных исключений и появились ли понятные доказательства для разбора.
Если правило создаёт много шума, его не нужно сразу отключать. Сначала стоит разделить слабый сигнал, требующий накопления, и критический сигнал, требующий остановки. Для AI-сценариев это особенно важно: один запрос может быть нормальным, а последовательность из запроса, запуска процесса и обращения к секретам уже становится подозрительной.
- среднее время от сигнала до triage;
- доля событий с полным набором журналов;
- число подтверждённых инцидентов после корреляции;
- количество постоянных исключений;
- скорость отзыва ключей и токенов;
- доля тестов, прошедших без ручной доработки.
