Основные выводы
- Varonis Triage Agent расследует оповещения подобно специалисту по реагированию на инциденты, формируя гипотезы, собирая доказательства и проверяя доброкачественные объяснения.
- В одном из случаев агент объединил три отдельных оповещения в единый инцидент, охватывающий более 17 000 загрузок файлов, которые пропустили обычные правила.
- В промышленной эксплуатации агент повысил эффективность аналитиков, сохраняя при этом полноту обнаружения на уровне выше 96% для подтвержденных угроз.
Каждый инцидент безопасности начинается как история: подозрительный вход в систему, доступ пользователя к конфиденциальным данным или слабый сигнал, скрытый среди тысяч шумных оповещений. В современном центре управления безопасностью (SOC) эта история скрыта в масштабах, которые кажутся невозможными, учитывая десятки тысяч оповещений, обрабатываемых командой. Как только злоумышленник получает точку опоры, каждая минута имеет значение, поскольку он может перемещаться по сети, расширять доступ и увеличивать радиус поражения до того, как аналитик приступит к делу.
Это давление стимулирует развитие систем AI SOC, предназначенных для выполнения значимой исследовательской работы до того, как аналитик откроет кейс. Именно эта задача направляет работу Triage Agent: автономного ИИ-агента, созданного Varonis для комплексного расследования оповещений, выявления наиболее важных случаев и предоставления аналитикам контекста, необходимого для быстрого реагирования.
Для Varonis триаж — это понимание данных через контекст: к какой конфиденциальной информации был получен доступ, кем, был ли этот доступ правомерным и является ли активность нормальной рабочей деятельностью, злоупотреблением со стороны инсайдера или вредоносной эксфильтрацией. Эта важнейшая информация превращает оповещение в решение по безопасности, готовое к исполнению.
Почему мы создали Varonis Triage Agent
Традиционный триаж опирается на правила, жестко запрограммированную автоматизацию и традиционные системы машинного обучения, которые являются важным фундаментом. Но агент может пойти дальше, выбирая, какие доказательства собрать следующими, адаптируясь по мере появления новых фактов и связывая разрозненные находки в более широкий инцидент.
Наша задача заключалась не просто в том, чтобы быстрее ранжировать оповещения, а в том, чтобы агент расследовал их с контекстом и адаптивностью опытного специалиста по реагированию.
Преимущество контекста Varonis
Агент полезен лишь настолько, насколько полезен контекст, на основе которого он рассуждает. В безопасности контекст определяет смысл. Одно и то же действие может представлять собой нормальную работу, неосторожное поведение или активную атаку в зависимости от нескольких факторов, таких как вовлеченная учетная запись, конфиденциальность данных, права доступа пользователя, его историческое поведение и окружающая активность.
У Varonis уже был этот контекст в рамках платформы Data Security Platform (DSP). Агент мог исследовать учетные записи, права доступа, полномочия, поведенческие паттерны, подверженность конфиденциальных данных риску и связанные события, вместо того чтобы рассуждать над изолированным оповещением. У нас также был большой репозиторий доказательств прошлых инцидентов, который предлагал реальные результаты, на основе которых можно было оценивать работу агента.
Другими словами, мы не обучали систему только на абстрактной теории безопасности. Мы могли сравнивать ее оценки с годами реальных расследований, выявлять, где ее логика давала сбой, и использовать эти ошибки для улучшения. Но богатых данных о безопасности было недостаточно. Прежде чем агент мог их исследовать, эти данные должны были стать согласованными и доступными для запросов.
Как агент проводит расследование
Большая часть работы заключалась в нормализации событий из платформ для совместной работы, электронной почты, служб идентификации, сетей и VPN в единую схему. Это позволило агенту рассуждать, например, о том, что «конфиденциальный файл был передан вовне», не зная, какая именно система отправила этот сигнал.
Агент также имеет доступ к поведенческим базовым линиям, включая предварительно вычисленные сводки того, как пользователь обычно себя ведет и какие направления и объемы данных ожидаемы. Это позволяет ему задать вопрос: «Нормально ли это для данного пользователя?», не перестраивая базовую линию для каждого оповещения. Курируемый каталог объясняет, что содержит каждая таблица и как делать к ней запросы.
Обработка бесконечного контекста
Varonis обладает огромным количеством полезного контекста, но полезный — не значит релевантный. Загрузка всего доступного контекста в агента для каждого оповещения делает систему медленнее, дороже и менее точной, потому что важные сигналы теряются.
Чтобы решить эту проблему, мы организовали расследования по сценариям: эксфильтрация данных, повышение привилегий, фишинг и атаки на учетные записи. Каждый сценарий определяет источники, поведение и таблицы, которые наиболее важны, поэтому агент начинает с релевантного контекста и расширяет его только тогда, когда этого требуют доказательства.
Этот динамический подход позволил нам сопоставить контекст для более чем 300 сценариев без написания индивидуальных инструкций для каждого из них. Считайте сценарии расследования способом обеспечения сфокусированной отправной точки, не превращая расследование в жесткий скрипт.
Формирование мышления специалиста по реагированию
Как только у нас появились данные, следующей задачей стало обучение агента тому, как проводить расследование. Ответить на вопрос — это одна проблема. Проработать открытый кейс по безопасности — совсем другая.
Хороший специалист по реагированию формирует первоначальную гипотезу, собирает доказательства, ищет противоречия и меняет направление, когда факты не сходятся. Каждая находка влияет на следующий шаг. Это стало нашей целью проектирования: не просто объяснитель оповещений, а агент, который следует процессу рассуждения опытного специалиста по реагированию.
Центральное противоречие, которое мы обнаружили, заключалось в выборе между структурой и гибкостью. Слишком мало руководств приводило к поверхностным расследованиям, а слишком много создавало тот же жесткий план действий, который мы пытались преодолеть. Агенту нужно было собрать достаточно доказательств, рассмотреть альтернативные объяснения, избегать трактовки каждой аномалии как вредоносной и распознавать, когда успокаивающего контекста недостаточно, чтобы отбросить реальную угрозу.
Создание этого потребовало тесного сотрудничества между исследователями безопасности, которые внесли вклад в методологию расследования и мышление злоумышленников, и специалистами по данным, которые создали инфраструктуру оркестрации и вызова инструментов. Мы сравнивали ранние версии с реальными результатами нашей команды MDDR, оценивая как вердикт, так и то, собрало ли расследование достаточно доказательств для его обоснования. Эти неудачи стали дорожной картой.
Как мы улучшили агента
Каждый запуск отслеживался как пошаговая транскрипция. Используя размеченные результаты, мы могли тестировать агента на случаях, где ответ был уже известен. Неверные вердикты были особенно полезны, так как трассировка показывала, где логика сбилась с пути.
Исправления редко требовали изменения модели. Они требовали изменения того, что знал агент и как он направлялся: уточнение руководств по расследованию, улучшение описания таблицы или ужесточение промпта, чтобы агент не делал поспешных выводов слишком рано.
Самым сложным было проявить сдержанность. Каждая ошибка провоцировала добавление новой инструкции, но слишком большое количество инструкций ограничивало агента до тех пор, пока он не мог следовать только по заранее определенному пути.
Главный вывод: хорошая подсказка направляет расследование, но не задает его жесткий сценарий. Например, агент неоднократно помечал загрузку файлов как подозрительную, не проверяя, принадлежат ли файлы пользователю. Жесткое правило вроде «доступ к собственным файлам безопасен» создало бы слепую зону, если бы владелец поделился конфиденциальными файлами с внешними лицами. Вместо этого мы добавили одну подсказку: «Прежде чем считать файловую активность подозрительной, установите взаимосвязь между пользователем и ресурсом».
Агент начал регулярно проверять принадлежность файлов, отбрасывая безобидный доступ к собственным данным и при этом эскалируя реальные угрозы на основе доказательств.
Еще один полезный метод заключался в сравнении двух запусков на одном и том же алерте: один был корректным, а другой — нет. Разница часто сводилась к одному действию: во время одного запуска проверялся источник подозрительного всплеска, в то время как во втором он принимался на веру без проверки. Эта развилка показала нам именно то, что нужно было усилить.
Настоящее расследование от начала и до конца
Все началось с алерта, который мало кто из аналитиков поспешил бы открыть: сотрудник отдела продаж за короткий промежуток времени скачал тысячи файлов с конфиденциальными данными с неизвестного внешнего IP-адреса. Массовые загрузки могут сопровождать миграцию, создание резервных копий и квартальную отчетность, и этот тип обнаружения входит в число самых частых и «шумных» на платформе. На основе правил и традиционного машинного обучения оценка алерта оказалась ниже порогового значения высокого приоритета. В очереди из десятков тысяч элементов он бы просто ждал своего часа.
Агент не стал рассматривать количество загрузок как окончательный вердикт. Он сам выбирал, какие доказательства изучить, проверял гипотезы о добросо характера активности и менял направление по мере появления новых фактов. Он начал с установления личности: это известный сотрудник нетехнического отдела продаж, а не администратор или служебная учетная запись. Само по себе это ничего не доказывало, но делало программный сбор тысяч финансовых документов труднообъяснимым в рамках рутинной работы.
Необработанные события показали, что загрузки выполнялись клиентом Node.js, а не браузером или управляемым рабочим приложением, что указывало на скриптовый сбор. Файлы охватывали тысячи папок и расположений, которые пользователю не принадлежали, и многие из них имели гриф «конфиденциально» или «совершенно секретно». Вопрос сменился с «Был ли всплеск?» на «Почему сотрудник отдела продаж с помощью скрипта собирает конфиденциальные финансовые материалы, которые ему не принадлежат?»
30-дневная база сравнения сделала контраст еще более резким. До этого дня пиковая активность пользователя составляла всего несколько файлов. Сетевая аналитика определила источник как анонимную конечную точку потребительского VPN, размещенную в инфраструктуре дата-центра. Ни один другой пользователь в этой среде не обращался к ней в течение указанного окна, что исключило общий корпоративный выход в сеть и связало скрытое происхождение именно с этой учетной записью.
Ни один отдельный факт не решал исход дела сам по себе. Большой объем может быть легитимной работой. Новый IP-адрес может указывать на путешествие. Скриптовый клиент может быть санкционированной автоматизацией. Важна именно комбинация факторов, которая позволила агенту сделать вывод: «Сочетание автоматизированного сбора, сокрытия происхождения и нацеливания на крайне конфиденциальные финансовые данные представляет собой конкретное доказательство массовой эксфильтрации данных».
Агент классифицировал активность как вредоносную и критическую, одновременно зафиксировав свое ограничение: телеметрия аутентификации была недоступна, поэтому он не мог различить украденные учетные данные, перехваченный сеанс или намеренные действия инсайдера.
От изолированных алертов к связанным инцидентам
Самый важный шаг заключался в том, чтобы выйти за рамки выданного ему тикета. Агент проанализировал данные за 14 дней по той же учетной записи на предмет невозможности перемещения (impossible travel), внешнего шеринга и выгрузки в персональное облачное хранилище. Ничего из этого обнаружено не было. Зато появились еще два алерта по тому же правилу загрузки за тот же день: более ранний всплеск примерно из 440 файлов и более поздний — из более чем 11 500.
В совокупности за три временных окна было загружено более 17 000 файлов. Умеренный всплеск ниже порогового приоритета оказался лишь одной из фаз непрерывного извлечения данных, нарастающего в течение дня.
Агент не просто сгруппировал алерты по пользователю. Он проверил связанные варианты атакующего поведения, отделил отсутствие сигналов от противоречивых доказательств и объединил соответствующую активность в единую шкалу времени. Именно это адаптивное расследование и реконструкция инцидента, а не какой-то отдельный индикатор, составили агентское преимущество.
Аналитик MDDR открыл дело, когда все эти доказательства уже были собраны, подтвердил объем и источник в виде потребительского VPN, после чего эскалировал инцидент для принятия мер клиентом.
Окончательное решение оставалось за человеком, но вместо трех несвязанных тикетов он получил один реконструированный инцидент.
Что потребовалось для создания полезного агента
Это никогда не было просто проектом по созданию модели или промптингу. Модель, оркестрация, инструменты и фундамент данных — все это имело значение. Но система стала полезной только тогда, когда эти элементы были подкреплены методологиями расследования опытных исследователей безопасности и протестированы на реальных результатах.
Исследователи безопасности выделили вопросы и взаимосвязи, которые человеческий следователь проверяет на уровне рефлексов. Дата-саентисты перевели эти уроки в инструменты, контекст, руководства и повторяемые рабочие процессы оценки. Непрерывный цикл между этими дисциплинами — запуск, проверка, корректировка и измерение — двигал агента вперед.
Результатом стал Varonis Triage Agent, продукт в новой категории ИИ-SOC, который делает гораздо больше, чем просто ускоряет обработку алертов. Он начинает расследование раньше, связывает доказательства по всей среде и дает аналитикам надежную отправную точку вместо чистого листа.
В продакшене агент повысил эффективность аналитиков на 35–100% в зависимости от базовых показателей каждого специалиста и опыта работы с ним. Переход от триажа на основе машинного обучения и плейбуков к агентскому триажу сократил время, необходимое для эскалации вредоносных инцидентов, в среднем на 16,4 часа на одну эскалацию.
Полнота обнаружения (recall) в продакшене превышает 96%. Поскольку аналитики Varonis MDDR вручную проверяют каждый след, менее 4% подтвержденных атак не были приоритизированы агентом. Агент уже расследовал десятки производственных алертов, и это число продолжает расти.
Точный агент, ориентированный на триаж, также меняет подход к проектированию детектирования (detection engineering). Когда каждое новое обнаружение добавляет работы в и без того перегруженную очередь, команды часто сужают правила, чтобы не засыпать аналитиков ложными срабатываниями, жертвуя при этом охватом. С надежным агентом, берущим на себя дополнительный объем работы, инженеры по детектированию могут писать более широкие и чувствительные правила, в то время как агент фильтрует шум и выводит на поверхность случаи, заслуживающие внимания.
В конечном счете цель состоит не в том, чтобы заменить человеческое суждение. Цель в том, чтобы избавить аналитиков от ручного сбора контекста и переключить их внимание на анализ доказательств, принятие важных решений и локализацию угроз до того, как ущерб распространится дальше.
Эта статья написана в соавторстве с Хадас Шалев (Hadas Shalev). Спасибо Орену Тевету (Oren Tevet), Йонатану Халдарову (Yonatan Haldarov) и Амиту Даниэлю (Amit Daniel) за их вклад в эту тему.
