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