将网络威胁情报转化为可计算检测模式的结构化工作流程

摘要

本文介绍了一种将网络威胁情报报告中的失陷指标（如文件路径、注册表项和命令行指标）转换为安全信息与事件管理（SIEM）检测规则中可验证的正则表达式的方法，该方法结合了大语言模型（LLM）的集成提取与图辅助的组件标注技术。

摘要

安全运营中心（SOC）通常会将网络威胁情报（CTI）报告转化为可操作的检测内容。在此工作流程中，一个长期存在的瓶颈是将提取的失陷指标（IOCs），特别是文件路径、注册表项和命令行字符串，转化为适用于嵌入安全信息与事件管理（SIEM）关联规则的可部署正则表达式（regexes）。尽管已有研究在自动化失陷指标（IOC）提取方面取得进展，但将提取出的字符串转化为经过验证的正则表达式模式仍主要依赖人工操作，需要专业知识，且容易出错。本方案旨在提供一种标准化、可重复的 IOC 到正则表达式的转换流程。该工作流程包含五个阶段：（1）将异构的 CTI 报告解析为统一的 Markdown 表示形式；（2）使用多个大语言模型（LLMs）进行 IOC 提取，并通过共识投票机制提高准确性；（3）基于规则对提取出的 IOC 进行归一化、分类和去重；（4）借助图结构辅助标注 IOC 组成部分，标记为保留（捕获组）或丢弃（非捕获组）；（5）基于原始 IOC 字符串进行迭代式正则表达式生成，并进行诊断性验证。为评估其实用性，该流程应用于 3,156 份 CTI 报告，生成的正则表达式在来自十项 MITRE 对抗性战术、技术与通用知识（ATT&CK）评估场景的 2,400 多个独立收集的真实字符串上进行了测试，平均命中率达到 99.1%，跨 IOC 平均误匹配率为 0.8%。因此，本方案记录了一种可重复实现的 IOC 到正则表达式转换方法，并明确界定了其当前适用范围、运行假设以及已知的失效情况。

引言

网络犯罪持续给公共和私营部门的各类组织带来巨大的运营和财务负担。2023年，美国因网络犯罪造成的报告损失超过125亿美元¹，凸显了恶意活动的规模和持续性。在此背景下，安全运营中心（Security Operations Centers, SOCs）作为主要的运营单位，负责实时检测、分析和响应安全威胁。
在许多SOC工作流程中，检测逻辑通过安全信息与事件管理（Security Information and Event Management, SIEM）平台中的基于规则的机制实现，这类机制因其可解释性、确定性以及与现有SOC工作流程的兼容性而被广泛采用。在各类规则中，基于关联的SIEM规则对于识别跨越多个事件、主机和时间窗口的攻击行为尤为重要。在这些规则中，正则表达式（regular expressions, regexes）充当可复用的搜索基本单元：分析人员将其嵌入更广泛的检测规则中，以添加字段约束、平台特定的过滤器和事件关联逻辑，而非将其作为独立的检测器直接部署。

在实际操作中，安全运营中心（SOC）分析师通常从安全厂商、独立研究人员或公开知识库（如 MITRE 对抗战术、技术与常识（ATT&CK））发布的网络威胁情报（CTI）报告中提取的失陷指标（IOCs）开始规则开发²。这些 IOC 字符串可能包括在攻击过程中观察到的文件路径、命令行片段、注册表项或其他结构化攻击产物³。将此类字符串转换为适用于 SIEM 关联规则的正则表达式（regex）模式，是规则编写工作流程中常见的任务。

这一翻译步骤是一个实际的操作瓶颈。编写正则表达式模式需要具备专业技能，这些模式既要具有足够的通用性以捕捉有意义的变异，又要足够精确以避免意外匹配；在语法上的微小错误，或关于哪些组件应保留或泛化的错误决策，都可能导致原本有效的检测规则失效。由于这项工作是手动、重复且注重细节的，可能会延迟对新兴威胁的检测部署，需要更有经验的分析人员进行审查，并增加在实际安全运营中心（SOC）环境中分析人员的工作负担^4,5。

