jadhavyash/detection-as-code

# Detection-as-Code 流水线 像管理软件一样管理 Sigma 检测规则：版本控制、同行评审、单元测试，并通过 CI/CD 进行部署。 规则只需使用厂商中立的 [Sigma](https://sigmahq.io/) 编写一次，即可编译为后端原生查询（此处为 Splunk SPL，通过修改配置即可轻松支持 Sentinel KQL 和 Elastic）。任何未通过测试套件的内容都无法合并到 `main` 分支。 ## 为什么需要它 大多数检测仓库只是存放规则的文件夹。这只是版本控制，而不是 detection-as-code。真正的差距在于规则*周围*发生的一切： | 实践 | 实现方式 | |---|---| | **版本控制** | Git，每个文件一个规则，稳定的 UUID ID | | **同行评审** | `CODEOWNERS` + 分支保护 + 强制要求包含调优影响说明的 PR 模板 | | **自动化测试** | `pytest` — 针对样本事件测试 schema、metadata、ATT&CK 映射以及检测*逻辑* | | **CI/CD 部署** | GitHub Actions：在 PR 时验证，在合并时编译并发布 | 测试套件才是最关键的部分。一个符合语法的 YAML 规则仍然可能存在隐性问题。 ## 它解决的问题 一次“调优”提交为了减少误报而缩小了规则的范围，却悄悄抹杀了真正的检测覆盖。直到发生安全事件时才会有人注意到。 这里的每个规则都附带了真阳性 (TP) 和假阳性 (FP) 样本事件。如果某次改动导致原本能检测到的行为无法再被检测到，测试套件就会失败： ``` $ pytest tests/ -q FAILED tests/test_rules.py::test_detection_logic[t1003_lsass_dump] E AssertionError: MISSED detection — rule failed to match: E {'TargetImage': '...\\lsass.exe', 'GrantedAccess': '0x1410', ...} ``` 该回归问题是由于从 LSASS 规则中删除了单个访问掩码引起的。在合并之前的 CI 阶段被成功拦截。 ## 目录结构 ``` ├── rules/ │ └── windows/ │ ├── proc_injection_createremotethread_t1055.yml │ ├── scheduled_task_creation_t1053.yml │ ├── lsass_credential_dump_t1003.yml │ ├── powershell_encoded_command_t1059.yml │ └── pass_the_hash_ntlm_t1550.yml ├── tests/ │ ├── test_rules.py # validation + logic test suite │ ├── sigma_eval.py # Sigma detection evaluator │ └── testdata/ # TP/FP samples per rule ├── .github/ │ ├── workflows/ │ │ ├── validate.yml # runs on every PR │ │ └── deploy.yml # compiles + ships on merge to main │ ├── CODEOWNERS │ └── pull_request_template.md └── requirements.txt ``` ## 测试的约束范围 | 测试项 | 拦截的问题 | |---|---| | `test_rule_parses` | Sigma 语法错误 | | `test_required_metadata` | 缺失描述、参考信息或记录在案的误报 | | `test_valid_uuid` / `test_unique_ids` | 重复或格式错误的规则 ID | | `test_mitre_mapping` | 没有 ATT&CK 技术的规则 — 无法追踪覆盖范围 | | `test_converts_to_splunk` | 有效 YAML 但无法编译为 SPL 的规则 | | `test_detection_logic` | **漏报和误报** | | `test_every_rule_has_testdata` | 没有附带测试就发布的规则 | ### 关于评估器 pySigma 负责将规则转换为查询；它并不包含评估引擎。要测试检测*逻辑*，就必须自行编写一个评估器 —— `tests/sigma_eval.py` 实现了这些规则所用到的 Sigma 规范子集：`contains` / `startswith` / `endswith` / `re` 修饰符、列表即 OR 的语义，以及布尔条件表达式。 ## 本地运行 ``` pip install -r requirements.txt pytest tests/ -v # full suite yamllint rules/ # style sigma check rules/ # Sigma validation # 编译为 Splunk SPL sigma convert -t splunk -p splunk_windows rules/ ``` 示例输出： ``` TargetImage="*\\lsass.exe" GrantedAccess IN ("0x1010", "0x1410", "0x143a") NOT SourceImage="C:\\Program Files\\Windows Defender\\*" ``` ## 覆盖范围 | 规则 | 技术 | 严重程度 | 日志来源 | |---|---|---|---| | 通过 CreateRemoteThread 进行进程注入 | [T1055](https://attack.mitre.org/techniques/T1055/) | 高危 | Sysmon EID 8 | | 可疑的计划任务创建 | [T1053.005](https://attack.mitre.org/techniques/T1053/005/) | 中危 | Sysmon EID 1 | | LSASS 内存访问 | [T1003.001](https://attack.mitre.org/techniques/T1003/001/) | 严重 | Sysmon EID 10 | | PowerShell 编码命令 | [T1059.001](https://attack.mitre.org/techniques/T1059/001/) | 高危 | Sysmon EID 1 | | 通过 NTLM 进行 Pass-the-Hash | [T1550.002](https://attack.mitre.org/techniques/T1550/002/) | 高危 | Security EID 4624 | ## 添加规则 1. 创建分支：`git checkout -b detection/t1234-technique-name` 2. 在 `rules//` 中编写规则 3. 在 `tests/testdata/` 中添加 TP/FP 样本 4. 运行 `pytest tests/` 直到测试通过 5. 发起 PR —— 模板要求填写调优影响说明 6. CI 进行校验；代码所有者进行审查；合并操作会触发部署 ## 路线图 - [ ] 使用 [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) 验证实时遥测数据的检测结果 - [ ] 添加 Sentinel KQL 和 Elastic 后端（仅需更改配置） - [ ] 在每次构建时根据规则标签生成 ATT&CK Navigator 层 - [ ] 检测健康度指标：随时间推移监控每个规则的警报量和误报率 - [ ] macOS 和 Linux 规则覆盖

标签：Detection-as-Code, Sigma规则, 安全规则引擎, 安全运营, 扫描框架, 目标导入, 逆向工具