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

Краткое содержание

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

Аннотация

Центры операций безопасности (SOC) регулярно преобразуют отчёты по киберразведчикам (CTI) в оперативный контент для обнаружения. Постоянным узким местом в этом рабочем процессе является перевод извлечённых индикаторов компрометации (IOC), в частности путей к файлам, ключей реестра и строк командной строки, в развертываемые регулярные выражения (regexes), подходящие для вложения в правила корреляции информации безопасности и управления событиями (SIEM). Хотя предыдущие работы улучшили автоматизированное извлечение индикаторов компромисса (IOC), преобразование извлечённых строк в валидированные шаблоны regex в основном выполняется вручную, требует специализированной экспертизы и подвержен ошибкам. Цель этого протокола — предоставить стандартизированную, воспроизводимую процедуру трансляции IOC в регулярный выражение. Рабочий процесс состоит из пяти этапов: (1) разбор гетерогенных отчётов CTI в единое представление Markdown; (2) извлечение из IOC с использованием нескольких крупных языковых моделей (LLM) с консенсусным голосованием; (3) нормализация, категоризация и дедупликация извлечённых МОК на основе правил; (4) графовая маркировка компонентов IOC как keep (группа захвата) или discard (не захватывающая группа); и (5) итеративная генерация regex с диагностической валидацией по исходным строкам IOC. Для оценки полезности рабочий процесс был применён к 3 156 отчетам CTI, а полученные регулярные выражения были проанализированы по более чем 2 400 независимо собранным строкам правды из десяти сценариев оценки MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK), что дало средний процент попаданий 99,1 % и средний коэффициент несоответствия между IOC 0,8 %. Таким образом, протокол документирует воспроизводимую реализацию перевода IOC в регулярные выражения и явно определяет его текущий объём, операционные предположения и известные случаи отказов.

Введение

Киберпреступность продолжает создавать значительные операционные и финансовые нагрузки на организации в государственном и частном секторах. В 2023 году зарегистрированные убытки от киберпреступности в США превысили 12,5 миллиарда^{долларов, что} подчёркивает масштаб и устойчивость вредоносной деятельности. В этом контексте Центры операций безопасности (SOCs) выступают в роли основных оперативных подразделений, отвечающих за обнаружение, анализ и реагирование на угрозы в реальном времени.
Логика обнаружения во многих рабочих процессах SOC реализуется через механизмы на основе правил в платформах Security Information and Event Management (SIEM), которые широко используются благодаря их интерпретации, детерминированию и совместимости с существующими рабочими процессами SOC. Среди различных типов правил корреляционные правила SIEM особенно важны для выявления поведения атак, охватывающих несколько событий, хостов и временных окна. В рамках этих правил регулярные выражения (регулярные выражения) функционируют как многократно используемый поисковый примитив: аналитики внедряют их в более широкие правила обнаружения, добавляющие ограничения по полям, специфичные для платформы фильтры и логику корреляции событий, вместо того чтобы использовать их как автономные детекторы.

На практике аналитики SOC часто начинают разработку правил с индикаторов компрометации (IOC), полученных из отчётов по киберразведчикам (CTI), опубликованных поставщиками безопасности, независимыми исследователями или общественными базами знаний, такими как MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK⁾². Эти строки IOC могут включать пути к файлам, фрагменты командной строки, ключи реестра или другие структурированные артефакты, обнаруженные во время^{атак 3}. Перевод таких строк в шаблоны regex, подходящие для правил корреляции SIEM, является повторяющейся задачей в рабочем процессе создания правил.

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

Основная задача при переводе из IOC в регулярные выражения — определить, какие части IOC кодируют стабильное, релевантное для атакующему поведение и, следовательно, должны сохраняться, а какие — отражать вариации, специфичные для среды или хоста, и их следует обобщать. Например, канонические корни реестров, такие как HKEY_CLASSES_ROOT\CLSID, системные каталоги вроде System32, и известные исполняемые имена, такие как rundll32.exe, обычно должны оставаться явными, тогда как пути профиля пользователя, специфичные для хоста идентификаторы безопасности (SID) и глобально уникальные идентификаторы (GUID) обычно должны быть абстрагированы. Постоянное выполнение этого между гетерогенными типами IOC делает задачу перевода непростой. В этом протоколе мы называем первые компонентами сохраненной или группой захвата, а вторые — абстрактными или не-групповыми компонентами.

Предыдущие исследования изучали автоматизированное извлечение разведданных угроз из неструктурированного текста с использованием обработки естественного языка и методов извлечения^{сущностей 6,7}. В последнее время несколько исследований изучали прямую генерацию правил обнаружения из отчётов CTI с использованием крупных языковых моделей (LLMs)⁸. Эти подходы показывают, что части рабочего процесса создания правил могут поддерживаться языковыми моделями, но обычно они не сосредоточены на конкретной операционной задаче генерации шаблонов регулярных выражений, которые сохраняют семантику групп захвата и остаются подходящими для дальнейшего развертывания SIEM. Взаимодополняющие направления работы имеют структурированное содержимое CTI для дальнейшего использования различными способами, включая представления на основе графов знаний, такие как^{TINKER 9}, и генерацию запросов для поиска логов с помощью CTI, например ThreatRaptor¹⁰, которые преобразуют неструктурированные CTI в структурированные знания или языки запросов, специфичных для предмета, а не в шаблоны регулярных выражений, предназначенные для встраивания в правила корреляции SIEM.

Параллельно предыдущие исследования изучали автоматизированный синтез регулярных выражений с использованием методов на основе примеров, нейронного перевода и подходов генерации и^{ремонта 11, 12, 13, 14, 15, 16}. Однако эти методы обычно предназначены для условий, основанных на больших наборах представительных примеров или описаний на естественном языке, а не на контекстах обнаружения, основанных на IOC. В рабочих процессах SOC строки IOC часто редки, структурно разнородны и тесно связаны с операционной семантикой. Это несоответствие мотивирует рабочий процесс, адаптированный для перевода IOC в regex, а не на утверждение, что существующие методы генерации регулярных выражений в целом недостаточны.

