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