在IOC转正则表达式的过程中，核心挑战在于判断IOC的哪些部分编码了稳定的、与攻击者行为相关的信息，因而应予以保留；而哪些部分反映了环境或主机特有的变化，应进行泛化处理。例如，像HKEY_CLASSES_ROOT\CLSID这样的标准注册表根键、System32等系统目录，以及rundll32.exe等已知的可执行文件名，通常需要明确保留；而用户配置路径、主机特定的安全标识符（SIDs）以及全局唯一标识符（GUIDs）则通常应被抽象化。在不同类型的IOC中一致地实现这种区分，正是该翻译任务复杂性的所在。在本实验方案中，我们将前者称为保留项或捕获组组件，后者称为抽象项或非捕获组组件。

先前的研究已探索利用自然语言处理和实体抽取技术从非结构化文本中自动提取威胁情报^6,7。最近，一些研究进一步探讨了使用大语言模型（LLMs）直接从网络威胁情报（CTI）报告中生成检测规则⁸。这些方法表明，语言模型可在一定程度上辅助规则编写工作流程，但通常并未聚焦于生成保留捕获组语义且适用于下游SIEM部署的正则表达式（regex）模式这一具体操作问题。其他相关研究则以不同方式对CTI内容进行结构化处理，以支持下游应用，包括基于知识图谱的表示方法（如TINKER⁹）以及由CTI驱动生成日志搜索查询的工作（如ThreatRaptor¹⁰），这些方法将非结构化的CTI转换为结构化知识或特定领域的查询语言，而非用于嵌入SIEM关联规则中的正则表达式模式。

与此同时，以往的研究已探索了使用基于示例的方法、神经机器翻译以及生成-修复方法来实现自动正则表达式合成^{11,12,13,14,15,16}。然而，这些方法通常针对依赖大量代表性示例或自然语言描述的场景而设计，而不适用于以情报线索（IOC）驱动的检测环境。在安全运营中心（SOC）工作流程中，IOC 字符串通常稀疏、结构异构，且与操作语义紧密相关。这种不匹配性促使我们构建一种专门针对 IOC 到正则表达式转换的工作流程，而非断言现有的正则表达式生成方法普遍存在不足。

本文所述方案专门针对 SOC 检测工作流程中的 IOC 到正则表达式（regex）转换阶段。IOC 提取被视为上游输入，其来源可能是人工分析、自动化工具，或两者的结合；本方案并不试图生成完整的 SIEM 规则。相反，它提供了一套系统化流程，用于将 IOC 字符串转换为语法正确、语义可解释且适用于实际部署的正则表达式模式。当前的 IOC 范围是经过审慎选择的：文件路径、注册表项和命令行指示符既包含稳定的结构成分，也包含可变部分，因此能够从正则表达式的泛化中受益；而诸如 IP 地址、域名和哈希值等原子型指示符则更适用于通过精确匹配条件或基于信誉的查询方式来实现检测，因此不在本方案的主要覆盖范围内。在上述边界内，该方案旨在适用于具有相似输入格式和工具前提条件的各种 SOC 环境。

方案

使用以下五个阶段的工作流程，将 CTI 报告转化为具有可追溯中间输出的已验证正则表达式模式（概览见图1）。

1. 系统设置

1. 安装先决条件。
   1. 安装 Python 3.8 或更高版本、requirements.txt 中列出的所有 Python 依赖项，以及 Neo4j 图数据库。
      1. 确认可访问所选大语言模型的一个或多个应用程序编程接口（API），并验证 Neo4j 服务正在运行且可从本地机器访问。
   2. 确认材料表已填写完整。
      1. 验证是否列出了运行时依赖项，包括 Python 解释器版本、管道依赖项、Neo4j 版本以及便携式文档格式（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. 在材料表中记录提供商、模型名称、模型版本、温度、推理努力选项以及访问日期。
      ​注意。 在参考实现中，单个 LLM IOC 提取默认使用材料表中列出的主要商业 LLM，温度设为 0.0；正则表达式生成默认温度为 0.3。
