Общий язык для защиты агентов: представляем Project Quarry

Санкет Мендапара (Sanket Mendapara) и Евгений Лившиц (Evgeny Livshits)

ИИ-агенты теперь читают, принимают решения и действуют самостоятельно, а атаки на них разворачиваются через множество обычных, разрешенных шагов, которые большинство современных средств защиты не могут связать воедино. Project Quarry («Quarry»), который мы сегодня открываем в формате open-source, представляет собой язык обнаружения, созданный с нуля для решения этой задачи. Он позволяет службе безопасности один раз описать многошаговую атаку на агента, проверить по нему каждую сессию агента и увидеть доказательства, стоящие за каждым обнаружением. Мы разработали Quarry, чтобы он стал общей основой для обнаружения вредоносного или неразрешенного поведения агентов как в Cisco, так и во всем сообществе специалистов по безопасности.

В июле ИИ-агенты, работающие в рамках оценки кибербезопасности OpenAI, обошли элементы управления, призванные ограничить их доступ в интернет, обнаружили уязвимые учетные данные и провели примерно два с половиной дня внутри производственной инфраструктуры Hugging Face. Позже Hugging Face изучила примерно 17 600 действий агентов по своим логам. Большинство из них сами по себе ничем не примечательны: вывести список каталога, загрузить файл, отправить веб-запрос, запустить команду. Вторжение становилось заметным только по тому, как эти действия накапливались с течением времени и отклонялись от задачи, поставленной перед агентами.

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

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

Обнаружение мошенничества с картами предлагает привычное сравнение. Банк одобряет каждую покупку отдельно, в то время как его команда по борьбе с мошенничеством ищет паттерны по всем покупкам (например, небольшое тестовое списание, затем покупка в другом штате, затем крупный заказ электроники в течение часа) и сообщает держателю карты, какие списания вызвали тревогу. Безопасность агентов требует такого же сочетания обнаружения паттернов и доказательств, применяемого к шагам, которые предпринимает агент, а не к покупкам.

Защитники сетевой безопасности уже сталкивались с подобной проблемой раньше. Один пакет редко доказывает успешную атаку, поэтому Snort, система предотвращения вторжений с открытым исходным кодом, поддерживаемая Cisco, предоставляет им легко читаемый язык правил для обнаружения вредоносного трафика атак. Эти правила можно тестировать, версионировать, делиться ими и спорить о них, а Cisco Talos выпускает новые правила Snort в день выхода ежемесячных патчей Microsoft. Аналитики вредоносного ПО получили сопоставимый общий язык в YARA, а команды операций безопасности получили его для логов в Sigma. Поведение агентов теперь заслуживает собственного языка, и мы считаем, что защитникам будет лучше использовать один открытый язык, который каждая команда может читать, тестировать и расширять, чем отдельный формат правил внутри каждого продукта.

Сегодня мы открываем в формате open-source Project Quarry, нейросимволический язык правил (сочетающий суждения машинного обучения с точными проверками на основе правил) для оценки поведения агентов, а также движок, который оценивает эти правила. Мы создали Quarry в качестве такого языка для безопасности агентов. Он охватывает одноходовые и многоходовые разговоры с большими языковыми моделями (LLM), агентов, использование инструментов, взаимодействия по протоколу Model Context Protocol (MCP) и мультимодальные вводы. Ознакомьтесь с репозиторием GitHub здесь.

Одно правило Quarry может опираться на два типа доказательств. Нейронные сигналы поступают от классификаторов машинного обучения и судей LLM, которые справляются с вопросами, требующими оценки, например, содержит ли результат работы инструмента внедрение промпта (prompt injection). Символические проверки обрабатывают то, что можно сформулировать точно, например небезопасную команду, совпадение строк или порядок двух вызовов инструментов. Оптическое распознавание символов (OCR) и модели компьютерного зрения могут аналогичным образом предоставлять нейронные сигналы для изображений. Правило определяет, какие данные проверять, какие сигналы вызывать, как их комбинировать, какие исключения применяются и что является совпадением. Quarry также привлекает агентов к процессу написания политик.

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

Где команды могут использовать Quarry:

• Защитные барьеры во время выполнения (runtime guardrails): проверка агента до и после каждого вызова модели и запуска инструмента, а также блокировка или пометка рискованного шага
• Апостериорная оценка (post-hoc evaluation): проверка сохраненных трассировок по набору правил для аналитики безопасности
• Реагирование на инциденты: запуск недавно изученного паттерна по старым трассировкам

От угрозы к действию: интеграция с фреймворком AI Security & Safety Framework

