Пользователь спрашивает AI-поиск, где войти в личный кабинет или как связаться с поддержкой. Ответ выглядит уверенно, но ведёт на вредный домен или повторяет ложную инструкцию. Для жертвы это не письмо от незнакомца, а рекомендация системы, которой она уже доверяет.
Такой сценарий меняет привычную модель фишинга. Злоумышленник может не отправлять письмо напрямую: он публикует оптимизированные страницы, подделывает контекст, создаёт сеть однотипных материалов и ждёт, что AI-поиск включит их в ответ. Защитникам нужно проверять не только почтовый поток, но и то, как внешние AI-сервисы описывают компанию.
Практический вопрос для SOC: какие домены и инструкции появляются в AI-ответах рядом с нашим брендом, входом, поддержкой, оплатой и восстановлением доступа. Если этот слой не мониторить, фишинг будет обнаружен только после жалоб пользователей.
Цель защиты — быстро заметить подмену, заблокировать инфраструктуру, отправить жалобы провайдерам и обновить пользовательские предупреждения.
Как выглядит атака в защитном разборе
Атакующий создаёт страницы, которые выглядят как справочный контент, инструкции или обсуждения проблемы. Они оптимизируются так, чтобы AI-система посчитала их релевантными. Затем в ответе появляется ссылка, номер поддержки, ложная процедура восстановления или совет отключить защитную настройку.
Следы остаются не в одном месте. Их нужно искать в поисковой выдаче, реферерах, обращениях к поддельным доменам, жалобах пользователей и всплеске однотипных запросов в поддержку.
- появились похожие страницы с названием бренда;
- новые домены имитируют поддержку или вход;
- пользователи приходят с необычных рефереров;
- поддержка получает жалобы на советы AI;
- почтовая защита видит переходы после поиска;
- угрозные домены используют свежую регистрацию;
- текст приманок повторяет одну и ту же инструкцию.
Процесс мониторинга бренда
Команда должна регулярно проверять ключевые пользовательские вопросы в популярных AI-поисковых системах и чатах: вход, поддержка, восстановление доступа, оплата, отмена подписки, установка приложения. Для каждого ответа фиксируются домены, формулировки и уровень риска.
Если найден вредный совет, важна скорость: блокировка домена, обращение к провайдеру, предупреждение пользователей и обновление правил прокси должны происходить в один день.
- составить список чувствительных запросов о бренде;
- проверять ответы AI-поиска по расписанию;
- сравнивать найденные домены с разрешённым списком;
- создать канал жалоб от поддержки в SOC;
- добавить вредные домены в SWG и почтовые фильтры;
- фиксировать скриншоты и ссылки для жалобы;
- обновлять предупреждения для пользователей.
Журналы, без которых расследование слепнет
Контроль бесполезен, если после срабатывания команда не может доказать, какие данные были обработаны, какое правило применилось и кто подтвердил действие. Поэтому журналирование нужно проектировать до запуска AI-функции, а не после первого инцидента.
Для чувствительного контекста лучше сохранять не полный текст, а безопасные признаки: класс данных, источник, хеш, идентификатор политики, итоговое действие и причину решения. Это уменьшает риск повторной утечки через сами журналы.
- user_id и роль пользователя;
- device_id и доверенность устройства;
- source_system и тип источника;
- model_version и версия политики;
- политика_id и причина решения;
- resource_id и класс данных;
- action_type и итог операции;
- risk_score и главные признаки риска.
Как включать контроль постепенно
Сначала правило работает в режиме наблюдения и собирает статистику. Затем команда проверяет ложные срабатывания, корректирует исключения и только после этого включает блокировку для критичных действий. Такой порядок снижает риск остановить рабочий процесс из-за неудачного правила.
Исключения должны иметь срок жизни и владельца. Постоянное исключение без объяснения почти всегда превращается в скрытый обход политики.
- запустить правило в режиме наблюдения;
- собрать примеры нормальных и подозрительных событий;
- разделить предупреждение и остановку;
- назначить владельца каждого исключения;
- проверить правило на старых инцидентах;
- описать процедуру аварийного отката;
- пересматривать шумные правила каждую неделю.
Метрики качества защиты
После внедрения важно измерять не число созданных правил, а то, стала ли система управляемее. Хорошая метрика показывает, быстрее ли команда замечает риск, меньше ли ручных исключений и достаточно ли доказательств для аудита.
Для AI-сценариев полезно считать связку из нескольких сигналов. Один запрос к модели может быть нормальным, но запрос вместе с доступом к секрету, внешним доменом и новым токеном уже требует реакции.
- среднее время от сигнала до triage;
- доля событий с полным набором журналов;
- число подтверждённых инцидентов после корреляции;
- количество постоянных исключений;
- скорость отзыва ключей и токенов;
- доля тестов, прошедших без ручной доработки.
Карта ответственности
У каждой меры должен быть владелец: SOC расследует события, AppSec проверяет приложение и зависимости, владелец данных оценивает чувствительность, инфраструктурная команда управляет сетью и ключами, руководитель риска утверждает исключения.
Если роли не прописаны заранее, инцидент превращается в переписку между командами. Карта ответственности должна храниться рядом с описанием системы и обновляться после каждого изменения.
- SOC отвечает за корреляцию и приоритет;
- AppSec проверяет код и настройки;
- владелец данных определяет допустимый контекст;
- инфраструктура отзывает ключи и меняет сеть;
- юридическая функция оценивает уведомления;
- руководитель риска утверждает остаточный риск.
Проверка на учебных сценариях
Перед включением блокировки команда должна провести учебную проверку. Один сценарий описывает нормальную работу, второй — подозрительное поведение, третий — попытку обойти правило через косвенный источник. Такой набор показывает, где контроль действительно видит риск, а где просто реагирует на отдельное слово.
Результаты проверки сохраняются как доказательства: входные условия, ожидаемое решение, фактическое решение, журналы и ответственный владелец. Это помогает не спорить о качестве контроля после первого реального срабатывания.
- проверить нормальный рабочий запрос;
- проверить внешний недоверенный источник;
- проверить попытку передачи чувствительных данных;
- проверить блокировку опасного действия;
- проверить понятность алерта для аналитика;
- сохранить журналы и итоговое решение.