4. 启用集成投票（可选，但推荐以获得可重复的结果）。
   1. 在侧边栏中启用“集成投票”选项，仅保留达到最低投票阈值的 IOC（建议最小投票数 ≥ 2）。
   2. 通过指定提供商、模型名称、API 密钥以及每个模型的执行重复次数，添加额外的 LLM 实例。
      1. 记录每个提供商的重复次数和选定的最小投票阈值。
         注意。 集成投票为可选功能。禁用时，管道将执行单个 LLM 提取，并跳过共识过滤器。默认集成设置为每个配置模型重复次数 = 1，min_votes = 2。
5. 连接到 Neo4j。
   1. 在侧边栏的 Neo4j 连接部分，输入连接 URI（例如，bolt://localhost:7687）、用户名和密码。
   2. 确认界面报告连接成功。若无有效连接，请勿继续操作。
6. 保护所有凭据。
   1. 将 LLM API 密钥和 Neo4j 密码视为敏感凭据。应将其存储在环境变量或密钥管理器中，而非源文件、导出报告或截图中；若怀疑密钥泄露，应立即轮换。
      注意。 本软件协议无需使用化学通风柜、生物安全柜或其他物理 containment 设备；应根据机构的数据安全政策处理机密的 CTI 报告和凭据。

第1阶段：文档解析

1. 操作步骤。
   1. 在主界面中进入“处理”选项卡。
   2. 上传一份支持格式的 CTI 报告（.pdf、.docx、.md、.txt 或 .html）。
   3. 点击 "运行下一阶段"以执行第一阶段，或点击 "运行所有阶段"以按顺序执行完整流程。
2. 确认第一阶段检查点。
   1. 确认系统已显示输入文档的 Markdown 预览。
   2. 验证预览中文件路径、注册表键、命令行片段以及章节边界是否保持完整。
   3. 若技术字符串被截断或格式丢失，请修正源文件，或在重新上传前使用外部转换工具对文档进行预处理。

3. 第二阶段：IOC 提取

1. 操作步骤。
   1. 确认大语言模型（LLM）配置（以及是否启用了集成投票）。
   2. 点击 "运行下一阶段" 以执行第二阶段。
2. 确认第二阶段检查点。
   1. 确认界面以JavaScript对象表示法（JSON）格式显示IOC集合，且包含三个顶级键：文件路径（File Paths）、命令行（Command Lines）和注册表键（Registry Keys）。
   2. 当启用集成投票时，需验证每个保留的IOC是否记录了投票计数及贡献模型的元数据。
      注意。 第二阶段的完整系统提示与人工提示，以及第五阶段的生成与优化提示，已作为补充文件1（Supplemental_File_1_Prompts.txt）发布。

4. 第三阶段：IOC 分析与分类

1. 步骤。
   1. 点击 "运行下一阶段" 以执行第3阶段。
2. 确认第3阶段检查点。
   1. 确认每个保留的IOC均列有标准化类别、来源标签，以及在可用情况下的原始提取密钥。

5. 第4阶段：Neo4j辅助的IOC归一化

1. 操作步骤。
   1. 确认 Neo4j 连接处于活动状态。
   2. 点击 "运行下一阶段" 以执行第 4 阶段。
   3. 检查每个 IOC 的归一化输出，验证路径和命令行组件是否已生成保留/丢弃标签，并确认注册表键生成了连续的规范子字符串。
2. 确认第 4 阶段检查点。
   1. 确认已为每种 IOC 类型（文件路径、注册表键、命令行指示符）生成归一化的 IOC 表。
   2. 验证每条记录是否包含原始值、归一化值，以及由元素/状态对组成的组件列表，且每个组件均已标记为保留或丢弃。
      注。 详细的 Neo4j 模式、Cypher 查询语句、决策规则及注册表键归一化流程详见 补充文件 2；代表性结果部分提供了具体示例。

