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