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

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

Здесь мы представляем протокол для преобразования индикаторов компрометации из файлов отчётов о киберугрозах, ключей реестра и индикаторов командной строки в проверенные регулярные выражения для правил обнаружения информации и событий безопасности (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...

Обсуждение

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

Материалы

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

Имя	Компания	Каталожный номер	Комментарии
Компьютер (ЦП)	—	≥ рекомендуется 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 года.