Представленный здесь протокол сосредоточен конкретно на этапе перевода IOC в регулярный выражение в рабочем процессе обнаружения SOC. Экстракция IOC рассматривается как исходящий из ручного анализа, автоматизированного инструмента или их комбинации; протокол не пытается генерировать полные правила SIEM. Вместо этого он предоставляет систематическую процедуру преобразования строк IOC в шаблоны регулярных выражений, которые являются синтаксически валидными, семантически интерпретируемыми и подходящими для операционного развертывания. Текущая область действия IOC является целенаправленной: пути файлов, ключи реестра и индикаторы командной строки содержат как стабильные, так и переменные структурные компоненты, которые выигрывают от обобщения regex, тогда как атомарные индикаторы, такие как IP-адреса, домены и хэши, более естественно реализуются с помощью условий точного совпадения или поисков в стиле репутации и поэтому выходят за рамки основной области. В этих границах протокол предназначен для переносимости в средах SOC, которые имеют сопоставимые форматы входа и предварительные условия инструментов.

Протокол

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

1. Настройка системы

1. Установите необходимые требования.
   1. Установите Python 3.8 или новее, все зависимости Python, указанные в requirements.txt, и базу данных графов Neo4j.
      1. Подтвердите доступ к одному или нескольким интерфейсам программирования приложений (API) для выбранных крупных языковых моделей и убедитесь, что сервис Neo4j работает и доступен ли с локальной машины.
   2. Подтвердите, что таблица материалов завершена.
      1. Убедитесь, что перечислены зависимости во время выполнения, включая версию интерпретатора Python, зависимости от конвейера, версию Neo4j и бэкенд для извлечения текста Portable Document Format (PDF).
      2. Убедитесь, что указаны опции конфигурации LLM, включая поставщиков LLM, названия и версии моделей, температуру, варианты рассуждения и усилий и настройки ансамблевого голосования.
      3. Убедитесь, что указаны форматы ввода и вывода, включая поддерживаемые форматы входных файлов и поддерживаемые форматы экспорта.
2. Запустите веб-интерфейс пользователя (UI).
   1. Откройте терминал, перейдите к корневому каталогу референс-реализации и запустите приложение с помощью задокументированной команды запуска (в референсной реализации: cd langchain_pipeline затем streamlit run app_v2.py).
   2. Убедитесь, что приложение загружается в http://localhost:8501 и что панель конфигурации в боковой панели видна.
3. Настройте провайдера LLM.
   1. В разделе конфигурации LLM на боковой панели выберите провайдера LLM, введите имя модели и введите допустимый ключ интерфейса программирования приложений (API).
   2. Запишите поставщика, название модели, версию модели, температуру, параметры рассуждения и усилий и дату доступа к таблице материалов.
      ПРИМЕЧАНИЕ. В эталонной реализации извлечение IOC из одного LLM по умолчанию относится к основной коммерческой LLM, указанной в таблице материалов, с температурой = 0.0; Генерация регулярных выражений по умолчанию устанавливает температуру = 0.3.
4. Включить ансамблевое голосование (необязательно, но рекомендуется для воспроизводимых результатов).
   1. Включите опцию ансамблевого голосования в боковой панели, чтобы сохранить только МОК, которые достигли минимального порога голосов (рекомендуем минимум голосов ≥ 2).
   2. Добавьте дополнительные экземпляры LLM, указав провайдера, имя модели, ключ API и количество повторений выполнения на модель.
      1. Запишите количество повторений каждого поставщика и выбранный минимальный порог голосов.
         ПРИМЕЧАНИЕ. Голосование по ансамблю является необязательным. При отключении конвейер выполняет извлекательную систему одного LLM, а фильтр консенсуса пропускается. Стандартные настройки ансамбля: повторы = 1 на одну настроенную модель и min_votes = 2.
