Бенчмарк для оценки LLM в задачах триажа security-находок

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

| Если вам интересна тема AI‑агентов и внедрения нейросетей, заглядывайте в мой Telegram‑канал ДругОпенсурса ^[1]. Там я публикую свежие новости и разборы инструментов в числе первых. |

Почему стандартные бенчмарки не подходят

THOR – это форензик-сканер, который мы разрабатываем в Nextron Systems. Он ищет признаки компрометации, подозрительные артефакты, инструменты атакующих, вредоносное ПО, следы persistence и другие security-релевантные свидетельства. Бенчмарк использует находки THOR как входные данные, но сама проблема не специфична для THOR.

Находка THOR – это не задача по программированию, не математическая головоломка и не творческое задание. Это кусок форензик-контекста или security-контекста из реальной системы. Она может указывать на вредонос, инструмент атакующего, подозрительный persistence, странный артефакт кэша, dual-use утилиту админа или просто на ложное срабатывание, которое выглядит страшно на первый взгляд.

Модель должна принять решение:

• подавить как ложное срабатывание

• оставить для ручной проверки

• эскалировать как вероятный инцидент

Эти решения имеют разную стоимость ошибки ^[2]. Если модель помечает безобидную находку как подозрительную, это тратит время аналитика. Особенно плохо, если таких находок много, при сканировании сотен или тысяч систем даже небольшой процент ложных эскалаций создаёт массу лишней работы. Но гораздо хуже, если модель помечает реальный инцидент как безобидный. Это может скрыть атакующего и убрать единственную находку, которая должна была запустить расследование. Модель может отлично справляться с кодом, логическими задачами или написанием отчётов по уязвимостям, но плохо оценивать реальные security-события. И наоборот: менее известная модель может быть более консервативной и принимать лучшие операционные решения для этой конкретной задачи.

Я построил бенчмарк вокруг триажа находок THOR. Цель – не найти лучшую LLM в общем смысле, а понять, как разные модели ведут себя при классификации security-находок как истинно положительных, ложно положительных или неопределённых (Inconclusive).

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

Устройство бенчмарка

Бенчмарк намеренно начинается с чистого листа. Каждая модель получает одну обогащённую находку THOR и должна её классифицировать. Затем контекст сбрасывается, и оценивается следующая находка. Нет долговременной памяти ^[3], нет обратной связи от аналитиков, нет customer-specific allowlist, нет RAG, VirusTotal, песочницы или поиска в SIEM. Это не значит, что модель получает только тонкий намёк. Находка THOR уже обогащена по дизайну — это не то, что мы добавили специально для бенчмарка. Такую же структуру THOR использует в своих обычных отчётах. THOR не просто говорит “подозрительная запись в ShimCache” и оставляет всё остальное на откуп LLM, а парсит форензик-артефакт, добавляет контекст детекта и обогащает событие информацией о файле, где это возможно.

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

Бенчмарк не просит модель рассуждать с нуля. Он просит интерпретировать структурированную, обогащённую security-находку. Мы намеренно убираем внешние инструменты, долговременную память ^[4], предыдущую обратную связь и customer-specific контекст.

В продакшене LLM может быть частью агентного workflow. У неё могут быть инструменты, она может запрашивать VirusTotal, проверять инвентарь активов, искать предыдущие кейсы, смотреть деревья процессов в EDR, инспектировать события в SIEM, использовать customer-specific allowlists или получать обратную связь аналитиков из базы знаний. Всё это может улучшить финальную оценку. Но это меняет то, что мы измеряем. Бенчмарк перестаёт измерять только способность модели к триажу. Он начинает измерять всю систему: модель, промпт, выбор инструментов, качество данных, качество извлечения, customer-контекст, дизайн workflow и накопленную обратную связь от предыдущих решений аналитиков.

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

В текущем бенчмарке используется контролируемая настройка: одно обнаружение, одно решение, никаких инструментов, никакой памяти ^[5], никакой обратной связи. Это не окончательный вариант того, как большая языковая модель будет работать в рамках полноценного рабочего процесса автоматизации SOC.