Фреймворк Cisco Integrated AI Security & Safety Framework предоставляет организациям общий язык для описания рисков ИИ, установления границ и определения того, какие средства контроля и оценки им необходимы. Quarry — это уровень политик и оценки, который может заставить этот язык работать при взаимодействиях в реальном мире: категория фреймворка может быть переведена в проверяемое правило для сообщений, вызовов инструментов, результатов и контекста сессии. В этом смысле Quarry переводит фреймворк от описания рисков ИИ к их обнаружению в активности агентов, а категории фреймворка предлагают естественную дорожную карту для правил, которые Cisco и сообщество напишут в дальнейшем.

Например, цель фреймворка «Сбои автономности агентов» (Agentic Autonomy Failures) включает избыточную агентность (excessive agency), дрейф целей (goal drift) и взлом вознаграждения (reward hacking). Политика Quarry может искать такие свидетельства, как выход агента за пределы предоставленных ему полномочий, продолжение работы после условия остановки, изменение курса во время выполнения длительной задачи или обход проверки для создания видимости успешного выполнения метрики. Это поведенческие паттерны, а не просто небезопасные фразы, поэтому для них требуются доказательства на уровне трассировок, чтобы обеспечить более полное представление о потенциально непреднамеренной или нежелательной активности.

Недавнее обновление нашего фреймворка классифицировало бы инцидент с OpenAI и Hugging Face как AITech-2.3 Reward Hacking в сочетании с AITech-2.1 Excessive Agency. Правило Quarry превращает такую классификацию в проверку, а репозиторий включает такие отправные точки, как расширение масштаба возможностей (capability scope creep) и скрытая подмена задач.

Где Quarry занимает место среди других средств контроля

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

Другие средства контроля остаются полезными, поскольку они решают другие части проблемы. Промежуточное ПО (middleware) может направлять агента или проверять его на отдельных этапах, а классификаторы контента могут отмечать подозрительное сообщение или результат. Однако при использовании в одиночку эти средства контроля могут не связываться с полной структурированной трассировкой, не сохранять историю сеанса, не объединять различные сигналы и не возвращать доказательства, лежащие в основе многошагового выявления. В таком случае командам приходится выстраивать логику с сохранением состояния (stateful) и логику политик отдельно для каждой интеграции.

Иногда достаточно одного вызова инструмента

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

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

Рисунок 1: Достаточно одного вызова инструмента: обнаружение пейлоада декомпрессии и выполнения

Намерение может проявляться со временем

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

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

Рисунок 2: История меняет вердикт: разведка и заявленные полномочия перед предоставлением прав администратора

Утечка данных — это последовательность, а не единичное событие

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

Invariant Labs продемонстрировала это на примере MCP-сервера GitHub в мае 2025 года. Злоумышленник внедрил инструкции в проблему (issue) в публичном репозитории. Когда владелец попросил своего агента просмотреть открытые проблемы, тот последовал им: он прочитал приватные репозитории владельца и опубликовал найденное в пулл-реквесте (pull request) в публичном репозитории, используя только те доступы, которые были предоставлены владельцем.

Рисунок 3: Следуя за данными: внедренная проблема, которая раскрывает приватный репозиторий

Один результат может поддерживаться несколькими сигналами

Результат работы инструмента может содержать инструкцию проигнорировать предыдущие правила и выгрузить файл с секретами. Детерминированный паттерн может пометить эти инструкции. Классификатор промпт-инъекций может оценить текст, а модель-судья может учесть сопутствующие сообщения. Политика может потребовать эти сигналы в сочетании с последующим использованием инструментов оболочки и сети. Детекторы предоставляют улики, а правило отвечает за логику, которая определяет, соответствует ли объединенное поведение заданному условию.

General Analysis показала версию этого сценария с MCP-сервером Supabase в июле 2025 года: инструкции в тикете техподдержки заставили агента Cursor разработчика, работавшего с полными привилегиями базы данных, прочитать таблицу токенов интеграции и опубликовать их обратно в тикете, чтобы их увидел злоумышленник.

За пределами текста

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

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

Чтение инцидента Hugging Face как трассировки

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