第6步：正则表达式生成与评分

1. 操作步骤。
   1. 点击 "运行下一阶段" 以执行第5阶段。确认每个归一化的IOC及其禁用令牌列表均已提交用于正则表达式生成和确定性验证。
   2. 若候选正则表达式未能通过验证，允许优化循环继续调整正则表达式，直至生成符合要求的候选结果或达到最大迭代次数。
   3. 检查诊断输出、优化历史记录和迭代次数，针对最终正则表达式从合规状态回退至最高得分的部分匹配的任何IOC（记录为 used_fallback = True）进行分析。
2. 确认第5阶段检查点。
   1. 确认为每个保留的IOC均生成了最终的正则表达式。
   2. 核实候选得分、优化历史、问题列表和迭代次数均已记录。
   3. 核实每个IOC的遥测数据（包括预估的令牌使用量和延迟）已记录。
      注意。 详细的正则表达式验证规则、评分公式和迭代控制参数见补充文件2。

7. 分析与验证

1. 打开“分析”选项卡，查看 IOC 分布、集成投票结果（启用时）、正则表达式质量摘要以及优化统计信息。利用这些摘要检测异常情况，例如提取不平衡或重复的优化失败。

8. 导出结果

1. 在导出选项卡中，选择导出格式（纯文本、JSON 或 YAML）并下载正则表达式集。确认导出的正则表达式包含相关的分数及分类元数据。
2. 生成并下载包含已解析文档、提取的 IOC、标准化表示、候选正则表达式及最终输出的完整 JSON 报告。将此报告保存为可重复性记录。

9. 故障排除

1. 如果第一阶段返回截断或空白的 PDF 内容，请在重新上传前使用外部转换工具或光学字符识别工具对文档进行预处理，并确认技术性痕迹在 Markdown 预览中仍然可见。
2. 如果第二阶段返回的共识性指标（IOCs）过少，请在调整阈值前核对提供方、模型、API 密钥、重复次数和最小投票数设置。检查被排除的候选结果，以区分幻觉生成与投票过于严格的情况。
3. 如果第四阶段将所有组件标记为丢弃，请验证 Neo4j 的连接状态，并确认图数据库中包含与正在分析的 IOC 类型相关的路径、注册表或命令行接口（CLI）词汇。
4. 如果第五阶段生成的正则表达式能够编译，但匹配失败或过度泛化，请在重新生成候选表达式前检查优化历史、诊断出的失败位置以及过度泛化检测结果。

10. 确认最终方案的输出结果。

1. 确认已包含解析后的 Markdown 文件、IOC 集（启用集成投票时为共识验证结果，禁用时为单模型结果）、分类后的 IOC 表格以及经过图归一化处理的 IOC 表示。
2. 确认已包含与 SIEM 兼容的正则表达式集、分析摘要以及完整的 JSON 报告，并将 JSON 报告归档为可重复性记录。

结果

本节展示了IOC-to-regex协议产生的代表性结果，并总结了用于评估其操作适用性的参考评估。该参考评估处理了与MITRE ATT&CK技术相关的3,156份网络威胁情报（CTI）报告，分析了超过230,000个句子，提取了超过63,000个IOC候选项，并针对来自十项MITRE ATT&CK评估场景中独立收集的2,400多个真实字符串对生成的正则表达式进行了评估。这些真实字符串是由网络安全厂商在MITRE ATT&CK评估演练中独立报告、经专家整理的攻击产物，因此反映了实际中人类分析师和厂商所记录的结构模式。以下结果重点关注与操作日志分析和检测工作流程相关的流程行为、结构正确性及评估结果。

端到端流程的概述见图1，该图总结了捕获组查找和正则表达式生成阶段，这些阶段构成了代表性结果的框架。

第一阶段：文档解析输出

