Сотрудник получает правдоподобное сообщение, проходит похожий на штатный сценарий входа, а спустя несколько минут в облаке появляются новые сессии, необычные обращения к данным и правила почты. Качество текста письма уже не главный признак: AI помогает делать приманку локальной, персональной и убедительной. SOC должен смотреть на телеметрию личности и облака: привязку устройства, новую сессию, согласие приложения, массовое чтение файлов и изменения в почте.
Защитная работа начинается не с доверия к одному сигналу, а с описания цепочки. Нужно понять, кто выполняет действие, какой источник данных затронут, какое решение политики принято и почему событие отличается от обычного поведения. Без такой связки AI-сигнал превращается в красивую подсказку, но не помогает остановить риск.
Для внедрения нужен ограниченный сценарий. Команда выбирает одну поверхность: облачные роли, AI-приложение или облачный вход после фишинга. Затем описывает нормальное поведение, обязательные поля журнала, владельца реакции и условия, при которых событие становится инцидентом.
Важно заранее разделить предупреждение, проверку и блокировку. Низкий риск добавляется в контекст аналитика. Средний риск требует подтверждения владельца. Высокий риск запускает ограничение доступа, отзыв сессии, остановку действия или ручную эскалацию.
Контрольная схема
- считать качество письма слабым сигналом и опираться на телеметрия личности
- отслеживать новую привязку устройства и необычную сессию
- сверять вход с условным доступом, географией и устройством
- контролировать согласия OAuth-приложений и новые права
- искать массовые обращения к SharePoint, OneDrive и Graph
- проверять правила почты, пересылку и делегирование
- включать дополнительная проверку и защита токенов для высокого риска
Первый запуск лучше проводить в режиме наблюдения. В течение недели правило собирает события, но не мешает процессу. Аналитик сравнивает результаты с ручной проверкой, отмечает ложные срабатывания и добавляет недостающие поля. Только после этого часть условий можно перевести в предупреждение или блокировку.
Объяснимость важнее сложной модели. Если аналитик не может понять, почему событие попало в высокий риск, он не сможет защитить решение перед владельцем процесса. Поэтому каждая оценка должна раскладываться на простые признаки: новый источник, необычная операция, несвойственный объём, изменение прав или нарушение политики.
Что логировать
- пользователь
- идентификатор сессии
- устройство
- привязка ключа доступа
- источник сети
- условный доступ
- OAuth-приложение
- права согласия
- обращение к файлам
- правило почты
- объём выгрузки
Журнал должен хранить минимум, достаточный для расследования. Не нужно копировать чувствительные документы, полный текст запроса или содержимое файлов в открытый индекс. Достаточно ссылки на защищённое хранилище, класса данных, хэша, решения политики и идентификатора цепочки.
Корреляция строится вокруг общего идентификатора. Он должен связывать пользователя, сессию, облачное действие, решение политики, событие SIEM и итоговую реакцию. Если данные остаются в разных системах без связи, расследование снова превращается в ручной поиск.
- назначить владельца каждого правила;
- задать срок реакции для высокого риска;
- хранить причину исключения и дату пересмотра;
- проверять полноту полей после каждого изменения источника;
- сохранять безопасные тестовые события для регрессии;
- разделять бизнес-исключение и технический сбой.
Метрики нужны для управления шумом. Команда должна видеть долю событий с полным контекстом, число подтверждённых рисков, среднее время реакции, количество ложных срабатываний и долю случаев, где автоматическое решение было изменено человеком.
План внедрения
За первый день можно описать сценарий, владельцев и минимальные поля журнала. За неделю — собрать события, проверить корреляцию и подготовить безопасные тесты. За месяц — перевести надёжные условия в предупреждение, а самые уверенные в автоматическую остановку с возможностью отката.
- описать нормальное и рискованное поведение;
- выбрать источники журналов и проверить права доступа;
- создать запросы для базовой выборки;
- добавить оценку риска и пороги эскалации;
- провести тест на безопасных примерах;
- утвердить порядок блокировки и отката;
- пересматривать правило после каждого ложного срабатывания.
Типовая ошибка — пытаться автоматизировать всё сразу. Лучше начать с небольшого набора признаков, которые хорошо объясняются и имеют понятное действие. Например, новая облачная роль с необычным регионом, AI-приложение с доступом к чужим данным или сессия после подозрительного входа.
Вторая ошибка — доверять зелёному индикатору без проверки цепочки. Чистый скан, нормальный вход или привычная роль ещё не доказывают безопасность. Риск часто появляется между системами, где модель, права и бизнес-логика соединяются в одно действие.
Проверка зрелости
Раз в месяц команда берёт три события: подтверждённый риск, ложное срабатывание и спорный случай. Для каждого события нужно восстановить источник, контекст, решение политики, владельца реакции и итог. Если это нельзя сделать по журналам, контроль считается незрелым.
- проверить, что событие имеет владельца;
- убедиться, что решение политики не пустое;
- найти ссылку на первичный источник;
- проверить дату пересмотра исключений;
- оценить, какие поля не помогли расследованию;
- добавить новый тест для обнаруженного обхода.
Итоговая цель — не заменить аналитика, а дать ему проверяемую картину. Когда видны источник, поведение, политика, владелец и действие, AI помогает ускорить защиту, но не скрывает риск за непрозрачной рекомендацией.
Контрольный список для владельца
Перед переводом правила в постоянный режим владелец процесса должен подтвердить, что контроль не ломает нормальную работу и действительно снижает риск. Для этого достаточно короткой проверки по журналам, правам и реакции команды. Если хотя бы один пункт не проходит проверку, правило остаётся в режиме наблюдения.
- подтвердить владельца данных и владельца действия;
- проверить, что правило не хранит лишние чувствительные сведения;
- сравнить событие с прошлым поведением пользователя или роли;
- убедиться, что исключение имеет срок окончания;
- проверить, что блокировка имеет безопасный откат;
- сохранить пример для будущей проверки качества.
Такой список дисциплинирует внедрение. Он превращает AI и аналитику поведения в управляемый защитный процесс: событие понятно, риск объясним, данные защищены, а решение можно проверить после инцидента или аудита.