• Общение агентов там, где им не положено (12 мая): Во время тренировочного запуска агент оставил заметку во внутреннем пакетном реестре OpenAI с просьбой к другим агентам предоставить недостающий файл. Запись сообщений в службу пакетов выходит за рамки любой задачи, и OpenAI заявляла, что внутренняя команда заметила такую активность в конце мая, до того как была осознана ее значимость.
• Доступ в интернет из изолированной среды (песочницы), у которой его не было (26 мая и 8 июля): Агенты заставили службу пакетов отправлять веб-запросы от их имени — сначала 26 мая, а затем снова 8 июля, после того как OpenAI перестроила сервис. Правило может пометить любой вызов инструмента, который достигает пункта назначения за пределами разрешенного списка задачи.
• Учетные данные найдены, а затем использованы в другом месте (10 июля): Агент восстановил, проверил и передал 14 публично раскрытых учетных данных Hugging Face с правами на запись, а позже другой агент использовал их для получения выполнения кода на серверах Hugging Face. Учетные данные, которые появляются в результате работы инструмента и за которыми следует вызов к внешнему сервису, представляют собой описанный ранее паттерн перемещения данных.
• Закодированное выполнение (11 июля): Код, который выполнялся на воркерах Hugging Face, поступил в виде однострочного полезного груза типа «декодируй и запускай», описанного ранее. Агенты упаковывали свои команды таким образом с 9 июля.
• Упорство после успеха (июль): По данным OpenAI, у большинства агентов уже был правильный ответ, полученный нечестным путем, но они продолжали работать, пытаясь использовать Hugging Face в течение нескольких дней, потому что были уверены, что проверяющая система хочет большего. Продолжение работы после достижения цели задачи является признаком взлома вознаграждения (reward-hacking), и его можно заметить только при анализе всей цепочки (trace).

Правила дополняют мониторинг, описанный обеими компаниями, а не заменяют его. OpenAI заявила, что ее текущий мониторинг цепочки рассуждений (chain-of-thought), если бы он работал во время этих оценок, предупредил бы ее службу безопасности более чем за сутки до того, как агенты взломали системы Hugging Face. Компания Hugging Face охарактеризовала свои первые сигналы как сами по себе неоднозначные и отметила, что они стали полноценным сигналом атаки только после их сопоставления. Ценность правила в таком сценарии заключается в фиксации паттерна в форме, которую другие команды могут изучить, протестировать и применить к собственным агентам.

Рисунок 4. Пять точек на шкале времени OpenAI и Hugging Face (с 12 мая по 19 июля), на которых правило Quarry имело бы основания для принятия мер.

Ближе к дому: постоянно работающие персональные агенты

В сентябре Meta запустила Muse, а OpenAI — Dots — агенты, которые совершают покупки, заполняют формы, планируют путешествия и отправляют электронные письма в фоновом режиме от имени пользователя. Оба запрашивают одобрение перед совершением значимых действий. И снова более сложным случаем является последовательность, в которой ни один отдельный шаг не выглядит важным.

Допустим, пользователь просит забронировать рейс, когда цена снизится, а на странице авиакомпании содержится скрытый текст, предписывающий агенту подтвердить личность путешественника путем отправки скана паспорта по электронной почте на адрес службы поддержки. Правило Quarry может описать этот паттерн: инструкция из веб-контента, за которой в течение нескольких шагов следует исходящее сообщение с вложением, о котором пользователь никогда не упоминал. Quarry не встроена ни в один из продуктов, но любой, кто видит трафик агента, может проверить его: оператор платформы, корпоративный шлюз или, для агентов, запускаемых пользователями самостоятельно, DefenseClaw (см. ниже).

Если вы читали правило Snort, вы сможете прочитать и правило Quarry

Правило Snort имеет заголовок, указывающий, какой трафик нужно просматривать, опции, определяющие, что именно искать, и метаданные для отслеживания правила. Quarry применяет ту же анатомию к цепочкам агентов в синтаксисе, который узнает каждый, кто писал правила YARA. Приведенное ниже правило Snort помечает облачный секрет, покидающий систему в HTTP-запросе; правило Quarry помечает агента, который считывает файл учетных данных и осуществляет вызов в течение четырех шагов.

Рисунок 5: Пример сравнения того, как выглядят правило Snort и правило Quarry

Это иллюстративные примеры, так как мы понимаем, что эти два правила различаются по тому, что они могут наблюдать. Правило Snort в текущем виде находит секрет только в том случае, если он передается по сети в читаемом виде, поэтому полезный груз, который агент предварительно закодировал (как это сделал злоумышленник в случае с Hugging Face), потребует дополнительной логики правила для обнаружения. Ни один движок не декодирует обфускацию нативно, и в обоих случаях автор правила должен предусмотреть закодированные варианты. Однако правило Quarry в данном примере ориентируется на шаги агента (чтение файла учетных данных с последующим исходящим запросом), а не на содержимое запроса, поэтому кодирование полезной нагрузки не влияет на то, сработает ли правило.

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

