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