В расследовании видно, что злоумышленник быстрее обычного переходит от разведки к проверке гипотез, исправляет ошибки скриптов и создаёт несколько вариантов фишингового текста за короткое время. Это не доказывает применение AI само по себе, но меняет рабочую гипотезу SOC: атака может развиваться быстрее, чем стандартный плейбук реагирования.
Практическая задача защиты — не спорить, “используется ли AI в атаке или в бизнес-процессе”, а построить проверяемый контроль вокруг AI-ускорение этапов атаки. Если контроль зависит только от доверия к пользователю или к модели, он не выдержит масштабирования, ошибки поставщика или действий злоумышленника.
Первый слой работы — инвентаризация. Команда должна знать, какие сервисы участвуют в процессе, какие данные им доступны, кто владелец, где хранятся журналы и какие действия могут выполняться автоматически. Без этого невозможно отличить нормальное ускорение работы от опасного обхода политики.
Второй слой — наблюдаемость. Для SOC и команды управления рисками важны не красивые отчёты, а события, которые можно связать между собой: пользователь, действие, источник данных, модель, время, решение политики и результат. Тогда расследование опирается на факты, а не на пересказ пользователя.
Минимальные контроли
- измерять время между разведкой, доставкой, запуском и закреплением
- искать серии похожих вариантов писем и скриптов
- контролировать обращения заражённых узлов к внешним AI-сервисам
- повышать приоритет при быстрой смене тактики после блокировки
- использовать поведенческие правила, а не только индикаторы
- фиксировать признаки машинной скорости в карточке инцидента
Эти контроли лучше включать поэтапно. Сначала режим наблюдения собирает базовую картину поведения, затем мягкие ограничения предупреждают владельцев, и только после настройки исключений включаются блокировки. Такой порядок снижает шум и помогает отделить критичные сценарии от обычных рабочих ошибок.
Важно не переносить решение внутрь подсказки. Модель может помочь классифицировать риск, объяснить событие или подготовить краткую сводку, но право доступа, лимит, блокировка и исключение должны находиться во внешнем коде, политике, IAM, DLP или сетевом контроле. Иначе пользователь сможет получить больше данных, чем ему разрешено.
Что писать в журналы
- время первого события
- переход между этапами
- тип внешнего сервиса
- объём исходящих запросов
- варианты полезной нагрузки
- язык сообщения
- результат EDR
- новые домены
- изменение тактики
- решение аналитика
Журналы должны быть полезны для расследования и при этом не превращаться во вторую утечку данных. Поэтому чувствительные тексты лучше хранить в усечённом или обезличенном виде, а полный доступ оставлять только ограниченной группе с отдельным аудитом. Для большинства проверок достаточно класса данных, источника, решения политики и идентификатора события.
Для обнаружения полезны не только отдельные сигналы, но и последовательности. Один запрос может быть нормальным, а серия похожих действий за короткое время уже показывает автоматизацию, подбор обхода или массовое извлечение данных. Поэтому правило должно смотреть на темп, разнообразие действий, смену источников и реакцию после отказа.
- если пользователь быстро меняет формулировки после отказа, риск повышается;
- если сервис обращается к данным вне обычной роли, событие уходит в разбор;
- если новый ключ сразу создаёт большой объём запросов, включается ограничение скорости;
- если модель используется из заражённой среды, внешние AI-сервисы блокируются;
- если исключение не имеет владельца и срока, оно удаляется автоматически.
Для проверки внедрения нужна короткая таблица ответственности. В ней указываются владелец процесса, владелец данных, владелец технического контроля, канал эскалации и действие по умолчанию. Если спорное событие не разобрано вовремя, система должна не ждать бесконечно, а переводить процесс в безопасный режим.
План внедрения на месяц
В первую неделю команда собирает реестр сервисов, ключей, интеграций и владельцев. Во вторую неделю включает передачу событий в SIEM и сверяет их с журналами приложений. В третью неделю настраивает DLP, лимиты и правила корреляции. В четвёртую неделю проводит тест отказа: что произойдёт, если AI-сервис недоступен, ключ украден или данные ошибочно попали в запрещённый контекст.
- проверить, что каждый сервис имеет владельца и категорию данных;
- связать журналы AI-сервиса с событиями IAM, почты, EDR и DLP;
- создать тестовые события для блокировки и режима наблюдения;
- проверить отзыв доступа и ротацию ключей;
- утвердить метрики для ежемесячного отчёта CISO.
Главная метрика зрелости — способность объяснить событие через несколько недель после него. Команда должна видеть, кто инициировал действие, какая политика применялась, какие данные были доступны, почему система разрешила или заблокировала операцию и кто подтвердил исключение.
Такой подход не мешает использовать AI. Напротив, он делает внедрение устойчивым: бизнес получает скорость, SOC получает телеметрию, AppSec получает проверяемые требования, а руководитель безопасности видит не обещания, а управляемый риск с числами, владельцами и журналами.
Проверка качества контроля
После включения правил важно проверить не только факт блокировки, но и качество объяснения. Аналитик должен видеть, какое правило сработало, какие данные были задействованы, какой владелец получил уведомление и почему система выбрала именно это действие. Если событие нельзя объяснить без ручного поиска по нескольким панелям, контроль ещё не готов к промышленному использованию.
- событие должно иметь единый идентификатор во всех журналах;
- решение политики должно храниться рядом с исходным контекстом;
- исключение должно иметь владельца, срок и причину;
- повторное нарушение после предупреждения должно повышать критичность;
- отчёт для владельца процесса должен быть понятен без доступа к сырым данным.
Отдельно стоит настроить контроль изменений. Любое расширение доступа модели, подключение нового источника данных, изменение поставщика, новый тип вложения или новая интеграция должны запускать повторную проверку. Это защищает от ситуации, когда безопасная пилотная схема постепенно превращается в неконтролируемую рабочую систему.
Команда может использовать простую шкалу зрелости: нулевой уровень — сервис неизвестен безопасности; первый — сервис есть в реестре; второй — события попадают в SIEM; третий — работают лимиты и DLP; четвёртый — проверены сценарии отказа; пятый — метрики риска регулярно обсуждаются с владельцами процессов.