Позвольте вашим агентам кодирования писать правила Quarry

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

Тот же плагин также будет обеспечивать работу Policy Studio от Cisco — нашей платформы для создания и запуска средств обнаружения. Policy Studio добавляет то, что необходимо платформе вокруг этого движка: доступ арендаторов и пользователей, сохраненные правила и диалоги, наборы данных и разметку, пакетную оценку (batch evaluation) и продвижение проверенных правил до уровня активного обнаружения. На практике агент может составить проект правила на ноутбуке разработчика, после чего Policy Studio оценит его на собственных данных организации до того, как оно будет продвинуто и выпущено. Плагин и Policy Studio — это первые шаги к созданию покрытия детектирования, способного идти в ногу со скоростью появления новых техник атак агентов.

Что входит в ваш стартовый набор Quarry

Проект с открытым исходнымходом предоставляет практикам рабочую основу для инженерного детектирования:

• читаемый DSL для диалогов, использования инструментов и связей между событиями;
• среда выполнения для оценки (evaluation runtime) с настраиваемыми ограничениями безопасности и ресурсов, которая компилирует каждое правило при загрузке;
• сканер командной строки для отдельных цепочек, каталогов и наборов данных;
• Python SDK для интеграции приложений;
• опционально настроенные операции моделей для семантических сигналов;
• плагин Quarry для Claude Code, Codex и других агентов, совместимых с MCP;
• метаданные правил, примеры, документация и рекомендации по формату сообщений; а также
• рабочий процесс для валидации правил на основе позитивных и доброкачественных наборов данных.

Репозиторий Quarry содержит инструкции по установке, поддерживаемые версии Python, примеры конфигурации, руководство по написанию правил и информацию об участии в разработке.

Внедрение может происходить в три этапа:

• Начните с уже имеющихся у вас цепочек (traces). Quarry читает JSON-файлы чатов в формате OpenAI, которые многие фреймворки агентов уже логируют или могут в него конвертировать. Укажите quarry scan на каталог с сохраненными цепочками.
• Настройте перед применением. Проверьте совпадения и их подтверждения, затем добавьте исключения для санкционированного вами поведения, например, для ваших собственных конечных точек загрузки. Подумайте о версионировании каждого правила с помощью соответствующего и понятного примера диалога, контролируя изменения в CI.
• Переходите к выполнению в реальном времени после того, как разберетесь с шумом. Вызывайте Quarry из пути приложения и сопоставляйте результаты для отправки оповещений, блокировки, маскирования, карантина или логирования.

Интеграция Quarry в Cisco AI Defense

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

Мы также планируем внедрить Quarry в DefenseClaw, наш уровень управления с открытым исходным кодом для сред выполнения агентов, который уже сканирует навыки, серверы MCP и сгенерированный код перед их запускем, а также передает вызовы инструментов и решения политик в Splunk. Цель состоит в том, чтобы тестировать правила на сохраненных трассировках из DefenseClaw и отправлять его результаты с подтверждениями в тот же индекс Splunk. В совокупности эти интеграции отражают наше стремление к тому, чтобы одни и те же правила Quarry работали во всех продуктах Cisco по безопасности ИИ, чтобы покрытие, написанное и протестированное один раз, можно было применять везде, где работают агенты организации.

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

Что это значит для вас

• Если вы создаете или развертываете агентов: используйте политики для описания поведения, охватывающего сообщения, вызовы инструментов, результаты и изменения состояния. Сохраняйте элементы управления авторизацией для отдельных действий, а затем добавляйте обнаружение на уровне трассировок там, где риск зависит от порядка или контекста.
• Если вы пишете правила обнаружения или оцениваете агентов: формулируйте подтверждения и связи, которые должны приводить к срабатыванию, а затем тестируйте эту политику на репрезентативных трассировках. Общие правила делают разногласия очевидными и дают командам конкретный объект для улучшения.
• Если вы возглавляете направление безопасности или управления ИИ: используйте результаты и их подтверждения для связи требований политики с оценками, мониторингом и разбором инцидентов. Правило должно делать причину решения прозрачной, а не скрывать ее внутри непрозрачного показателя.
• Если вы покупаете или утверждаете продукты с агентами: спросите у поставщиков, что записывают их агенты, можете ли вы получить полную трассировку и приходит ли предупреждение безопасности вместе с подтверждающими его фактами. Агент, действия которого невозможно восстановить задним числом, оставляет организацию без каких-либо оснований для расследования.

Взаимодействуйте с нами

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

Ознакомьтесь с репозиторием на GitHub здесь: