Обучение машины мышлению специалиста по реагированию на инциденты

Основные выводы

• Агент триажа Varonis расследует оповещения подобно специалисту по реагированию на инциденты: выдвигает гипотезы, собирает доказательства и проверяет безобидные объяснения.
• В одном из случаев агент объединил три отдельных оповещения в единый инцидент, охватывающий более 17 000 загрузок файлов, который правила сами по себе пропустили.
• В рабочей среде агент повысил эффективность аналитиков, сохранив при этом показатель полноты (recall) на уровне выше 96% по подтвержденным угрозам.

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

Это давление стимулирует рост систем SOC на базе ИИ, предназначенных для выполнения значимой исследовательской работы до того, как аналитик-человек откроет дело. И именно эта задача стала ориентиром для агента триажа (Triage Agent): автономного ИИ-агента, созданного Varonis для комплексного расследования оповещений, выявления наиболее важных инцидентов и предоставления аналитикам контекста, необходимого для быстрых действий.

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

Почему мы создали Varonis Triage Agent

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

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

Контекстное преимущество Varonis

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

У Varonis уже был такой контекст в рамках платформы Data Security Platform (DSP). Агент мог исследовать учетные записи, разрешения, права доступа, поведенческие паттерны, утечки конфиденциальных данных и связанные события вместо того, чтобы рассуждать над изолированным оповещением. У нас также был большой репозиторий доказательств прошлых инцидентов, который предоставлял реальные результаты для оценки работы агента.

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

Как агент проводит расследование

Большая часть работы заключалась в нормализации событий из платформ для совместной работы, электронной почты, служб идентификации, сетей и VPN в единую схему. Это позволило агенту рассуждать, например, о том, что «конфиденциальный файл был предоставлен внешним пользователям», не зная, какая именно система выдала этот сигнал.

Агент также имеет доступ к базовым показателям поведения, включая предварительно вычисленные сводки о том, как пользователь обычно себя ведет и какие направления и объемы трафика ожидаемы. Это позволяет ему задавать вопрос: «Нормально ли это для данного пользователя?», не перестраивая базовый уровень для каждого оповещения. Специально подготовленный каталог объясняет, что содержит каждая таблица и как делать к ней запросы.

Обработка бесконечного контекста

У Varonis есть огромное количество полезного контекста, но полезный не означает релевантный. Загрузка всего доступного контекста в агента для каждого оповещения делает систему более медленной, дорогой и менее точной, поскольку важные сигналы оказываются погребенными под лишней информацией.

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

Этот динамический подход позволил нам сопоставить контекст для более чем 300 сценариев без написания индивидуальных инструкций для каждого из них. Сценарии расследования можно рассматривать как инструмент, обеспечивающий сфокусированную отправную точку, не превращая при этом расследование в жесткий сценарий по шагам.

Формирование мышления специалиста по реагированию на инциденты

Как только у нас появились данные, следующей задачей было научить агента проводить расследование. Ответить на вопрос — это одна проблема. Работать с открытым делом безопасности — совсем другая.

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

Главное противоречие, с которым мы столкнулись, — это баланс между структурой и гибкостью. Слишком малое руководство приводило к поверхностным расследованиям, в то время как слишком большое создавало те же жесткие алгоритмы, которые мы пытались преодолеть. Агенту нужно было собирать достаточно доказательств, рассматривать альтернативные объяснения, избегать восприятия каждой аномалии как вредоносной и распознавать, когда обнадеживающего контекста недостаточно для отброса реальной угрозы.

Создание этого потребовало тесного сотрудничества между исследователями безопасности, которые внесли свой вклад в методологию расследований и мышление злоумышленников, и специалистами по работе с данными (data scientists), которые создали инфраструктуру оркестрации и вызова инструментов. Мы провели бенчмаркинг ранних версий по сравнению с реальными результатами нашей команды MDDR, оценивая как вердикт, так и то, собрало ли расследование достаточно доказательств для его обоснования. Эти неудачи стали нашей дорожной картой (роадмапом).

Как мы улучшили агента

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

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

Самым сложным было проявить сдержанность. Каждая ошибка напрашивалась на добавление еще одной инструкции, но слишком большое количество инструкций сужало возможности агента до тех пор, пока он не начинал следовать только по заранее определенному пути.

Вывод: хороший совет подталкивает расследование, а не задает жесткий сценарий. Например, агент неоднократно помечал загрузки файлов как подозрительные, не проверяя, принадлежат ли файлы пользователю. Жесткое правило вроде «доступ к собственным файлам безопасен» создало бы «слепую зону», когда владелец поделился конфиденциальными файлами с внешними лицами. Вместо этого мы добавили одну подсказку: «Прежде чем расценивать файловую активность как подозрительную, установите связь между пользователем и ресурсом».

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

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

Настоящее расследование от начала и до конца

Все началось с оповещения, которое мало кто из аналитиков стал бы спешить открывать: сотрудник отдела продаж за короткий промежуток времени скачал тысячи файлов с конфиденциальными данными с незнакомого внешнего IP-адреса. Массовые загрузки могут сопровождать миграцию, создание резервных копий и квартальную отчетность, и такое детектирование относится к числу наиболее частых и «шумных» на платформе. Оценки на основе правил и традиционного машинного обучения поместили это оповещение ниже порога высокого приоритета. В очереди из десятков тысяч оно бы просто ждало своей очереди.