Что такое триаж находок THOR

THOR сканирует системы на подозрительные файлы, форензик-артефакты, инструменты атакующих, механизмы persistence, подозрительные командные строки, записи в кэше, следы в логах и многие другие сигналы. Когда THOR находит что-то релевантное, он создаёт находку. Находка означает: “Это выглядит достаточно релевантным, чтобы кто-то это оценил”.

Это может быть явное срабатывание на вредонос, веб-шелл, credential dumper, след исполнения инструмента атакующего в ShimCache или AmCache. Это может быть легитимная админская утилита, странный бинарник вендора, продукт для удалённого управления или скрипт, который выглядит подозрительно, но нормален в этом окружении.

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

• True Positive — находка представляет реальную угрозу или индикатор компрометации

• Inconclusive — неопределённость, находка должна остаться видимой для ручной проверки

• False Positive — находка безобидна в этом контексте

True Positive означает, что находка представляет реальную угрозу или индикатор активности атакующего. Её нужно расследовать и обычно эскалировать.

False Positive означает, что находка безобидна в этом контексте. Она могла сработать по правилу, но не требует действий аналитика.

Inconclusive – интересная средняя категория. Inconclusive означает, что находка должна остаться видимой для ручной проверки. Это может быть легитимная аномалия, dual-use инструмент, подозрительная активность админа, необычный механизм persistence или артефакт, который требует customer-specific контекста для оценки. В реальных сканах большинство находок – это ложные срабатывания или безобидные совпадения. Меньшая часть – легитимные аномалии: вещи, которые не являются инцидентами, но и не должны подавляться автоматически. И иногда встречаются те немногие находки, которые действительно важны – реальные индикаторы инцидента.

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

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

Почему scoring отличается

Первая версия бенчмарка была проще. Модель классифицировала находку как TP, FP или Inconclusive. Мы сравнивали ответ с ground truth и рассчитывали score. Это звучит просто, но недостаточно. Проблема в том, что ошибки триажа не равнозначны. В обычных задачах классификации неправильный ответ – это просто неправильный ответ. В security-находках важно, какую именно ошибку допустила модель.

Ложное срабатывание, классифицированное как TP, создаёт нагрузку на аналитиков. Кто-то должен на это посмотреть, возможно, открыть кейс, спросить владельца системы, проверить несколько артефактов. Это раздражает и дорого, особенно в больших масштабах. Но гораздо хуже, когда реальная угроза классифицируется как FP. Такая находка исчезает из workflow. Модель фактически говорит: “игнорируй это”. Если это был единственный след инструмента атакующего, подозрительного persistence или исполнения вредоноса, аналитик может его никогда не увидеть.

Но гораздо хуже, когда реальная угроза классифицируется как FP. Такая находка исчезает из workflow. Модель фактически говорит: “игнорируй это”. Если это был единственный след инструмента атакующего, подозрительного persistence или исполнения вредоноса, аналитик может его никогда не увидеть. Модель, которая переэскалирует безобидные находки — шумная. Модель, которая подавляет реальные угрозы — опасная. Это разные типы ошибок.

Inconclusive означает, что находка должна остаться видимой для ручной проверки. Решение TP→Inc не идеально, но безопасно для проверки. Модель не чётко идентифицировала инцидент, но и не подавила его. Решение Inc→FP более проблематично. Это значит, что аномалия, достойная проверки, исчезает. Это может быть dual-use инструмент, подозрительное поведение ^[6] админа, необычный persistence или другой контекст-зависимый сигнал, который не должен выбрасываться автоматически.

Поэтому мы добавили операционный слой scoring. Бенчмарк измеряет не только качество классификации, но и практическую полезность решения в реальном workflow триажа.

Scoring должен отражать стоимость решения. Упрощённо это выглядит так:

• Критическая ошибка (TP→FP): реальная угроза подавляется

• Переэскалация (FP→TP): безобидная находка помечается как угроза

• Подавление аномалии (Inc→FP): находка, требующая проверки, исчезает

Бенчмарк использует несколько метрик:

• классический confidence-weighted scoring

• операционный scoring триажа

