Пользователь получает письмо, которое не похоже на массовую рассылку. Тон подобран под его роль, тема выглядит рабочей, а переход к действию развивается постепенно. Даже если кампания не заявляет прямое использование AI, именно такие сценарии показывают, почему SOC больше не может полагаться только на индикаторы и старые шаблоны фишинга.
AI снижает стоимость персонализации: проще менять язык, стиль, контекст, предлог и последовательность сообщений. Для защитника это означает, что один и тот же фишинговый план может быстро превращаться в десятки вариантов, где меняются домены, формулировки и момент доставки.
Практическая задача SOC — отслеживать не только конкретный адрес или вложение, а развитие план: как строится доверие, когда появляется просьба о действии, какие аккаунты получают похожие сообщения и какие входы происходят после клика или ответа.
Такой разбор остаётся защитным: цель не повторить атаку, а выделить следы, которые помогут поймать персонализированную социальную инженерию до кражи учётных данных.
Сигналы эволюции кампании
Классический IOC быстро устаревает. Домен меняется, письмо переписывается, вложение исчезает, но структура воздействия остаётся: знакомый контекст, доверительный тон, постепенный переход к ссылке или файлу, а затем попытка получить доступ.
SOC должен хранить признаки сценария как отдельные объекты. Это помогает увидеть, что разные письма относятся к одной кампании даже без совпадающих ссылок.
- похожий предлог переписки;
- повторяющаяся роль жертвы;
- медленное наращивание доверия;
- переход между каналами;
- новый домен после первого ответа;
- попытка входа после взаимодействия;
- создание почтовых правил после компрометации.
Корреляция почты и идентичности
Защитный разбор должен связывать письмо с событиями входа. Если после подозрительного сообщения появляется вход из новой сети, смена устройства, создание правила пересылки или доступ к редким документам, это уже не отдельный фишинговый шум, а возможная цепочка компрометации.
Особое внимание нужно уделять пользователям, которые работают с внешними партнёрами, исследованиями, политикой AI или чувствительными проектами. Для них персонализированный предлог выглядит особенно убедительно.
- связать письмо с входом;
- проверить новый ASN;
- проверить новое устройство;
- искать правила пересылки;
- искать загрузку документов;
- сравнить темы сообщений;
- поднять похожие жалобы пользователей.
Обновление правил SOC
Правила должны описывать поведение, а не только конкретную строку. AI-персонализация делает текст более разнообразным, поэтому полезнее искать сочетания: новая переписка, нетипичный отправитель, просьба перейти в другой канал, затем рискованный вход или попытка сброса MFA.
Пользовательская кнопка жалобы остаётся важной. Даже один ранний сигнал от сотрудника может раскрыть кампанию, если SOC умеет быстро найти похожие цепочки у других адресатов.
- оценивать намерение письма;
- учитывать историю отношений;
- искать смену канала;
- связывать жалобы пользователей;
- проверять входы после клика;
- обогащать домены разведданными;
- отдельно отслеживать целевые группы.
Контрольные журналы
Любой AI-помощник в процессе проверки должен оставлять следы. Команде нужны не только итоговые выводы, но и исходная гипотеза, источник данных, шаг проверки, решение человека и причина отклонения. Без этого нельзя понять, помогла модель или просто убедительно описала ошибку.
Журналы лучше сразу приводить к единой схеме. Тогда события из репозитория, тестовой среды, почты, облака и SIEM можно связать в одну временную линию.
- идентификатор задачи;
- источник гипотезы;
- данные, переданные модели;
- ссылка на ручную проверку;
- решение политики;
- результат теста;
- владелец исправления;
- срок повторной проверки.
Практический порядок внедрения
Начинать нужно с режима наблюдения. Команда выбирает один процесс, собирает реальные события, считает шум и только затем включает обязательные проверки для критичных случаев. Это снижает риск, что новая AI-функция создаст красивые отчёты, но не улучшит безопасность.
Для каждого правила назначается владелец. Он отвечает за качество сигнала, исключения, срок действия правила и связь с рабочим процессом.
- описать процесс до внедрения AI;
- выбрать один ограниченный сценарий;
- собрать события за две недели;
- проверить ложные срабатывания;
- назначить владельца правила;
- описать исключения;
- включить обязательную проверку только для критичных зон.
Метрики результата
Успех измеряется не количеством сгенерированных отчётов. Важно видеть, сократилось ли время проверки, уменьшилось ли число пропущенных дефектов, стали ли доказательства полнее и не выросла ли нагрузка на аналитиков.
Если метрика не улучшается, контроль нужно сузить. Узкое правило, которое стабильно ловит один риск, ценнее широкой модели, создающей поток неподтверждённых замечаний.
- время до подтверждённой гипотезы;
- доля воспроизводимых находок;
- число ложных отчётов;
- доля задач с доказательствами;
- время назначения владельца;
- число повторных дефектов;
- доля ручных исключений.
Разбор инцидента после срабатывания
Когда правило сработало, команда не должна ограничиваться отметкой «подтверждено» или «ложно». Нужна короткая послесобытийная карточка: что увидели первым, какой сигнал оказался решающим, какие данные были недоступны и какое действие действительно остановило риск. Такая карточка превращает один случай в материал для улучшения процесса.
Особенно важно фиксировать пропущенные события. Если модель предложила полезную гипотезу, но журнал не позволил её проверить, проблема находится не в модели, а в наблюдаемости. Если журнал был полным, но правило не сработало, нужно менять логику корреляции.
- первый замеченный сигнал;
- решающий артефакт;
- недостающий журнал;
- решение аналитика;
- действие владельца системы;
- срок исправления;
- обновление правила обнаружения.
Как снизить шум без потери риска
AI-подходы часто создают много похожих выводов. Если отправлять их напрямую разработчикам или аналитикам, доверие быстро исчезает. Нужно группировать сигналы по причине, активу и владельцу, а не показывать каждую формулировку как отдельный инцидент.
Хороший фильтр не скрывает риск, а объединяет повторяющиеся симптомы. Например, десять похожих предупреждений о доступе к чужим объектам должны стать одной задачей по проверке авторизации, а не десятью независимыми карточками. Для SOC похожие письма объединяются в кампанию, а не в десятки несвязанных жалоб.
- объединять события по корневой причине;
- сохранять первичные доказательства;
- назначать одного владельца;
- показывать частоту повторов;
- оставлять возможность раскрыть детали;
- разделять риск и шум;
- проверять качество правила раз в месяц.
