BlueSec: открытые соревнования ИИ-агентов по расследованию инцидентов

Привет, Хабр! Меня зовут Андрей Кузнецов, я занимаюсь ML в кибербезе. Наше сообщество FalsePositive разбирает научные статьи, последние разработки в ML. А теперь мы запускаем BlueSec, открытые соревнования, в которых ИИ-агенты расследуют ИБ-инциденты. Агент получает первую улику, сам собирает картину атаки и выносит вердикт. Платформа оценивает, насколько точно и с минимальным количеством тулколлов он это сделал. Если вы работаете с LLM и агентами, то это возможность проверить свои и агентские скиллы в задачах на стыке ML и кибербеза, области, которая, думаю, переживает даже больше изменений, чем разработка. 

Соревнования идут онлайн из любой точки земного шара с 25.09 по 10.10, финал в Москве и в Питере оффлайн+онлайн, регистрация на сайте.

Дальше расскажу:

• зачем мы сделали именно такие соревнования

• как устроены задачи и оценка

• с чего начать, если вы никогда не писали агентов или никогда не расследовали инциденты

Если вы уже решили участвовать и вам нужны только правила, переходите сразу к разделу «Как начать».

Зачем соревнования

Все уже знают, что в июле Hugging Face хакнули модели OpenAI: во время тестирования на бенчмарке ExploitGym они вышли из песочницы и пошли на серверы Hugging Face за ответами к заданиям.

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

Сначала команда попробовала фронтирные модели через API, но это не сработало. Для анализа нужно отправлять в модель эксплойты и артефакты C2, а гардрейлы такие запросы (сюрпризсюрприз) блокируют: они не отличают ибшника и хакера. В итоге расследование провели на открытой модели GLM 5.2, развернутой у себя. Заодно данные атакующего и учетные данные из логов не ушли за периметр.

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

В апреле в нашем офисе проходил московский хаб BitGN Agent Challenge. Там задачи по безопасности были ловушками для агентов: промпт-инъекции, фишинговые письма. 

В BlueSec безопасность и есть задача.

Сценарии мы собирали вместе с экспертами по расследованию инцидентов. Перед открытым запуском провели внутренний этап: задачи решали сотрудники Positive Technologies, причем не только из SOC, но и разработчики, тестировщики, инженеры. 

Что должен сделать агент

Агент получает первую улику: алерт или подозрительное действие в инфраструктуре. Дальше он должен раскрутить инцидент целиком:

• какие хосты захвачены

• какие учетные записи скомпрометированы

• какие риски реализованы

После этого агент выносит вердикт: была атака или нет.

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

Описание одного сценария (агенты не видят его):

С украденной валидной доменной учётной записью актор подключается по RDP с аномального внешнего хоста, выполняет разведку доменных групп и ACL, получает отказ при дампе учётных данных из LSASS на хосте, к которому подключился, а затем переключается на обзор ролей и разрешений локальной SQL-базы, где обнаруживает собственный недокументированный грант UPDATE на таблицу получателей платежей по сделкам и перезаписывает на месте одну запись получателя.

Process C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe (PID: 3080) was started on host APP97 (IP: 10.37.212.235) at 2024-06-12T20:59:28+00:00