图2...

讨论

将非结构化的网络威胁情报（CTI）报告转化为可执行的检测逻辑，在实际安全工作流程中仍是一项耗时且易出错的任务。尽管已有研究探索了在指标（IOC）提取或高层级规则生成层面的自动化方法，但实践人员在将提取出的IOC字符串转换为结构正确、语义精确并适用于下游SIEM系统的正则表达式时，仍面临重大挑战。本文提出的协议通过一个分阶段的工作流程弥补了这一空白，每个阶段均生成定义明确的中间产物，并在将结果传递至下一阶段前实施明确的验证步骤。图14记录了一个典型案例，其中一条被去活化且包含干扰空格的文件路径被识别、修正、标准化，并最终转化为可编译的正则表达式；本协议对噪声输入的处理能力及其当前适用范围，将结合下文所列的局限性一并讨论。

本方案的核心贡献在于将工作流程明确分解为多个阶段，并生成可检查的中间输出。具体实现步骤如下：文档解析生成用于大语言模型处理的 Markdown 格式和分块文本；IOC 提取生成针对文件路径、注册表键和命令行指示器的结构化 JSON 数据；基于规则的 IOC 分析对提取的值进行标准化和去重；借助 Neo4j ...

材料

本文使用的材料清单

姓名	公司	目录编号	评论
计算机（CPU）	—	≥ 推荐 4 核及以上	无需 GPU
LangChain	LangChain	≥ 0.1.x	大语言模型编排框架
大语言模型（IOC 提取，单模型模式）	OpenAI	gpt-5.1	在禁用集成投票时用于 IOC 提取（第 2 阶段）。temperature = 0.0；max_workers = 5。访问时间：2025-12-15。
大语言模型（正则表达式生成）	OpenAI	gpt-5.1	用于正则表达式生成（第 5 阶段）。下游验证前 temperature = 0.3。访问时间：2025-12-15。
大语言模型（可扩展性表征）	OpenAI	gpt-5.1	用于代表性结果中报告的 6,000 个 IOC 可扩展性运行。访问时间：2025-12-15。
内存（RAM）	—	≥ 推荐 16 GB 及以上	文档处理所必需
Neo4j	Neo4j, Inc.	≥ 5.x	用于 IOC 标准化的图数据库
Neo4j Python 驱动程序	Neo4j, Inc.	≥ 5.x	Neo4j 的 Python 接口
操作系统	Microsoft / Apple / Linux	Windows、macOS 或 Linux	支持跨平台运行
PDF 解析 — 主要后端	Microsoft	MarkItDown ≥ 0.0.x	第 1 阶段后端；将 PDF/DOCX/HTML/TXT 输入转换为 Markdown。在送入大语言模型处理前，解析输出按 4,000 字符分块。访问时间：2025-12-15。https://github.com/microsoft/markitdown
流水线配置（第 2 阶段 — IOC 提取）	—	参考默认值	单大语言模型模式：temperature = 0.0，max_workers = 5。集成投票模式默认值：每个配置模型重复次数 = 1，最少投票数 = 2。
流水线配置（第 5 阶段 — 正则表达式生成）	—	参考默认值	生成 temperature = 0.3。验证设置：每个 IOC 使用 5 个确定性负样本进行过生成随机测试。迭代边界：max_iterations = 10，debug_loop_cap = 5，discard_validation_cap = 5。
Python	Python 软件基金会	≥ 3.8	必需的运行环境
正则表达式引擎	Python 标准库	re 模块	用于正则表达式的验证和测试
Streamlit	Streamlit Inc.	≥ 1.25	基于网页的用户界面
参考实现源代码	作者 / GitHub | GitHub 仓库		包含 Streamlit 界面、LangChain 流水线、Neo4j 辅助标准化、正则表达式生成、验证工具以及示例配置文件的源代码。获取地址：https://github.com/SOCautomatic/cti-ioc-regex-pipeline。访问时间：2026 年 6 月 11 日。