• сбалансированный scoring по FP, Inc и TP

• критический miss rate

• threat capture rate

• false review load

• стоимость

• скорость

Цель не в том, чтобы усложнить бенчмарк ради усложнения. Сам workflow триажа запутан. Это не только про правильность, но и про то, как модель ошибается так, чтобы workflow аналитиков мог это выдержать.

Наивные базовые линии

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

Для этой задачи три очевидные базовые линии:

• классифицировать всё как false positive

• классифицировать всё как inconclusive

• классифицировать всё как true positive

Никто не будет внедрять такие стратегии, но они полезны как ориентир. Они показывают, что должна превзойти модель, чтобы её поведение ^[7] можно было назвать осмысленным.

Стратегия “всё как false positive” опасна. Она подавляет всё. В окружении, где большинство находок безобидны, это может выглядеть хорошо по некоторым метрикам. Она создаёт почти нулевую нагрузку на аналитиков. Но проблема очевидна: она подавляет и все реальные инциденты.

Стратегия “всё как true positive” имеет обратную проблему. Она избегает подавления реальных угроз, но превращает каждую находку в инцидент. На бумаге это выглядит безопасно, но на практике разрушает workflow. Аналитикам приходится обрабатывать всё как срочное. Это не триаж, а паника как стратегия классификации.

Стратегия “всё как inconclusive” интереснее. Она оставляет всё видимым для ручной проверки. С точки зрения ^[8] безопасности это привлекательно, потому что не скрывает TP или аномалии, достойные проверки. Но это значит, что модель фактически не сокращает нагрузку. Она просто пересылает всю кучу аналитику.

Эта базовая линия создала больше всего проблем в scoring. Если бенчмарк слишком сильно вознаграждает безопасность и недостаточно наказывает нагрузку на проверку, “всё как inconclusive” начинает выглядеть как хорошая стратегия. Но это не так. Это просто безопасный fallback. Она ловит всё, но почти ничего не фильтрует. Полезная модель триажа должна балансировать между этими крайностями. Она не должна вести себя как “всё false positive”, потому что это скрывает инциденты. Она не должна вести себя как “всё true positive”, потому что это превращает триаж в спам алертов. И она не должна вести себя как “всё inconclusive”, потому что это просто возвращает всю нагрузку аналитикам.

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

Почему нет единой лучшей модели

После добавления операционного scoring и наивных базовых линий стало очевидно: нет единой лучшей модели для этой задачи.

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

High-safety профиль предпочитает модели, которые почти никогда не подавляют TP. Такие модели могут отправлять много находок аналитикам, но это приемлемо в окружениях, где пропустить инцидент — худший исход. Например, критически важная инфраструктура, высокоценные системы, регулируемые окружения или post-compromise расследования, где приоритет — не пропустить ничего важного.

Balanced SOC профиль пытается держать под контролем обе стороны. Нужен низкий critical miss rate, но также нужно сокращать нагрузку на аналитиков. Это, вероятно, самый распространённый сценарий: модель должна помогать аналитикам быстрее обрабатывать находки, но не подавлять слишком много.

Noise-reduction или high-volume профиль отличается. Здесь главное — объём. Модель должна подавлять достаточно безобидных находок, чтобы workflow масштабировался. Но этот профиль опасен без guardrails. Низкая нагрузка на проверку полезна только если модель не достигает этого за счёт подавления реальных угроз.

Есть и аспект deployment. Модель через vendor API может быть удобной и часто хорошо работает, но не всегда применима. Некоторые окружения не могут отправлять security-находки внешнему провайдеру. Кто-то хочет предсказуемую фиксированную стоимость. Кто-то хочет полный локальный контроль. Кто-то хочет запускать open-weight модели на своём железе, даже если это означает более медленную обработку или более низкое качество.

Поэтому мы разделили результаты по tiers:

• Closed source / vendor API

• Open source / pro hardware

• Open source / consumer hardware

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

Первые результаты

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