{
    "trigger_entities": [
        {
            "id": "bfe64f2c-1e7c-54aa-90b5-7012018f03e1",
            "type": "host",
            "properties": {
                "hostname": "APP97",
                "ad_object_id": "44fb2469-803a-58bd-80de-4b2377aea7cc",
                "platform": "windows",
                "os": "Windows Server 2019",
                "os_version": null,
                "ip": "10.37.212.235",
                "ip_addresses": null,
                "mac_addresses": null,
                "architecture": null,
                "domain": "keystone.local",
                "role": "server",
                "is_virtual_machine": null,
                "boot_time": null
            },
            "host_id": null
        },
        {
            "id": "83ddd3f2-ae87-52ee-b29a-4f999ce09039",
            "type": "windows_process",
            "properties": {
                "pid": 3080,
                "parent_pid": 6324,
                "parent_image": "C:\\\\Windows\\\\explorer.exe",
                "image_path": "C:\\\\Windows\\\\System32\\\\WindowsPowerShell\\\\v1.0\\\\powershell.exe",
                "cmdline": "powershell.exe",
                "cwd": "C:\\\\Users\\\\svc_bi",
                "powershell_host": "ConsoleHost",
                "powershell_version": "5.1.17763.1592",
                "user_sid": "S-1-5-21-1653141765-1919052686-1450328695-8058",
                "user": "keystone.local\\\\svc_bi",
                "integrity_level": "medium",
                "session_id": 4,
                "logon_id": "0xed8c6",
                "is_elevated": null,
                "sha256": "9F914D42706FE215501044ACD85A32D58AAEF1419D404FDDFA5D3B48F66CCD9F",
                "sha1": "F43D9BB316E30AE1A3494AC5B0624F6BEA1BF054",
                "md5": "04029E121A0CFA5991749937DD22A1D9",
                "original_filename": "PowerShell.EXE",
                "digital_signature": null,
                "signed": true,
                "signer": "Microsoft Windows",
                "company": "Microsoft Corporation",
                "product": "Microsoft\\u00ae Windows\\u00ae Operating System",
                "file_description": "Windows PowerShell",
                "file_version": "10.0.19041.546 (WinBuild.160101.0800)",
                "token_privileges": null,
                "start_time": "2024-06-12T20:59:28+00:00",
                "end_time": null,
                "loaded_modules": null
            },
            "host_id": "bfe64f2c-1e7c-54aa-90b5-7012018f03e1"
        }
    ],
    "trigger_relations": [
        {
            "id": "23715389-c162-5f0e-ba45-3fb150405ce3",
            "type": "hosts",
            "source_id": "bfe64f2c-1e7c-54aa-90b5-7012018f03e1",
            "target_id": "83ddd3f2-ae87-52ee-b29a-4f999ce09039",
            "timestamp": null,
            "log_sources": [
                "Sysmon-1",
                "WinEvt-4688"
            ],
            "properties": null,
            "logon_properties": null,
            "access_properties": null
        }
    ]
}

Как устроена платформа

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

Платформа оценивает три параметра:

1. верен ли вердикт

2. насколько полно расследован инцидент

3. сколько вызовов инструментов потребовалось

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

Модель или харнесс

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

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

Как начать

Есть три пути.

Базовый агент. Мы выложили агента, который уже умеет подключаться к платформе, получать задачи, вызывать инструменты и отправлять результат. Внутри простой ReAct-цикл. Склонируйте репозиторий, пропишите свои API-токены в .env, запустите, и вы увидите себя на лидерборде. Дальше агента можно дорабатывать.

Агент, который пишет агента. Дайте репозиторий и документацию платформы своему кодинговому агенту (Codex, Claude, Kimi Code etc.). Попросите прогнать решение на нескольких кейсах, разберите ошибки, попросите предложить и реализовать улучшения. Это самый быстрый способ попасть в лидерборд. Если вы не работаете в SOC, тот же кодинговый агент поможет разобраться в предметной области.

С нуля. Любой язык, любой стек, свой агентный цикл. Агенты взаимодействуют с платформой по протоколу gRPC.

Подойдет любая модель, через OpenRouter или по API ключам. Главное, чтобы она поддерживала tool calling и structured output. Если ответ плохо структурирован, агенту придется делать лишние вызовы, а это минус к скору.

Когда агент и модель готовы, идете на сайт и регистрируетесь.

Как улучшать агента

Первая версия агента почти наверняка будет ошибаться. Дальше работа идет по циклу: прогнали, разобрали ошибки, поправили, прогнали снова.

Разбирайте, где именно агент ошибся в расследовании:

• вынес не тот вердикт;

• пропустил звено цепочки или нужную сущность;

• добавил в ответ то, чего в инциденте не было;

• не распознал ложное срабатывание.

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

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

Меняйте по одному параметру за раз и ведите историю прогонов, тогда видно, какое изменение улучшает разбор, а какое дает регрессию. Логируйте траектории: алерт, шаги агента, ответы. Без логов не понять, почему результат изменился.

Как не переобучиться

Публичный набор задач ограничен, и score по нему виден. Поэтому агента легко подогнать под эти кейсы и вытянуть почти идеальный балл. Запомнить конкретные ответы не выйдет: id, scenario_id и имена хостов мутируют от запуска к запуску. А вот подогнать агента под паттерны публичного набора можно, и это главная ловушка.

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

Вы строите агента для реального мира, а не под эти кейсы. Цель не балл на публичном наборе, а расследование инцидента, которого агент раньше не видел. Что для этого делать:

• рассуждать от улик, а не от заученных идентификаторов;

• валидировать агента на отложенных кейсах, то есть локально гонять мутированные инциденты, которых он не видел;

• закрывать обе стороны, и атаки, и ложные срабатывания: агенты склонны чаще нужного выносить malicious и хуже объясняют, почему активность легитимна;

• не опираться на дыры платформы вроде утечек id или детерминизма, к закрытому этапу их закроют.

Что дальше

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