5. Подключитесь к Neo4j.
   1. В разделе Neo4j Connection боковой панели введите URI соединения (например, bolt://localhost:7687), имя пользователя и пароль.
   2. Убедитесь, что интерфейс сообщает об успешном соединении. Не продолжайте без активного подключения.
6. Защитите все учетные данные.
   1. Рассматривайте ключи LLM API и пароль Neo4j как конфиденциальные учетные данные. Храните их в переменных среды или в менеджере секретов, а не в исходных файлах, экспортированных отчетах или скриншотах, и быстро поворачивайте любой ключ, если подозревают утечку.
      ПРИМЕЧАНИЕ. Этот программный протокол не требует химического вытяжки, биобезопасности или другого физического оборудования для удержания; Обрабатывать конфиденциальные отчёты и учетные данные CTI в соответствии с институциональными политиками безопасности данных.

2. Этап 1: разбор документов

1. Процедура.
   1. Перейдите на вкладку «Обработка» в основном интерфейсе.
   2. Загрузите отчёт CTI в поддерживаемом формате (.pdf, .docx, .md, .txt или .html).
   3. Нажмите «Запустить следующий этап», чтобы выполнить Этап 1, или «Запустить все этапы», чтобы выполнить весь конвейер последовательно.
2. Подтвердите контрольную точку первого этапа.
   1. Убедитесь, что отображается предварительный просмотр вводного документа через Markdown.
   2. Проверьте, что пути файлов, ключи реестра, фрагменты командной строки и границы разделов остаются нетронутыми в предварительном просмотре.
   3. Если технические строки урезаны или форматирование отброшено, исправьте исходный файл или предварительно обработайте документ с помощью внешнего конвертера перед повторной загрузкой.

3. Этап 2: Экстракция IOC

1. Процедура.
   1. Подтвердите конфигурацию LLM (и ансамблевое голосование, если включено).
   2. Нажмите «Запустить следующий этап», чтобы выполнить второй этап.
2. Подтвердите контрольную точку второго уровня.
   1. Убедитесь, что интерфейс отображает коллекцию IOC в формате JavaScript Object Notation (JSON) с тремя ключевыми ключами: Пути к файлам, Командные строки и Ключи реестра.
   2. Когда ансамблевое голосование включено, проверяйте, что для каждого сохранённого IOC записаны подсчёты голосов и метаданные модели вклада.
      ПРИМЕЧАНИЕ. Дословная система Этапа 2 и человеческие запросы, а также запросы генерации и оптимизации Этапа 5 выпускаются как Дополнительный файл 1 (Supplemental_File_1_Prompts.txt).

4. Этап 3: Анализ и классификация МОК

1. Процедура.
   1. Нажмите «Запустить следующий этап», чтобы выполнить этап 3.
2. Подтвердите контрольную точку третьего этапа.
   1. Убедитесь, что каждый сохранённый IOC перечислен со стандартизированной категорией, исходным тегом и оригинальным ключом извлечения, когда он доступен.

5. Стадия 4: нормализация МОК с помощью Neo4j

1. Процедура.
   1. Убедитесь, что соединение с Neo4j активно.
   2. Нажмите «Запустить следующий этап», чтобы выполнить Этап 4.
   3. Проверьте выходные выходы нормализации для каждого IOC и убедитесь, что для компонентов пути и командной строки созданы метки keep/discard, а также что ключи реестра дают смежную каноническую подстроку.
2. Подтвердите контрольную точку четвёртого уровня.
   1. Убедитесь, что для каждого типа IOC создаются нормализованные таблицы IOC (пути к файлам, ключи реестра, индикаторы командной строки).
   2. Проверьте, что каждая запись содержит исходное значение, нормированное значение и список компонентов пар элемент/статус, помеченных как keep или discard.
      ПРИМЕЧАНИЕ. Подробная схема Neo4j, запросы Cypher, правила принятия решений и процедура нормализации ключей реестра приведены в дополнительном файле 2; проверенный пример приведён в разделе «Репрезентативные результаты».

6. Этап 5: генерация и подсчёт оценок по регулярным выражениям

1. Процедура.
   1. Нажмите «Run Next Stage», чтобы выполнить Этап 5. Подтвердите, что каждый нормализованный IOC и его список запрещённых токенов подаются на генерацию regex и детерминированную валидацию.
   2. Если кандидат не проходит валидацию, позвольте циклу оптимизации уточнить регулярный выраженный выражение до получения соответствующего кандидата или достижения лимита итерации.
   3. Проверьте диагностический результат, историю оптимизации и количество итераций для любого IOC, чей итоговый regex возвращается от соответствующего на наиболее высоко набранное частичное совпадение (зафиксировано как used_fallback = True).
2. Подтвердите контрольную точку пятого уровня.
   1. Подтвердите, что для каждого сохранённого IOC создаётся окончательный regex.
   2. Проверьте, что учтены баллы кандидатов, истории оптимизации, списки проблем и количество итераций.
   3. Проверьте, что телеметрия по IOC, включая предполагаемое использование токена и задержку, ведётся в логе.
      ПРИМЕЧАНИЕ. Подробные правила валидации regex, формула оценки и параметры управления итерацией приведены в дополнительном файле 2.

7. Аналитика и валидация

1. Откройте вкладку «Аналитика», чтобы просмотреть распределения IOC, результаты голосования по ансамблю (при включении), сводки качества регулярных выражений и статистику оптимизации. Используйте эти сводки для выявления аномалий, таких как дисбаланс экстракции или повторяющиеся сбои оптимизации.

8. Результаты экспорта

1. Во вкладке «Экспорт» выберите формат экспорта (обычный текст, JSON или YAML) и скачайте набор регулярных выражений. Подтвердите, что экспортированные регулярные выражения содержат соответствующие оценки и метаданные категоризации.
2. Сгенерируйте и скачайте полный отчет JSON, содержащий парсовые документы, извлеченные IOC, нормализованные представления, кандидатные регексы и конечные выходы. Сохраните этот отчет как запись воспроизводимости.

9. Устранение неполадок

1. Если Этап 1 возвращает усечённый или пустой PDF-контент, предварительно обработайте документ с помощью внешнего конвертера или оптического инструмента распознавания символов перед повторной загрузкой и убедитесь, что технические артефакты остаются видимыми в предварительном просмотре Markdown.
2. Если второй этап возвращает слишком мало консенсусных МОК, проверьте поставщика, модель, API-ключ, повторное количество и минимальные настройки голосов перед изменением порога. Проверьте исключённых кандидатов, чтобы отличить галлюцинации от чрезмерно строгого голосования.
3. Если Stage 4 помечает все компоненты как отброшенные, проверьте связность Neo4j и убедитесь, что граф содержит соответствующий словарь Path, Registry или командного интерфейса (CLI) для анализируемого типа IOC.
4. Если на этапе 5 появится регулярный виключ, который компилируется, но не удаётся совпадения или чрезмерно обобщает, перед повторной генерацией кандидата проверьте историю оптимизации, позицию диагностического сбоя и проверки на чрезмерное обобщение.

10. Подтвердить окончательные результаты протокола.

1. Убедитесь, что разбор файла Markdown, набор IOC (валидируемый консенсусом при включении ансамблевого голосования или одиночная модель при отключении), категоризированная таблица IOC и граф-нормализованные представления IOC все присутствуют.
2. Подтвердите, что совместимый с SIEM набор regex, аналитические резюме и полный отчет JSON присутствуют, и архивируйте отчет JSON как запись воспроизводимости.

Результаты

В этом разделе представлены репрезентативные результаты, полученные протоколом IOC-to-regex, и резюмирована эталонная оценка, используемая для оценки его операционной применимости. Эталонная оценка обработала 3 156 отчётов CTI, связанных с методами MITRE ATT&CK, проанализировала более 230 000 предложений, извлекла более 63 000 кандидатов в МОК и оценила сгенерированные регулярные выражения по более чем 2 400 независимо собранным строкам с основной правдой из десяти сценариев оценки MITRE ATT&CK. Эти строки с основной правдой — это артефакты атак, отобранные экспертами, о которых независимо сообщают поставщики кибербезопасности во время оценки MITRE ATT&CK, и поэтому отражают структурные закономерности, которые на практике документируют аналитики и поставщики. Ниже приведены результаты сосредоточены на поведении рабочих процессов, структурной корректности и результатах оценки, релевантных для операционного анализа и процессов обнаружения журналов.

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

Этап 1: Вывод разбора документов

Рисунок 2 показывает результат Этапа 1, где входной отчет CTI парнсируется в единое представление Markdown. После успешного выполнения интерфейс отображает структурированный предпросмотр документа, включая границы разделов и индикаторы релевантности.

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

Этап 2: Консенсусная экстракция МОК

Рисунок 3 иллюстрирует результат второго этапа, где кандидаты в IOC извлекаются с помощью ансамблевого голосования с многоуровневыми LLM. Получившийся интерфейс представляет коллекцию IOC в формате JSON, аннотированную подсчётом голосов и моделями.

Сохраняются только те IOC, которые соответствуют установленному минимальному порогу консенсуса. МОК, исключённые на этом этапе, обычно отражают галлюцинации, специфичные для модели, или неоднозначные фрагменты текста. Их исключение является ожидаемым и желательным результатом, что указывает на правильное функционирование ансамблевого голосования.

Этап 3: Анализ и классификация МОК

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

На рисунке 4 показаны кандидаты в МОК, которые не достигли консенсусного порога во время ансамблевого голосования на втором этапе, а интерфейс выходит на поверхность для аналитика. Такие кандидаты обычно отражают галлюцинации, специфичные для модели, или неоднозначные фрагменты текста. Таким образом, рисунки 4 и 5 соответствуют различным выходам этапов — отброшенному набору из Этапа 2 и сохранённому набору из Этапа 3 — а не альтернативным представлениям одного и того же процесса Этапа 3.

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

Этап 4: Нормализация МОК с помощью графов по типам МОК

Рисунки 6, Рисунок 7 и Рисунок 8 иллюстрируют результаты репрезентативной нормализации для трёх категорий IOC, охваченных в текущем исследовании: пути к файлам, ключи реестра и индикаторы командной строки. Для каждой категории цифры сравнивают исходный IOC, извлеченный из отчёта CTI, с нормализованным представлением, полученным с помощью графового анализа.

Для всех типов IOC протокол разбивает каждый IOC на семантические компоненты и разрешает иерархические отношения с помощью структурированных знаний, закодированных в базе данных графов. В текущей реализации Neo4j хранит нормализованные узлы Path, Registry и CLI и использует отношения смежности для проверки принадлежности компонентов к признанным цепочкам. Эта роль аналогична использованию структурированных знаний ATT&CK в инженерии^{обнаружения 2}.

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

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

Этап 5: Генерация регулярных выражений с выбором на основе вспомогательных ограничений

Рисунок 9 иллюстрирует результат этапа 5, где протокол генерирует структурно совместимые регулярные выражения из нормализованных IOC посредством итеративного процесса валидации. Реализация сочетает начальную генерацию запроса, диагностический повторный запрос при несоответствии кандидата с IOC, валидацию с учётом отброса и циклы повторных попыток с ограничением.

Имея нормализованный IOC и связанную с ней спецификацию компонента keep/discard, рабочий процесс сначала генерирует начальный кандидат на regex. Кандидат затем тестируется по IOC, диагностически повторно подспрашивается при неудаче сопоставления, проверяется на запретные отброшенные токены и оценивается на чрезмерную обобщённость с помощью случайных отрицательных строк.

Когда несколько кандидатов выполняют базовые проверки валидации, протокол применяет вспомогательный механизм выбора на основе ограничений, чтобы сохранить репрезентативный регуляр для последующего использования. Текущая реализация оценивает кандидатов по показателю 'Score = n_cg - n_wc', где 'n_cg' — количество представленных компонентов сохранения, а 'n_wc' — количество отброшенных или неотображённых токенов, присутствующих в регулярном выражении.

Функция выбора определяется как:

Счёт = n_cg − n_wc

Это специализация равного веса (α = β = 1) более общей формы Score = α·n_cg − β·n_wc. Здесь n_cg обозначает количество представленных компонентов сохранения, а n_wc — количество компонентов отброса или неотобразённых дополнительных токенов, вновь введённых регулярным выражением. Реализация также фиксирует количество итераций, списки выпусков, предполагаемое потребление токенов, использование кэша и телеметрию задержки для каждого IOC. Настройка равного веса использовалась как простая детерминированная настройка по умолчанию для эталонной реализации; поскольку он рассматривает недостающий компонент сохранения и повторно введённый компонент сброса как одинаково нежелательные, другие веса могут быть предпочтительны в контекстах развертывания, где ложноотрицательные и ложноположительные несут разные операционные затраты.

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

Обзор аналитики обработки CTI

Рисунок 10 даёт обзор результатов анализа CTI по всем обработанным документам. В эталонной оценке извлечение IOC из 3 156 отчётов CTI дало более 63 000 кандидатов в IOC, включая 12 195 путей к файлам, 2 302 ключа реестра и 10 286 индикаторов командной строки, при этом остальные кандидаты относятся к типам IOC без регулярного выражения.

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

В эталонной оценке сгенерированные регулярные выражения были оценены на более чем 2 400 независимо собранных строках с основной правдой из десяти сценариев оценки MITRE ATT&CK, и средний процент попаданий составил 99,1 % вместе со средним коэффициентом несоответствия между IOC 0,8 %. В этой рукописи частота несоответствия используется как семантическая мера специфики: несоответствие возникает, когда регулярный видага, сгенерированный для одного IOC, также совпадает со строкой основной истинности, связанной с другим IOC. Это значение не следует интерпретировать как сквозной коэффициент ложных положительных операционных оповещений, который также зависит от логики правил и контекста развертывания.

Распределение отражает структурный состав корпуса CTI и позволяет пользователям проверить, что извлечённые индикаторы совпадают с ожидаемыми типами IOC. Значительные отклонения от ожидаемых пропорций могут указывать на проблемы с разбором или экстракцией вверх по потоку и должны быть рассмотрены перед переходом к нормализации ниже по потоку и генерации регулярных выражений.

Анализ действий оптимизации по регулярным выражениям

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

Оптимизация, основанная на LLM, составляет 51,7 % всех наблюдаемых действий. Эта распространённость указывает на то, что начальная генерация часто недостаточно для получения регулярных выражений, удовлетворяющих ограничениям группы захвата и требованиям исключения. Вместо этого итеративная оптимизация активно и неоднократно применяется для уточнения кандидатных регулярных выражений.

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

Отдельная характеристика масштабируемости по случайной выборке из 6 000 IOC, сгенерированной с помощью LLM-теста масштабируемости (см. таблицу материалов), показала медианную задержку 2,95 с на IOC и среднюю задержку 23,18 с. В той же характеристике синтаксисически валидная компиляция regex достигла 99,56%, общий успех генерации — 99,4%, среднее предполагаемое использование токена составляло примерно 3 986 токенов на IOC, а рабочий процесс требовал примерно 7,89 LLM-вызовов на IOC. Процент успешности первого прохода составил 56,46 % для цикла отладки матча и отладки 72,92 % для цикла проверки без группы захвата. Эти измерения помогают охарактеризовать вычислительные затраты и операционную пропускную способность для пакетного использования.

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

Операционные доказательства и неудачное обращение. Рисунок 12 показывает структуру экспортированного файла SIEM regex, созданного протоколом, а также доказательства валидации на уровне правил для репрезентативных шаблонов пути файла, ключей реестра и командной строки. Рисунок 13 показывает соответствующий полный отчет JSON, который показывает все выходные данные стадий (извлечённые, проанализированные и нормализованные IOC вместе с сгенерированными шаблонами regex и флагами проверки для каждого IOC) и является основным артефактом, который потребляет инструменты в дальнейшем потоке. Рисунок 14 иллюстрирует, как протокол обрабатывает шумный вход CTI: на этапе анализа помечается дефланжированный, с нарушением пробелов путь файла, корректируется, нормализуется в канонический шаблон %TEMP% и затем преобразуется в компиляционный, соответствующий регекс. Этот использованный пример дополняет операционные доказательства на рисунках 12 и 13 , документируя, как протокол ведёт себя при отходе исходного текста IOC от канонической формы.

Рисунок 1: Общая архитектура протокола IOC-to-regex. На рисунке представлен сквозной конвейер. Кандидатные строки IOC, созданные восходящим экстрактором IOC, разлагаются и сравниваются с опорными узлами в графе Neo4j, заполненном из документации Windows (шаг 1), который получает известные компоненты пути, реестра и командной строки (шаг 2). Переменные или специфические для среды фрагменты маркируются как отброшенные и исключаются из нормализованной реконструкции, сохраняясь в метаданных компонентов, что приводит к нормализованному IOC с метками сохранения и отброса на уровне компонентов (шаг 3). Эти нормализованные IOC затем передаются на этап генерации регулярных выражений на основе LLM (шаг 4), который генерирует кандидатные регулярные выражения, которые оцениваются и итеративно оптимизируются с учётом ограничений групп захвата и правил отброшенного токена (шаг 5) перед выбором окончательного регулярного выражения (шаг 6). Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Рисунок 2: Выход парсинга документа на этапе 1. Сравнение оригинального отчёта CTI и предварительного просмотра разборочного документа. Левая панель показывает исходный отчёт CTI в формате PDF, а правая — унифицированное представление Markdown, сгенерированное парсером. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Рисунок 3: Консенсусная извлечение IOC с использованием ансамблевого голосования с многоуровневыми LLM. Интерфейс иллюстрирует процесс извлечения IOC на основе ансамбля и его промежуточные результаты. Красное поле выделяет настроенные экземпляры LLM, участвующие в извлечении IOC, включая выбранных поставщиков и количество повторных запусков извлечения для каждой модели. Синяя рамка указывает пользовательский порог консенсуса, который определяет минимальное количество случаев, необходимых для сохранения IOC. После агрегирования результатов экстракции по всем моделям и повторениям, кандидатные МОК, которые появляются реже порога, отбрасываются. Оранжевое поле показывает итоговый набор удерживаемых МОК, которые удовлетворяют критерию консенсуса и передаются на последующие этапы анализа. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

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

Рисунок 5: Сохранённый набор IOC со стандартизированной классификацией. Кандидаты IOC, сохраняемые после обработки третьего этапа, показываются вместе со стандартизированными категориями, исходными тегами и оригинальными ключами извлечения, когда они доступны. Эта таблица предоставляет структурированный вход IOC, используемый на этапе нормализации. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Рисунок 6: Нормализация IOC по пути файла с использованием графового анализа. Параллельное сравнение оригинального IOC пути к файлу и его нормализованного представления. Обход на основе графов запрашивает известные компоненты Path по нормализованному имену и маркирует каждый компонент как keep или discard. Идентификаторы дисков и фрагменты переменных файлов могут быть помечены как отброшенные в записи компонентов, в то время как нормализованная форма восстанавливает в основном из сохраненных структурных сегментов, необходимых для построения последующих шаблонов. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Рисунок 7: Нормализация IOC ключей реестра с использованием графового анализа. Нормализация IOC ключа реестра с помощью графового разрешения иерархических структур реестров. Сокращённые корневые ключи расширяются до канонических ульев реестра, а анализатор извлекает самую длинную непрерывную известную подстроку реестра, пропуская заполняющие элементы хоста, значения, подобные SID, и токены, похожие на GUID. Выход фиксирует метки keep/dismissing для каждого сохранённого компонента и создаёт канонический путь реестра для дальнейшей обработки. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Рисунок 8: Нормализация IOC в командной строке с использованием графового анализа. Сравнение исходного командного IOC и его нормализованного представления. Протокол токенизирует командную строку, сохраняя строки в кавычках, нормализует ведущий командный токен через поиск Neo4j, когда это возможно, и рекурсивно анализирует встроенные фрагменты, похожие на пути или реестры. Стабильные компоненты, связанные с командами, помечаются как keep, аргументы переменных — как discard, а итоговая каноническая структура команд восстанавливается из сохраненных элементов. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

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

Рисунок 10: Распределение извлеченных IOC между отчётами CTI. Сводка результатов извлечения IOC, показывающая общее количество индикаторов, выявленных из отчётов CTI, и их распределение по путям файлов, ключам реестра и индикаторам командной строки. Этот взгляд обеспечивает высокий уровень валидации покрытия контента CTI и поведения при извлечении. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Рисунок 11: Распределение действий оптимизации при генерации регулярных выражений. Разбивка действий, выполняемых во время генерации регулярных выражений, включая начальную генерацию, оптимизацию на основе LLM и регенерацию на основе повторных попыток. Оптимизация на основе LLM составляет 51,7 % всех действий, что иллюстрирует, что итеративная доработка является важнейшим компонентом протокола для получения регулярных выражений, удовлетворяющих ограничениям группы захвата. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Рисунок 12: Экспортированный репрезентативным файлом регулярных выражений. Пример содержимого экспорта SIEM regex (siem_rules.txt), сгенерируемого протоколом. Каждая запись включает исходный IOC, предполагаемую категорию (путь к файлу, ключ реестра или командная строка) и проверенный шаблон regex. Прилагаемая таблица валидации суммирует ожидаемое поведение и данные системы, используемые для подтверждения корректности каждого типа правила. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Рисунок 13: Полный отчет JSON представителя. Сквозной выход конвейера, полученный после запуска всех пяти этапов протокола на репрезентативном отчёте CTI. Документ JSON фиксирует исходный файл, счёт парсированных секций, извлечённые IOC, сгруппированные по категориям, записи на этапе 3 с метками источника, дифференциал нормализации стадии 4 и шаблоны regex этапа 5 с флагами валидации по IOC. В отчете также представлены метаданные успеха и ошибок на верхнем уровне, которые позволяют последующим инструментам выявлять частичные сбои. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Рисунок 14: Неудачный или шумный ввод: идентификация и исправление. Рабочий пример того, как протокол определяет и восстанавливается после шумного МОК. Исходный вход %T E M P%\вредоносное ПО[.]EXE отмечен тем, что его токен переменной среды содержит вставленные пространства, а расширение файла было дефангировано. Шаг коррекции удаляет вставленное пробел и восстанавливает буквальную точку; Нормализация этапа 4 затем расширяет %TEMP% в канонический шаблон папки Windows Temp; а этап 5 генерирует регулярный виключ, который компилирует и сопоставляет скорректированный нормализованный IOC. Этот пример иллюстрирует обработку шумных ввода, обсуждаемую в обсуждении. Пожалуйста, нажмите здесь, чтобы увидеть увеличенную версию этой фигуры.

Элемент	Тип	Ценность / Схема	Пример	Примечания
Метка узла	Лейбл	:P ат	Windows, System32, cmd.exe	Хранит компоненты по пути файла Windows
Метка узла	Лейбл	:Реестр	ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ, Microsoft, Windows NT	Хранит компоненты ключевого регистра под корневыми ульями
Метка узла	Лейбл	:CLI	powershell.exe, -ExecutionPolicy, Bypass	Сохраняет командные токены и параметры
Свойство узла	Струна	Название	cmd.exe	Оригинальный корпус; используется для отображения в нормализованном выходе
Свойство узла	Струна	name_lower	cmd.exe	Строчная форма; используется как ключ поиска для всех запросов MATCH
Отношения	Направленный край	(a)-[:NEXT]->(b)	(Windows)-[:NEXT]->(System32)	Обе конечные точки имеют одну и ту же метку; кодирует нативную смежность на Windows системах
Ограничение	Уникальность	n.name_lower УНИКАЛЬНО для каждой этикетки	-	Подано на :P ath, :Registry, :CLI
Источник данных	Покрытие	Windows 8, 10, 11	-	Клиентская ОС заполнена в граф
Источник данных	Покрытие	Windows Server 2012, 2016, 2019, 2022	-	Серверная ОС, заполненная в граф

Таблица 1: схема графа Neo4j, используемая для нормализации IOC (этап 4). Перечисляет три метки узлов (Path, Registry, CLI), их общую схему свойств (имя, name_lower), направленную смежность, используемую для нативного порядка рёбер, ограничения уникальности, а также клиентские и серверные версии Windows, заполняющие граф.

Сцена	Ожидаемый выпуск	Автоматизированная валидация	Контроль качества, ориентированный на аналитиков
Этап 1: Разбор документов	Текст Unified Markdown, разбитый на 4 000 символов до обработки LLM.	—	Визуальная проверка предварительного просмотра Markdown, чтобы убедиться, что пути к файлам, ключи реестра, фрагменты командной строки и границы разделов выдержаны при разборе; Если технические строки усечены, переключитесь на бэкэнд.
Этап 2: Экстракция IOC	JSON с тремя ключами верхнего уровня (пути к файлам, командные строки, ключи реестра); Подсчёт голосов на каждый IOC и метаданные модели вклада, когда включено ансамблевое голосование.	Фильтр порога консенсуса (min_votes) исключает МОК, чье количество голосов ниже установленного порога.	Проверка исключённых кандидатов с целью отличия галлюцинаций от чрезмерно строгого голосования перед корректировкой min_votes.
Этап 3: Анализ и классификация МОК	Категоризированный список IOC: каждый IOC сочетается со стандартизированной категорией, исходным тегом и исходным ключом извлечения, когда он доступен.	Отображение стандартизированных категорий с помощью правил на основе регулярных выражений и эвристик IOC-паттернов; (IOC, категория) дедупликация пар.	Точечная проверка категоризированного результата для неоднозначных или шумных кандидатов (рисунок 4A).
Стадия 4: нормализация с поддержкой Neo4j	Нормализованная форма для каждого IOC с метками на уровне компонентов сохранения и отбрасывания.	Cypher делает запросы (i)-(iii) по графу ссылок Windows; детерминированная предобработка, когда Neo4j недоступен.	Инспекция случаев с полностью отброшенными вариантами для выявления пробелов в покрытии графов; расширение графовых данных с использованием специфических для поставщика или среды ссылок, когда это необходимо.
Этап 5: Генерация и подсчёт оценок по регулярным выражениям	Итоговый регуляр для каждого IOC с баллами кандидатов, историей оптимизации, количеством итераций и телеметрией по IOC.	Тест на совпадение, статические проверки качества, проверка запрещённых токенов с учётом границ, тест на чрезмерную генерализацию против 5 детерминированных отрицательных выборок; Запасной вариант к полуматчу с наибольшим количеством очков (used_fallback флаг).	Обзор истории оптимизации для резервных регулярных выражений; Диагностический осмотр по положению неисправности для каждого IOC перед регенерацией.

Таблица 2: Сводка по этапам и валидации. Сопоставляет каждый этап протокола (1–5) с его ожидаемым артефактом, автоматизированным доказательствами валидации, полученными конвейером (статус компиляции regex, частота попаданий, коэффициент несоответствия между IOC, количество итераций оптимизации), а также соответствующую проверку качества с аналитиком (визуальное сравнение, инспекция отброшенных кандидатов и проверка категорий).

Дополнительный файл 1: дословные запросы на LLM. Дословная система и человеческие запросы, используемые для извлечения IOC этапа 2 и генерации и оптимизации regex этапа 5. Пожалуйста, нажмите здесь, чтобы скачать этот файл.

Дополнительный файл 2: Детали реализации для этапов 4 и 5. Алгоритмические и реализующие детали, поддерживающие нормализацию IOC с помощью графов этапа 4 и проверку, оценку и управление итерацией на этапе 5. Пожалуйста, нажмите здесь, чтобы скачать этот файл.

Обсуждение

Перевод неструктурированных отчётов CTI в логику обнаружения исполняемых файлов остаётся трудоёмкой и подверженной ошибкам задачей в рабочих процессах по безопасности операционной безопасности. Хотя предыдущие исследования изучали автоматизацию на уровне извлечения IOC или генерации правил высокого уровня, практики всё ещё сталкиваются с серьёзными трудностями при преобразовании извлечённых строк IOC в регулярные выражения, которые являются структурно корректными, семантически точными и подходящими для последующего использования в SIEM. Протокол, представленный здесь, устраняет этот пробел через поэтапный рабочий процесс, в котором каждая фаза создаёт чётко определённый промежуточный артефакт и применяет явную валидацию перед передачей результатов на следующий этап. Рисунок 14 документирует один из таких случаев, когда дефланжированный, с нарушением пробелов путь файла определяется, исправляется, нормализуется и преобразуется в компиляционный регекс; Обработка шумных входов протокола и его текущий объем обсуждаются совместно с приведёнными ниже ограничениями.

Центральным вкладом этого протокола является явное разложение рабочего процесса на этапы с проверяемыми промежуточными выходами. Реализация теперь описана конкретно: парсинг документов создаёт Markdown и фрагментированный текст для обработки LLM; Извлечение IOC излучает структурированный JSON для путей к файлам, ключей реестра и индикаторов командной строки; Анализ IOC на основе правил стандартизирует и дедуплирует извлечённые значения; Нормализация с поддержкой Neo4j маркирует каждый компонент IOC как keep или dispart; а генерация regex применяет отладку совпадения, проверку отброса и чрезмерную обобщение перед выбором кандидата.

Протокол рассматривает генерацию регулярных выражений как итеративную задачу построения, а не как единичную задачу прогнозирования. Реализация использует начальную генерацию запроса, автоматизированную диагностику сопоставления, ограниченные циклы уточнения и компонентную функцию оценки, чтобы сохранить структурно важные элементы IOC, одновременно штрафуя отброшенные или неотображённые подстроки. Этот итеративный дизайн вместе с детерминированными валидаторами, применяемыми на каждом этапе, поддерживает создание шаблонов регулярных выражений, которые остаются структурно верными на большом и гетерогенном наборе оценок. В эталонной оценке этот рабочий процесс был применён к 3 156 отчетам CTI и оценён по более чем 2 400 независимым строкам ground-truth, что дало средний процент попаданий 99,1 % и средний коэффициент несоответствия между IOC 0,8 %. Поскольку эти строки с основной правдой являются экспертными артефактами, собранными поставщиками кибербезопасности во время упражнений MITRE ATT&CK Assessment, эта оценка неявно сравнивает результаты протокола с паттернами IOC, задокументированными человеческими аналитиками, а не с автоматически сгенерированными.

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

Протокол можно сравнить с тремя семействами альтернативных методов. Во-первых, методы синтеза регулярных выражений на основе примеров, такие как^{TransRegex 11} и Regex+¹², изучают регексы из кураторских наборов положительных и отрицательных примеров строк. Эти методы хорошо работают, когда доступны репрезентативные наборы примеров, но менее напрямую применимы к контекстам SOC, где каждый IOC, представленный в CTI, обычно представлен как одна репрезентативная строка, а требуемая граница обобщения определяется операционной семантикой, а не покрытием примеров. Во-вторых, подходы генетического программирования, такие как те, что были представлены Бартоли и ^др.13,14, исследуют пространство регулярных выражений через эволюционные операторы и обычно требуют маркированного корпуса совпадения и несовпадения строк; они хорошо подходят для пакетного построения паттернов экстракции, но не поглощают напрямую неструктурированные нарративы CTI. В-третьих, современные нейронные и LLM-подходы ^15,16 переводят описания на естественном языке напрямую в регулярные выражения; Эти методы эффективны для чётко заданных запросов, но при одиночном использовании могут создавать синтаксически корректные регулярные выражения, но пропускать необходимые компоненты группы захвата или чрезмерно обобщаться между неродственными вариантами IOC. Настоящий протокол дополняет эти направления: (i) берёт неструктурированные отчёты CTI вместо курируемых наборов примеров или запросов на естественном языке в качестве входа, (ii) разбивая каждый IOC на компоненты с помощью графовой нормализации перед генерацией регулярных выражений, и (iii) валидируя каждый кандидат с помощью детерминированных проверок совпадения, отброса и чрезмерного обобщения в рамках лимитированного итеративного цикла. Цель — не превзойти предыдущие методы на их собственных бенчмарках, а создать воспроизводимый конвейер IOC в regex, промежуточные решения которого подлежат проверке и аудиту аналитиками SOC.

Протокол делает несколько предположений относительно качества входных отчётов CTI. Он предполагает, что (i) строки IOC появляются в восстанавливаемой текстовой форме после разбора документов, то есть пути к файлам, ключи реестра и индикаторы командной строки не встроены исключительно в изображения, скриншоты или запутанные кодировки; (ii) фрагменты IOC, указанные в CTI, достаточно полны, чтобы сохранить свои структурные анкеры (например, ключи реестра сохраняют префикс улья, пути файлов сохраняют как минимум один анкор каталога, узнаваемый для графа документации Windows, а командные строки сохраняют вызывающий исполняемый файл или известный модуль); и (iii) указанные IOC не усекаются, не редактируются и не переписываются таким образом, чтобы убрать компоненты группы захвата, на которых зависит протокол. Отчёты CTI, удовлетворяющие эти предположения, включают большинство описаний техник MITRE ATT&CK, уведомлений поставщиков, отчетов по реагированию на инциденты и хорошо оформленных бюллетеней угроз. Отчёты, основанные преимущественно на скриншотах, сильно сокращённых списках IOC без контекста или свободных текстовых парафразах без явных строк IOC, выходят за рамки предполагаемой операционной оболочки и должны ожидать снижения воспоминания извлечения и менее точной нормализации; Такие отчёты могут получить выгоду от предварительной обработки изображения в текст или аналитического анализа перед началом процесса.

При применении этого протокола следует учитывать несколько ограничений. Во-первых, текущая реализация сосредоточена на путях к файлам, ключах реестра и индикаторах командной строки, а не на более широких категориях IOC, таких как домены, артефакты электронной почты, строки пользователь-агент или поведенческие последовательности. Это осознанный выбор объёма, поскольку атомарные индикаторы обычно хорошо обслуживаются рабочими процессами точного совпадения, а существующий протокол нацелен на переменные структурные МОК, которые выигрывают от обобщения регулярных выражений; тем не менее, она ограничивает применимость к типам IOC, которые в настоящее время не представлены на графике. Во-вторых, текущие сценарии отказов делятся на три основные категории: неродные пути или командные аргументы, отсутствующие в графе операционной системы, неполное покрытие графа для соответствующих утилит или структур, а также неполнота самого источника CTI, когда важные командные фрагменты или командные модули никогда не сообщаются. В-третьих, метрика перекрестного несоответствия IOC, используемая в эталонной оценке, измеряет семантическую специфичность сгенерированных регулярных выражений, а не ложные срабатывания предупреждений по развернутой логике SIEM.

Воспроизводимость при изменчивости и версионировании LLM. Поскольку этапы извлечения IOC и генерации регулярных выражений зависят от коммерческих конечных точек LLM, на воспроизводимость влияют два источника вариабельности: обновления модели со стороны поставщика со временем и стохастичность выборки на вызов. Чтобы смягчить первое, все поля, связанные с LLM, в таблице материалов записывают точные идентификаторы модели и дату доступа, используемую при оценке ссылок, а протокол рекомендует закреплять конкретный снимок модели при раз, когда поставщик его открывает. Чтобы смягчить второе, эталонная реализация фиксирует температуру извлечения из IOC на уровне 0,0 и использует ненулевой температуру только на этапе генерации регулярных выражений, где ансамблевое голосование и детерминированные валидаторы на этапах 2 и 5 поглощают остаточные вариации. При воспроизведении этих результатов пользователи должны записывать точную версию модели, дату доступа, температуру и порог голосования ансамбля; Существенные отклонения по любым из этих осей должны смещать показатели попадания и несоответствия.

На уровне этапа, на котором они возникли, можно решить несколько восстановительных режимов отказа. Сбои парсинга этапа 1 (например, отсканированные PDF-файлы, производящие пустой или искажённый Markdown): предварительно обработайте вход с помощью оптического распознавания символов или внешнего конвертера перед повторной загрузкой; Проверьте, что количество разборных и общее количество символов не равны нулю, прежде чем продолжить. Неудачи экстракции на втором этапе (без возврата IOC или галлюцинационные записи): увеличить порог голосов ансамбля (минимум голосов ≥ 2), включить дополнительные экземпляры моделей или снизить температуру LLM; проверьте подключенность API и подтвердите, что настроенная модель принимает выводы в формате JSON. Нормализация этапа 4 с метками для всех отбросов (каждый компонент IOC помечен как discard): расширить граф опоры Neo4j с помощью специфических для производителя или среды компонентов пути и корней реестра; скрипты импорта Cypher и правило принятия решений о сохранении/отбросе приведены в Дополнительном файле 2. Сбои регулярных выражений на этапе 5 (used_fallback = истинные или повторные отклонения при валидации сброса): проверять поле истории оптимизации для каждого IOC для выявления неисправного валидатора; если у IOC действительно отсутствует стабильные компоненты сохранения, рассмотрите возможность ручного создания регулярных выражений для этого IOC или исключения его из автоматической генерации правил, сохраняя в категоризированной таблице IOC для аналитика.

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

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

Материалы

Список материалов, использованных в этой статье

Имя	Компания	Каталожный номер	Комментарии
Компьютер (ЦП)	—	≥ рекомендуется 4 ядра	Графический процессор не требуется
LangChain	LangChain	≥ 0.1.x	Фреймворк оркестрации LLM
LLM (Извлечение IOC, одномодельная)	OpenAI	gpt-5.1	Используется для извлечения IOC (этап 2), когда голосование ансамбля отключено. temperature = 0.0; max_workers = 5. Доступ: 2025-12-15.
LLM (Генерация регулярных выражений)	OpenAI	gpt-5.1	Используется для генерации регулярных выражений (этап 5). temperature = 0.3 до валидации в нижних потоках. Доступ: 2025-12-15.
LLM (Характеристика масштабируемости)	OpenAI	gpt-5.1	Используется для запуска масштабируемости 6000 IOC, описанного в представительных результатах. Доступ: 2025-12-15.
Память (ОЗУ)	—	≥ рекомендуется 16 ГБ	Требуется для обработки документов
Neo4j	Neo4j, Inc.	≥ 5.x	Графовая база данных для нормализации IOC
Python-драйвер Neo4j	Neo4j, Inc.	≥ 5.x	Интерфейс Python для Neo4j
Операционная система	Microsoft / Apple / Linux	Windows, macOS или Linux	Многоплатформенная поддержка
Парсинг PDF — основной бэкенд	Microsoft	MarkItDown ≥ 0.0.x	Бэкенд этап 1; преобразует входы PDF/DOCX/HTML/TXT в Markdown. Разбитый на куски разбор выхода по 4000 символов пере обработкой LLM. Доступ: 2025-12-15. https://github.com/microsoft/markitdown
Конфигурация конвейера (этап 2 — извлечение IOC)	—	Справочные значения по умолчанию	Режим одиночного LLM: temperature = 0.0, max_workers = 5. Значения по умолчанию в режиме ансамблевого голосования: repeats = 1 на настроенную модель, min_votes = 2.
Конфигурация конвейера (этап 5 — генерация регулярных выражений)	—	Справочные значения по умолчанию	Температура генерации = 0.3. Валидация: overgen_random_tests = 5 детерминированных отрицательных образцов на каждый IOC. Границы итераций: max_iterations = 10, debug_loop_cap = 5, discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	Необходимая среда выполнения
Движок регулярных выражений	Python Standard Library	модуль re	Используется для валидации и тестирования регулярных выражений
Streamlit	Streamlit Inc.	≥ 1.25	Веб-интерфейс пользователя
Исходный код реализации справочного примера	Авторы / GitHub | Репозиторий GitHub		Исходный код для интерфейса Streamlit, конвейера LangChain, нормализации с помощью Neo4j, генерации регулярных выражений, утилит валидации и примеров конфигурационных файлов. Доступен по адресу https://github.com/SOCautomatic/cti-ioc-regex-pipeline. Доступ: 11 июня 2026 года.