Первое, что я понял: обычный лидерборд недостаточен. Модель может хорошо выглядеть по классическому confidence-weighted score, но быть сомнительным выбором для security-триажа, если у неё слишком много критических ошибок. В этом бенчмарке критическая ошибка – когда ground truth – TP, но модель классифицирует как FP. Это та ошибка, которая меня волнует больше всего, потому что она означает, что реальная угроза подавляется.

Поэтому самые полезные графики — не простые “модель A лучше модели B”, а графики trade-off. Один из самых важных – Critical Miss Rate vs False Review Load. Critical Miss Rate показывает, как часто модель подавляет реальные угрозы. False Review Load показывает, сколько безобидных находок всё ещё доходит до аналитика. В идеале модель должна быть низкой по обоим показателям: не скрывать реальные инциденты, но и сокращать шум. Идеальная модель была бы в нижнем левом углу графика.

На практике это сложно. Некоторые модели безопасны, но шумны. Они оставляют TP видимыми, но отправляют много FP на проверку. Это может быть приемлемо для high-safety workflows, но не сокращает нагрузку на аналитиков для high-volume окружений. Другие модели агрессивнее сокращают нагрузку на проверку. Они выглядят эффективными, но некоторые из них платят за это более высоким critical miss rate. Это опасный trade-off. Модель, которая сокращает шум за счёт подавления реальных угроз, бесполезна.

Следующий полезный график – Balanced OTS vs False Review Load. Balanced OTS – это наш операционный score, сбалансированный по FP, Inc и TP. Он не даёт бенчмарку быть доминированным мажоритарным классом. Это важно, потому что результаты реальных сканов часто сильно смещены в сторону FP. Если оценивать только по распределению большинства, модель может выглядеть лучше, чем есть на самом деле, будучи хорошей в подавлении безобидных находок, но плохо работая с редкими важными случаями.

Balanced OTS показывает, делает ли модель полезные операционные решения по всем классам. False Review Load показывает, сокращает ли она нагрузку на аналитиков. Опять же, важен trade-off. Модель с высоким Balanced OTS, но высоким False Review Load может быть безопасной, но шумной. Модель с низким False Review Load, но слабым Balanced OTS может быть эффективной, но слишком рискованной или поверхностной. Интересны модели, которые сохраняют операционную безопасность, сокращая при этом шум.

Ещё один график сравнивает CW% и Balanced OTS. Он полезен, потому что показывает, как могут расходиться классическое качество классификации и операционная полезность. CW% вознаграждает близость к экспертному ответу с учётом уверенности. Это всё ещё ценно, но не полностью отражает операционную стоимость разных ошибок. Некоторые модели хорошо выглядят по CW%, но менее привлекательны, если учитывать Critical Miss Rate, подавление аномалий и false review load. Другие могут не выглядеть впечатляюще по классическому scoring, но ведут себя более консервативно в полезных для триажа аспектах.

Первые результаты показали нечто неожиданное: самая большая или дорогая модель не всегда лучшая для этого workflow. Некоторые более лёгкие модели показали себя удивительно хорошо. В некоторых случаях они были лучшим операционным выбором, чем более крупные pro модели из той же семьи. Моё текущее предположение: некоторые из этих моделей ведут себя более осторожно. Они могут быть менее склонны делать сильные утверждения, и это помогает в security-триаже, где подавление реальной угрозы – худшая ошибка.

Ранние результаты также сделали более важным разделение по tiers. Closed-source API модели удобны и часто сильны, но не всегда применимы в окружениях со строгими требованиями к контролю данных. Open-source модели на pro hardware могут быть более привлекательны для контролируемых deployments. Меньшие open-source модели, работающие на consumer hardware, могут быть интересны для локального триажа или workflows с ограниченным бюджетом, даже если они не выигрывают глобальный лидерборд.

Почему мы не публикуем сырые данные бенчмарка

Есть две причины, почему мы публикуем результаты, графики и методологию scoring, но не сырые данные бенчмарка.

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

Это постепенно сделает бенчмарк менее полезным. Он будет измерять не только то, как хорошо модель справляется с этой задачей security-триажа, но и то, сколько бенчмарка или похожих данных просочилось в тренировочные материалы.

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

