researchartifact-oss/Evolution-of-Log-Based-Detection-Rules
GitHub: researchartifact-oss/Evolution-of-Log-Based-Detection-Rules
该研究工件提供了一套完整的 pipeline，用于分析 Sigma 和 Splunk Security Content 检测规则的历史演进过程，通过中间表示、结构对齐和 LLM 标注揭示规则变更模式与意图。
Stars: 0 | Forks: 0
# 基于日志的检测规则的演进
双盲评审的研究工件
## 环境
- Python: 3.14.2
- OS: 在 macOS 上经过测试
- 包管理器: pip
## 数据
大文件（规则仓库包和生成的 pipeline 输出）托管在 Google Drive 上：
**[https://drive.google.com/drive/folders/1jdDMVvuRV3cT0WwRK91-R-AHfpUxXvzU?usp=sharing](https://drive.google.com/drive/folders/1jdDMVvuRV3cT0WwRK91-R-AHfpUxXvzU?usp=sharing)**
对于工件评审，我们建议使用 Google Drive 上预先构建的 pipeline 输出，而不是重新运行 `data_prep/build_src/`。特别是：
- 使用上传的 `build_data/` 作为复现的起点。
- 同时下载后续阶段的输出 `ir_data/`、`align_data/` 和 `llm_data/`。
- 仅当您特别想要检查或部分重建原始谱系构建 pipeline 时，才运行 `build_src/`。
## 设置说明
### 1. Python 环境
```
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
```
### 2. 下载预先构建的 pipeline 数据（推荐）
为了最清晰的工件评审路径，请从 [Google Drive 文件夹](https://drive.google.com/drive/folders/1jdDMVvuRV3cT0WwRK91-R-AHfpUxXvzU?usp=sharing)下载以下文件夹并将它们放置在 `data_prep/` 下：
| Google Drive 文件夹 | 本地路径 | 评审是否必需？ | 备注 |
|---|---|---|---|
| `build_data/` | `data_prep/build_data/` | 是 | 推荐的起点 |
| `ir_data/` | `data_prep/ir_data/` | 是 | 后续 pipeline 输出 |
| `align_data/` | `data_prep/align_data/` | 是 | 后续 pipeline 输出 |
| `llm_data/` | `data_prep/llm_data/` | 是 | 必须下载；请勿重新生成 |
有了这些文件夹，您可以直接进入 `analysis/scripts/` 中的 notebooks 并复现论文输出，而无需重新构建 data-prep pipeline。
### 3. 运行 IR pipeline (`ir_src/`)
将每个规则版本中的 SPL 解析为 Predicate-Graph IR (PG-IR)，供所有下游分析使用。
**输入：** `data_prep/build_data/rule_versions_{repo}.jsonl`
```
cd data_prep/ir_src
./run_pipeline.sh # both repos
./run_pipeline.sh sigma # sigma only
./run_pipeline.sh ssc # ssc only
```
输出结果位于 `data_prep/ir_data/` 中：
| 阶段 | 脚本 | 输出 |
|---|---|---|
| 1 | `build_unified_ir` | `unified_ir_{repo}.jsonl` — SPL 被解析为 Unified IR |
| 2 | `build_pgir_from_ir` | `pgir_{repo}.jsonl` — Unified IR 提升为 Predicate-Graph IR |
| 3 | `split_pgir_by_predicate_graph` | `pgir_{repo}_empty.jsonl` / `pgir_{repo}_nonempty.jsonl` |
### 4. 运行对齐 pipeline (`align_src/`)
计算连续规则版本之间的成对对齐和编辑距离轨迹。
**输入：** `data_prep/ir_data/pgir_{repo}_nonempty.jsonl`
```
cd data_prep/align_src
./run_pipeline.sh # both repos
./run_pipeline.sh sigma # sigma only
./run_pipeline.sh ssc # ssc only
```
输出结果位于 `data_prep/align_data/` 中：
| 输出 | 描述 |
|---|---|
| `all_steps_{repo}.jsonl` | 每个相邻版本对占一行 — 对齐、距离细分、更改计数 |
| `all_trajectories_{repo}.jsonl` | 每个谱系占一行 — 累积距离、冲击率、还原计数、端点相似度 |
### 5. LLM 标注 (`llm_src/`)
为连续的规则版本对生成提示，并收集用于意图标注的结构化 LLM 响应。
**输入：** `data_prep/build_data/rule_versions_{repo}.jsonl`
| 脚本 | 目的 |
|---|---|
| `prepare_llm_prompts.py` | 为所有非 noop 对生成提示 → `llm_data/{repo}/prompts.jsonl` |
| `prepare_llm_prompts_from_pair_manifest.py` | 为明确策划的配对列表生成提示 |
| `run_llm.py` | 将提示发送到兼容 OpenAI 的 API → `llm_data/{repo}/results.jsonl` |
| `make_entries_from_audit.py` | 从审计结果构建配对清单，用于定向重新运行 |
| `structural_test_labels.py` | 辅助工具：在不使用 LLM 的情况下派生结构化真值标签（在分析中使用） |
### 6. 可选：恢复规则快照并运行构建 pipeline (`build_src/`)
正常的工件评审不需要此步骤。我们建议评审者使用 Google Drive 上传的 `data_prep/build_data/`，并将 `build_src/` 视为可选的检查或重建路径。
上游规则仓库（SigmaHQ/sigma 和 splunk/security_content）未存储在此仓库中。它们以 git bundle 文件的形式在 Google Drive 上提供，保留了截至本研究中使用的 2026 年 4 月 10 日快照的完整提交历史。
**从 [Google Drive 文件夹](https://drive.google.com/drive/folders/1jdDMVvuRV3cT0WwRK91-R-AHfpUxXvzU?usp=sharing)下载 bundle** 并将它们放置在 `rules_repo/` 中：
```
rules_repo/sigma.bundle
rules_repo/splunk_sc.bundle
```
然后从 bundle 克隆：
```
git clone rules_repo/sigma.bundle rules_repo/sigma -b snapshot
git clone rules_repo/splunk_sc.bundle rules_repo/splunk_sc -b snapshot
```
这将为您提供两个本地 git 仓库，其中包含 pipeline 运行所依据的确切提交历史：
| 仓库 | 快照提交 | 日期 |
|---|---|---|
| `rules_repo/sigma` | `d4d12bdd` | 2026-04-01 (截至 2026-04-10 的 HEAD + 17 个分支) |
| `rules_repo/splunk_sc` | `aa672c674` | 2026-04-09 (截至 2026-04-10 的 HEAD + 678 个分支) |
```
cd data_prep/build_src
./run_pipeline.sh # run both repositories
./run_pipeline.sh sigma # sigma only
./run_pipeline.sh ssc # splunk security content only
```
输出结果位于 `data_prep/build_data/` 中。这五个阶段分别是：
1. `build_rename_metadata` -> `lineage_metadata_raw_{repo}.json`
2. `build_semantic_lineage_metadata` -> `lineage_metadata_{repo}.json`
3. `merge_non_head_lineages` -> `lineage_metadata_final_{repo}.json`
4. `build_lineage_spl_per_rule` -> `rule_lineages_{repo}/`
5. `build_rule_versions` -> `rule_versions_{repo}.jsonl`
## 复现论文结果
Google Drive 文件夹包含所有 pipeline 阶段的预先构建输出。为了忠实地 1:1 复现论文中报告的结果，**请从 Google Drive 下载预先构建的数据**，并在运行任何分析之前将文件放置在相应的目录下：
| Google Drive 文件夹 | 本地路径 | 可以从头复现吗？ |
|---|---|---|
| `build_data/` | `data_prep/build_data/` | 基本可以 — 参见下文说明 |
| `ir_data/` | `data_prep/ir_data/` | 是，可从提供的 `build_data/` 复现 |
| `align_data/` | `data_prep/align_data/` | 是，可从提供的 `build_data/` 复现 |
| `llm_data/` | `data_prep/llm_data/` | 否 — 请使用提供的文件 |
对于工件评审，这是推荐的路径：直接使用提供的 `build_data/`、`ir_data/`、`align_data/` 和 `llm_data/`。
如果您希望自己重新运行 `ir_src/` 和 `align_src/`，请从提供的 `build_data/` 开始，结果将与论文中报告的一致。
**为什么如果从头开始重新运行，`build_data/` 可能会略有不同：** 这些 bundle 是于 2026 年 4 月 30 日（即原始 4 月 10 日子模块快照之后的 20 天）从全新的 GitHub 克隆创建的。在该窗口期间，GitHub 上的 `splunk/security_content` 仓库中删除了 9 个短暂的修复/功能分支。这些分支为原始 pipeline 运行贡献了 9 个独特的提交（总计 1,722 条提交-规则记录，由一次广泛的格式化提交主导），这些提交现已无法恢复。结构性谱系输出（`lineage_metadata_final_ssc.json`，3,956 个条目）未受影响；只有 `rule_versions_ssc.jsonl` 的版本记录出现了小幅减少（约 0.8%）。
## 分析
论文中报告的所有图表均可通过 `analysis/scripts/` 中的 Jupyter notebooks 进行复现。每个 notebook 都是独立的，可直接从上述预构建的数据目录中读取。
| Notebook | 论文输出 |
|---|---|
| `dataset.ipynb` | 表 1 — 数据集概览（谱系计数、活跃/已删除、提交统计） |
| `temporal.ipynb` | 图 2、图 3、表 2 — 季度规则创建与修订量、队列堆叠 |
| `structural.ipynb` | 图 4、图 5、表 4、表 5 — 结构操作频率与共现 |
| `llm.ipynb` | 表 9、7、8 - LLM 标注针对 PG-IR 结构信号的验证及意图分布 |
标签：AMSI绕过, Cutter, DLL 劫持, LLM, NoSQL, Petitpotam, pip, Predicate-Graph IR, Python, SPL, Unmanaged PE, 代码分析, 代码示例, 凭证管理, 大语言模型, 威胁检测, 学术研究, 安全信息与事件管理, 安全规则演化, 序列对齐, 搜索引擎爬取, 数据分析, 数据管道, 无后门, 日志检测, 检测规则, 网络安全, 网络安全研究, 网络资产发现, 规则生命周期管理, 规则评估, 软件工程, 逆向工具, 隐私保护