Агент не стал рассматривать количество загрузок как окончательный вердикт. Он сам выбирал, какие доказательства изучить, проверял гипотезы о доброкачественной активности и менял направление по мере появления новых фактов. Все началось с личности: известный сотрудник коммерческого отдела, а не администратор или сервисная учетная запись. Сама по себе эта информация ничего не доказывала, но она делала программный сбор тысяч финансовых документов труднообъяснимым с точки зрения рутинной работы.

Необработанные события показали, что загрузки производились из клиента Node.js, а не из браузера или управляемого рабочего приложения, что указывает на скриптовый сбор. Файлы охватывали тысячи расположений, которыми пользователь не владел, и многие из них имели грифы «конфиденциально» или «совершенно секретно». Вопрос изменился с «Был ли всплеск?» на «Почему сотрудник отдела продаж с помощью скрипта собирает конфиденциальные финансовые материалы, которые ему не принадлежат?».

30-дневный базовый профиль еще сильнее подчеркнул контраст. До этого дня пиковая активность пользователя составляла всего несколько файлов. Сетевая аналитика определила источник как анонимную конечную точку потребительского VPN, размещенную в инфраструктуре дата-центра. Ни один другой пользователь в этой среде не обращался к ней в течение указанного периода, что исключает совместное использование корпоративного выхода в сеть и связывает скрытое происхождение именно с этой учетной записью.

Ни один отдельный факт не решал исход дела. Большой объем данных может быть легитимной работой. Новый IP-адрес может указывать на путешествие. Клиент со скриптом может быть санкционированной автоматизацией. Важна именно комбинация факторов, которая позволила агенту прийти к выводу: «Сочетание автоматизированного сбора, сокрытия происхождения и нацеливания на крайне конфиденциальные финансовые данные предоставляет конкретные доказательства массовой эксфильтрации данных».

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

От изолированных оповещений к связанным инцидентам

Самый значимый шаг заключался в том, чтобы выйти за рамки выданного ему тикета. Агент проанализировал данные за 14 дней по той же учетной записи на предмет невозможности путешествий, внешнего общего доступа и выгрузок в личное облачное хранилище. Ничего подобного обнаружено не было. Зато появились еще два оповещения по тому же правилу загрузки за тот же день: более ранний всплеск примерно из 440 файлов и более поздний — из более чем 11 500.

В совокупности за три временных окна было зафиксировано более 17 000 загрузок. Умеренный всплеск ниже порога приоритета оказался лишь одной из фаз непрерывного извлечения данных, нарастающего в течение дня.

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

Аналитик MDDR открыл дело, когда все эти доказательства уже были собраны, подтвердил объем и источник в виде потребительского VPN, а также передал инцидент на уровень выше для принятия мер клиентом. Окончательным вердиктом стало истинно-положительное срабатывание на внешнюю вредоносную угрозу.

Решение по-прежнему принимал человек, но вместо трех несвязанных тикетов он получил один реконструированный инцидент.

Что потребовалось, чтобы сделать агента полезным

Это никогда не было просто проектом по созданию модели или написанию промптов. Важное значение имели и сама модель, и оркестрация, и инструменты, и база данных. Но система стала полезной лишь тогда, когда все эти элементы были основаны на методологии расследований опытных исследователей безопасности и проверены на реальных результатах.

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

Результатом стал Varonis Triage Agent, продукт в новой категории ИИ-SOC, который делает гораздо больше, чем просто быстрее обрабатывает оповещения. Он начинает расследование раньше, связывает улики по всей инфраструктуре и дает аналитикам обоснованную отправную точку вместо чистого листа.

В рабочей среде агент повысил эффективность работы аналитиков на 35–100% в зависимости от исходного уровня и опыта работы с ним. Переход от триажа на основе машинного обучения и плейбуков к триажу на базе агентов сократил время, необходимое для эскалации вредоносных инцидентов, в среднем на 16,4 часа на одну эскалацию.

Полнота охвата в рабочей среде превышает 96%. Поскольку аналитики Varonis MDDR вручную проверяют каждый след, менее 4% подтвержденных атак не получили приоритета со стороны агента. Агент уже расследовал десятки производственных оповещений, и это число продолжает расти.

Точный агент, ориентированный на триаж, также меняет подход к проектированию правил обнаружения (detection engineering). Когда каждое новое детектирование добавляет нагрузку в перегруженную очередь, команды часто делают правила узкими, чтобы избежать засилья ложных срабатываний у аналитиков, что ведет к ухудшению покрытия. Когда надежный агент берет на себя дополнительный объем работы, инженеры по обнаружению могут писать более широкие и чувствительные правила, в то время как агент фильтрует шум и выводит на передний план случаи, заслуживающие внимания.

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

Автором этой публикации в соавторстве выступила Хадас Шалев (Hadas Shalev). Спасибо Орену Тэвету (Oren Tevet), Йонатану Халдарову (Yonatan Haldarov) и Амиту Даниэлю (Amit Daniel) за их вклад в эту тему.