Поэтому публичный репозиторий содержит то, что я считаю полезным и безопасным для публикации:

• подход к scoring

• таблицы результатов

• графики

• методологию бенчмарка

• сравнения моделей

• операционные профили

Он не содержит сырые отчёты THOR, приватные ground truth файлы или детальный материал кейсов за находками.

Как использовать бенчмарк

Я бы не использовал этот бенчмарк как простой лидерборд. Первый вопрос не должен быть “какая модель на первом месте?”, лучший вопрос: какая модель подходит под мой workflow и толерантность к риску?

Для security-триажа я бы начал с типа ошибки, который могу терпеть меньше всего. В большинстве workflows это критический miss: TP, классифицированный как FP. Если модель подавляет реальные инциденты, я бы не стал оправдывать это стоимостью, скоростью или высоким общим score. Поэтому первые метрики для проверки — Critical Miss Rate и Threat Capture Rate. Модель должна оставлять TP видимыми, либо как чёткие TP, либо как Inc, которые всё ещё доходят до человека.

Затем я бы посмотрел на False Review Load. Это покажет, сокращает ли модель нагрузку на аналитиков. Модель может быть безопасной, но всё ещё отправлять слишком много на проверку. Это может быть приемлемо в high-safety workflows, но не решает проблему high-volume триажа.

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

Deployment-ограничения тоже важны. Некоторые команды могут использовать vendor API. Другим нужна локальная обработка, open-weight модели или предсказуемая фиксированная стоимость. Поэтому бенчмарк разделяет модели по tiers. Лучшая глобальная модель может быть неприменима, если не подходит под ваши ограничения по контролю данных или инфраструктуре.

Мой практический порядок анализа:

1. выбрать deployment tier, который вы можете использовать

2. выбрать операционный профиль, который соответствует вашей толерантности к риску

3. отбросить модели с неприемлемым Critical Miss Rate

4. проверить Threat Capture Rate и Anomaly Capture Rate

5. сравнить False Review Load

6. затем сравнить Balanced OTS, стоимость и скорость

Этот бенчмарк должен сузить пространство поиска. Он не должен заменять ваше собственное тестирование. Если вы хотите использовать LLM в реальном SOC или форензик-workflow, протестируйте её на своих алертах, своих ложных срабатываниях, своих внутренних инструментах и своей толерантности к риску.

Текущий статус и следующие шаги

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

Следующий шаг – аккуратно расширять датасет. Больше находок полезно, но только если они добавляют реальный сигнал. Добавление сотен простых FP сделает бенчмарк больше, но не лучше. Важнее разнообразие: больше TP, больше неопределённых/легитимных аномалий, больше операционных систем, больше типов артефактов, больше слабых сигналов и более реалистичных edge-кейсов.

Самая сложная часть – TP. Они должны выглядеть и вести себя как реальные находки, а не как искусственные тестовые объекты. Если образец только выглядит подозрительно, но не имеет реальной вредоносной функции, результат становится неоднозначным. Одна модель может агрессивно его помечать, другая – более внимательно изучить и классифицировать ниже. Это не обязательно означает, что одна модель лучше. Возможно, тестовый кейс был недостаточно чистым. Я также буду добавлять новые модели по мере их появления. Модели меняются, дефолты провайдеров меняются, цены меняются, open-source модели быстро улучшаются. Scoring тоже может эволюционировать, но базовая идея должна остаться: критические ошибки должны быть дороже, чем ложные эскалации, а аномалии, достойные проверки, не должны рассматриваться как одноразовый шум.

Сырые находки и экспертные ground truth останутся приватными. Публичная часть — это методология, подход к scoring, графики и агрегированные результаты. Это та часть, которую я считаю полезной для публикации. Этот бенчмарк – базовая линия. Он показывает, как модели ведут себя на одних и тех же обогащённых находках, без внешних инструментов, памяти, обратной связи или customer-specific контекста. Реальный deployment может работать лучше с контекстом из SIEM, телеметрией EDR, allowlists, обратной связью аналитиков или RAG-памятью. Но тогда вы измеряете весь workflow, а не только модель.

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