Оповещение с предупреждающим треугольником остановлено перед архивом рядом с пустым ложементом данных.
Блог

ИИ закрывает оповещения в SOC: какие проверки нужны до запуска

Опубликовано:

Разрешая ИИ-агенту закрывать оповещения, руководитель SOC передаёт ему решение о том, какие сигналы больше не требуют разбора. Проверять нужно основания такого решения, включая случаи, когда агент уверенно сообщает, что угрозы нет.

В исследовании Alert-Bench самопроверка Self-Refine исправила 16 неверных решений и превратила 79 верных в ошибки. Агент повторно оценивал ответ в том же контексте. Эксперимент с GPT-4.1 на одном стенде показывает, почему добавление проверки «подумай ещё раз» тоже требует испытания: повторный ответ может ухудшить результат.

Пустой поиск ещё не обосновывает закрытие

В трассах Alert-Bench 211 из 602 расследований, ошибочно завершившихся закрытием атакующего оповещения, закончились без получения записей. Авторы суммировали результаты пяти стратегий. Это расследования оповещений, а не 602 независимых инцидента.

Пустая выдача отвечает на вопрос, вернул ли конкретный поиск записи. Её недостаточно, чтобы установить безопасность события. Если агент принимает отсутствие результатов за основание закрыть сигнал, пробел расследования превращается в положительный вердикт. Наблюдение в трассах не доказывает, что пустой поиск всегда вызывает ошибку, но даёт конкретный случай для испытания.

В пилоте стоит отдельно проверить, как агент поступает с таким пробелом. При отсутствии записей следует требовать обоснования достаточности расследования, прежде чем разрешать закрытие. Сам факт выполненного запроса этого обоснования не даёт.

Отдельная роль проверяет основания решения

Самопроверка из вступления оставляет агента в контексте собственного ответа. В той же работе авторы предложили протокол AIDA с отдельным оспариванием решения. Сначала исследователь фиксирует вывод и свидетельства. Затем другая роль получает этот вывод и общие свидетельства без приватных рассуждений автора.

Возражение и исходное решение рассматривает Judge, роль оценщика. Он проверяет достаточность оснований: для закрытия нужны свидетельства безопасности либо достаточно полное расследование. Если конкретный пробел способен изменить решение, оценщик запрашивает недостающие данные.

Такую проверку можно испытывать по её результатам: какие основания она приняла и какой пробел потребовала устранить. Разделение контекстов ролей само по себе не означает независимость моделей и не гарантирует отсутствие пропусков. Для пилота полезен именно механизм проверки свидетельств, а не количество агентов в схеме.

Поздние данные проверяют результат настройки

В исследовании REFINE использовали DeepSeek-V3.2 и данные одного SOC. Для каждого из четырёх сценариев взяли 100 ранних оповещений для настройки и 150 более поздних, не пересекающихся с ними, для проверки.

На ранних наборах полнота составила 1,0. На позднем наборе Host-Process она снизилась до 0,807; в трёх остальных сценариях сохранилась 1,0. Это средние результаты трёх запусков. Полнота здесь показывает, какую долю оповещений, требовавших эскалации по решениям аналитиков, система также направила дальше. Метками служили решения сотрудников этого SOC, поэтому показатель не измеряет обнаружение всех реальных вторжений.

Успех на данных настройки не установил тот же результат на поздних данных во всех сценариях. Проверочную выборку для пилота следует отделить по времени и оценить ошибочные закрытия по каждому сценарию. Общий удачный результат не должен скрывать ухудшение в одном из них.

Когда передавать полномочие закрытия

Пилот должен позволять разобрать ошибочное закрытие: какие записи агент получил, чем обосновал безопасность и прошёл ли этот способ принятия решения проверку на поздних данных. Если пустая выдача завершает расследование без достаточных оснований, полномочие закрывать такие сигналы передавать рано.

Практический следующий шаг для руководителя SOC — выделить сценарии предполагаемого автозакрытия и проверить их отдельно. Расширять полномочие следует по результатам разбора ошибок в этих сценариях. Хороший результат настройки и убедительное повторное объяснение не дают основания автоматически распространить разрешение на остальные оповещения.

Рекомендуемые статьи

Чем грозит открытая в интернет админка и как ограничить доступ к ней

Чем грозит открытая в интернет админка и как ограничить доступ к ней

Что может произойти при получении административных прав посторонним и как ограничить доступ к панели, сохранив возможность управлять системой.

Инженер с контрольным листом осматривает сервер, соединённый одним синим сетевым кабелем с клиентским компьютером.

Приложение работает. Что проверить перед запуском в продакшен

Как проверить доступ к пользовательским и служебным функциям, права приложения и ограничения рабочего окружения — и закрепить результат в процессе выпуска.

Лупа выделяет одинаковые синие маркеры на двух соединениях от ноутбуков к серверу; рядом зелёная галочка и янтарный треугольник.

Как обнаружить кражу сеанса, если сотрудник уже прошёл MFA

Украденный cookie может дать доступ к уже аутентифицированному сеансу. Разбираем, как связать события по Session ID в Microsoft Entra и Microsoft 365 и проверить контекст пользователя.

Сервер с предупреждением и прикреплённой карточкой: рядом со значками ответственного и связей рука добавляет плитку сетевого доступа.

Какие данные об активах собрать, прежде чем ранжировать уязвимости

Какие сведения об активе нужны для приоритизации уязвимостей: от установленного ПО и условий доступа до ответственного и ограничений обслуживания.

Графитовый технический стенд: разные геометрические объекты входят в прозрачную тестовую камеру, далее синие ветви сходятся в прозрачный контейнер с одним шаром.

Фаззинг без магии: как объяснить метод не-техническому руководителю

Фаззинг с управлением по покрытию ищет новые пути выполнения программы через изменённые входы. Для управленческого вывода важны границы охвата, качество тестовой обвязки, покрытие и разбор сбоев: число аварийных завершений само по себе не равно числу дефектов.

Серверный модуль в прозрачной камере на высокой платформе; слева резервная кассета и цепочка разъёмов, справа механический штамп над пустым диском и неподключённый штекер перед размытым сетевым контуром.

Когда нельзя возвращать сервис в работу после восстановления из резервной копии

Рамка решения для ИБ и ИТ: почему копии недостаточно и что согласовать перед возвратом сервиса в работу.

Тёмная минималистичная сцена: оранжевая сфера слева и синяя сфера справа разделены высокой прозрачной стеклянной панелью; к панели тянутся тонкие оранжевая и синяя световые линии.

Пять вопросов к совпадению CPE и CVE до приоритизации риска

Как проверить применимость совпадения CPE и CVE до приоритизации риска: отпечаток, версия, критерии, условия и подтверждённый результат.

Получите доступ к возможностям Сектора

Оставьте имя и номер — мы свяжемся с вами и покажем, как Сектор автоматизирует аудит безопасности