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