ELSATOAH/detkit

# detkit [](https://github.com/ELSATOAH/detkit/actions/workflows/ci.yml) [](https://pypi.org/project/detkit-cli/) [](https://pypi.org/project/detkit-cli/) [](https://github.com/ELSATOAH/detkit/blob/main/LICENSE) 为你的 Sigma 检测规则提供单元测试。编写一条规则，添加几个示例日志事件，detkit 就能告诉你它是否在应当触发的事件上正常触发，并在不该触发的事件上保持静默。将它接入 CI，出现故障的检测规则会直接导致 pull request 失败，而不会在生产环境中悄然失效。 可以把它想象成 `dbt test`，只不过是为检测规则量身定制的。  ## 安装说明 ``` pipx install detkit-cli # installs the `detkit` command # 或从源码获取最新版本： pipx install git+https://github.com/ELSATOAH/detkit.git ``` 然后： ``` detkit init # drops a starter rule, its test, and a CI workflow detkit test rules # green on the first run ``` ## 工作原理 你的规则就是标准的 [Sigma](https://sigmahq.io/)。在旁边放置一个 `.test.yml` 文件，列出示例事件以及你的预期结果： ``` # whoami_execution.test.yml tests: - name: fires on whoami event: { EventID: 4688, CommandLine: "cmd /c whoami /all", User: "alice" } expect: match - name: not for SYSTEM event: { EventID: 4688, CommandLine: "whoami", User: "SYSTEM" } expect: no_match ``` `detkit test` 会针对其事件运行每一条规则，如果有任何预期结果不匹配，就会以非零状态退出。核心思想就是这么简单： ``` $ detkit test rules . process_exec.yml :: fires on the encoded command x process_exec.yml :: ignores the admin allowlist (rule fired, expected no_match) 1 passed, 1 failed, 0 rule(s) without tests ``` `detkit validate` 会执行更快的结构性检查：确认必填字段是否存在，以及条件语句中是否仅引用了实际存在的标识符。 ## 在 CI 中 将以下配置放入你的规则仓库，任何破坏检测规则的 PR 都会在合并前被拦截： ``` # .github/workflows/detections.yml name: Detections on: [pull_request] jobs: detkit: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: ELSATOAH/detkit@v0 with: path: rules ``` ## pre-commit 更倾向于在提交之前就发现问题？请将 detkit 添加到你的 [pre-commit](https://pre-commit.com) 配置中： ``` # .pre-commit-config.yaml repos: - repo: https://github.com/ELSATOAH/detkit rev: v0.1.3 hooks: - id: detkit-test args: [rules] # path to your rules ``` 还提供了一个 `detkit-validate` 钩子，用于执行轻量级的结构性检查。 ## 覆盖率 当规则数量超过一定规模后，你会希望了解自己*未*覆盖的内容。`detkit docs` 会构建一个独立的 HTML 页面：其中包含所有规则的目录，以及一个 MITRE ATT&CK 热力图，直观展示你检测到了哪些技术、测试了哪些技术，以及还存在哪些空白。 ``` detkit docs rules -o coverage.html ``` 绿色表示有已测试规则覆盖的技术，琥珀色表示有规则但未进行测试的技术，暗淡的单元格则代表空白领域。这是一个不包含任何外部资源的单文件，因此你可以将其提交到仓库或直接发布到 GitHub Pages。 `detkit navigator` 会将相同的覆盖率数据导出为 [MITRE ATT&CK Navigator](https://mitre-attack.github.io/attack-navigator/) 图层，因此你可以将其直接导入你的团队已经在使用的工具中： ``` detkit navigator rules -o coverage.json # 然后选择 Open Existing Layer -> Upload at the Navigator ``` ## 处理范围 detkit 会在本地运行你的规则。无需 SIEM、无需提供凭证，任何数据都不会离开你的本地计算机或 CI runner。我曾在 SigmaHQ 仓库中对每一条规则进行了测试，大约 91% 的规则仅使用了它目前支持的功能：`contains`、`startswith`、`endswith`、`re`、值通配符（`*` 和 `?`）、`|cidr`、嵌套/点分字段（`DeviceDetail.deviceId`）、关键字列表，以及 `X of` / `all of` 条件。 它不会对剩余部分进行猜测。如果某条规则使用了 detkit 暂时无法评估的功能（例如 `base64`/`windash` 修饰符或对象数组），`test` 和 `validate` 会输出一条指明该功能的 WARN（警告）信息，而不是返回一个可能存在错误的答案。一个悄然输出错误结果的检测工具，比没有工具更糟糕。 ## 缘起 如今，检测规则都已经托管在 Git 中，但软件工程中习以为常的测试习惯却并未随之普及。多年前，dbt 已经为数据模型解决了这个问题；Sigma 规则理应享受同等的待遇。此外，它被设计为在本地运行是有意为之的，因为安全日志这种敏感数据，你绝不能仅仅为了验证一条规则就随意交给别人的云端服务。 ## 路线图 - `base64`/`windash` 修饰符和对象数组（即目前会发出警告的功能），未来可能通过 [pySigma](https://github.com/SigmaHQ/pySigma) 提供支持。 - `detkit generate`：通过纯英文描述自动起草规则及其测试。测试将作为配套生成，而不是事后补充。 - 字段映射，以便同一条规则可以根据多种日志 schema 进行检验。 - 未来将为需要共享运行记录和历史记录的团队提供托管方案。CLI 将保持免费。 ## 状态 处于早期阶段，但核心功能已完全可用并附带测试（`python3 tests/test_evaluator.py`）。源代码中较为粗糙的部分已用 `# ponytail:` 注释进行了标记。欢迎提交 Issue 和 PR。 MIT。

标签：Python, Sigma规则, URL发现, 安全检测, 无后门, 目标导入, 逆向工具