NikolasBielski/Adversarial-Detection-Engineering-Framework

# 对抗性检测工程 (ADE) 框架 [](https://github.com/NikolasBielski) [](https://github.com/NikolasBielski/Adversarial-Detection-Engineering-Framework/commits/main) [](https://github.com/NikolasBielski/Adversarial-Detection-Engineering-Framework/blob/main/LICENSE) **通过在威胁行为者滥用检测逻辑之前理解其失效方式，从而抢占先机，解决漏报问题。** 访问网站：[https://adeframework.org/](https://adeframework.org/) ## 什么是 ADE？ 对抗性检测工程 是一门关于**检测规则中漏报**推理的学科。ADE 框架提供了**检测逻辑缺陷**的现代开源形式化定义——即检测规则*意图*检测的内容与*实际*检测的内容之间的不匹配。 ### ADE 的优势 检测工程师无需等待现实世界中的漏报，而是可以主动提出： 这种对抗性的推理思路反映了威胁行为者如何滥用检测逻辑中的弱点。 ## 核心功能 - ✅ **识别可复现的检测逻辑缺陷**并将其映射到正式的 ADE 类别 - ✅ **将攻击者的心智模型嵌入**到检测逻辑的设计和审查中 - ✅ **暴露结构性的弱点**，针对用于搜寻或生产环境 MDR 工具 (SIEM, XDR, EDR) 的规则 - ✅ **为安全团队配备**可操作的检测逻辑缺陷情报 - ✅ **在威胁行为者发现并利用漏报之前**抢占先机 ## ADE 的目的 ADE 的目的不是强求设计上的完美，尽管那是一个理想目标——而是为了提高意识并跟踪局限性，即使是故意的局限性： - ADE 不是要求完美的检测规则；它是为了让漏报的风险可见。 - 许多规则由于范围、信号质量或操作限制而故意包含局限性，这些仍然可以映射到 ADE 缺陷类型，而不一定是“错误的”。 - ADE 提供了一种共享的方式来记录、接受、缓解或补偿整个规则集中的这些风险，而不是孤立地评判单个规则。 ## ADE 与检测逻辑暴露 的联系 - ADE 为检测逻辑缺陷提供了规范的分类法和缺陷类别。 - [DLE](https://github.com/NikolasBielski/Adversarial-Detection-Engineering-Framework/tree/main/dle) 提供了一份公认的、公开披露的带有 ADE 映射的绕过列表。 ## 快速入门 **ADE 新手？** 从这里开始： 1. **[简介](docs/getting-started/introduction.md)** - 了解什么是 ADE 及其重要性 2. **[核心概念](docs/getting-started/core-concepts.md)** - 学习基础术语 3. **[快速入门指南](docs/getting-started/quick-start.md)** - 将 ADE 应用于您的第一个检测规则 4. **[缺陷可能性测试](docs/guides/bug-likelihood-test.md)** - 用于评估规则缺陷的快速检查清单 **准备深入研究？** - [检测逻辑缺陷理论](docs/theory/detection-logic-bugs.md) - 正式基础 - [分类法概述](docs/taxonomy/overview.md) - 所有缺陷类别 - [示例](examples/) - 真实世界示例 ## ADE 检测逻辑缺陷分类法 该框架识别了 **4 个主要类别**和 **13 个子类别**的检测逻辑缺陷： ``` 🌳 ADE1 – Reformatting in Actions ├─ ADE1-01 Substring Manipulation └─ ADE1-02 Normalization Asymmetry 🌳 ADE2 – Omit Alternatives ├─ ADE2-01 Method/Binary ├─ ADE2-02 Versioning ├─ ADE2-03 Locations └─ ADE2-04 File Types 🌳 ADE3 – Context Development ├─ ADE3-01 Process Cloning ├─ ADE3-02 Aggregation Hijacking ├─ ADE3-03 Timing and Scheduling └─ ADE3-04 Event Fragmentation 🌳 ADE4 – Logic Manipulation ├─ ADE4-01 Gate Inversion ├─ ADE4-02 Conjunction Inversion └─ ADE4-03 Incorrect Expression ``` **[→ 探索完整分类法](docs/taxonomy/overview.md)** ## 框架提供的内容 ### 1. 检测逻辑缺陷理论 [正式定义](docs/theory/detection-logic-bugs.md)和理论基础： - 什么构成了检测逻辑缺陷 - 缺陷如何产生漏报 - 范围与检测逻辑之间的关系 - 规则绕过的概念 ### 2. 正式缺陷分类法 具有清晰术语的[综合分类](docs/taxonomy/overview.md)： - 4 个主要类别 - 13 个详细子类别 - 一致的标签系统 (ADE1-01, ADE2-01, 等) - 映射到真实世界的检测规则 ### 3. 真实世界示例 来自生产规则集的具体示例： - **[Sigma](https://github.com/SigmaHQ/sigma)** 检测规则 - **[Microsoft Sentinel](https://github.com/Azure/Azure-Sentinel)** 分析 - **[Elastic Security](https://github.com/elastic/detection-rules)** SIEM & EDR 规则 **示例类别：** - [ADE1 示例](examples/ade1/) - 字符串操作绕过 - [ADE2 示例](examples/ade2/) - 遗漏的替代方案 - [ADE3 示例](examples/ade3/) - 上下文开发 - [ADE4 示例](examples/ade4/) - 逻辑操作 ### 4. 实用工具 - **[缺陷可能性测试](docs/guides/bug-likelihood-test.md)** - 快速预分析检查清单 - **[快速入门指南](docs/getting-started/quick-start.md)** - 分步应用流程 ## ADE 如何补充现有框架 ADE 与现有检测工程实践集成并增强： | 框架 | 重点 | ADE 集成 | |:----------|:------|:----------------| | **[MITRE ATT&CK](https://attack.mitre.org/)** | 攻击技术与战术 | ADE 解释了 ATT&CK 技术检测*为什么*失败 | | **[MITRE CAR](https://car.mitre.org/)** | 检测分析存储库 | ADE 为 CAR 分析提供了缺陷分类法 | | **[检测工程生命周期](https://github.com/Ke0xes/Detection-Engineering-Framework)** | 工程工作流阶段 | ADE 是**改进阶段**的推理框架 | | **Sigma/YARA/KQL** | 规则语法与格式 | ADE 分析跨所有查询语言的*语义逻辑缺陷* | **ADE 的独特价值：** 漏报原因的形式化逻辑级分类 ## 维护者 - [Nikolas Bielski](https://www.linkedin.com/in/nikbielski/) - 框架作者 & 主要维护者 - [Daniel Koifman](https://www.linkedin.com/in/koifman-daniel/) - 联合维护者 ## 贡献 我们欢迎贡献！活跃开发领域包括： ### 高优先级 - **静态分析器开发** - 用于分析检测规则中潜在逻辑缺陷的工具 - 专为 Detection-as-Code CI/CD 管道设计 - IDE 集成支持 - **缺陷库扩展** - 已识别缺陷的精选集合 - 跨平台规则分析 - 供应商规则集评估 - 社区提交的绕过 ### 一般贡献 - 文档改进 - 来自其他供应商/平台的新示例 - 基于新兴技术的分类法优化 - 测试框架和验证工具 **[查看 CONTRIBUTING.md 了解详情 →](CONTRIBUTING.md)** ## 用例 ### 面向检测工程师 1. **部署前审查** - 在部署新规则之前应用 ADE 分类法 2. **系统性改进** - 使用缺陷可能性测试审计现有规则 3. **文档记录** - 当缺陷无法立即修复时，记录已知的局限性 4. **优先级排序** - 将精力集中在高严重性缺陷上 ### 面向安全研究人员 1. **形式化绕过** - 将发现的规避方法映射到 ADE 类别 2. **贡献发现** - 用新的缺陷类别扩展分类法 3. **供应商分析** - 客观评估检测能力 ### 面向红队 1. **现实测试** - 使用 ADE 测试蓝队检测能力 2. **可操作的反馈** - 提供结构化的绕过情报 3. **训练场景** - 开发检测规避演练 ### 面向 SOC/威胁搜寻者 1. **根本原因分析** - 了解攻击为何未被检测到 2. **覆盖范围评估** - 识别监控中的盲点 3. **供应商评估** - 根据 ADE 分类法测试工具 ## 路线图 **计划开发：** - 🔨 **静态分析工具** - 用于 CI/CD 的自动化缺陷检测 - 📚 **扩展缺陷库** - 社区驱动的集合 ## 许可证 | 特征 | 值 | |------------------------------|-------------| | 基于 | [MIT license](https://opensource.org/licenses/MIT) | | 分发 | 是 | | 修改 | 是 | | 私人使用 | 是 | | 商业使用 | 是 | | 责任 | 否 | | 保证 | 否 | | 许可证和版权声明 | 是 | | 作者署名 | 必需 | ## 免责声明 ⚠️ **重要：** 本框架仅用于**防御性安全研究**、检测工程和风险评估。其目的是帮助防御者识别、推理和修复检测逻辑及安全监控系统中的弱点。 用户需自行确保其使用符合所有适用的法律、法规和授权要求。作者和协作者不对因使用本框架而产生的滥用、损害或伤害承担任何责任。 **需要授权：** 在您拥有或运营的环境之外测试检测、系统或控制措施之前，请务必获得明确的书面授权。 **负责任的披露：** 示例是在考虑负责任披露的情况下提供的。检测规则和监控内容通常不属于供应商漏洞披露和漏洞赏金计划的范畴。 **无担保：** 本框架按“原样”提供，不提供任何形式的明示或暗示担保。 ## 联系方式 - GitHub Issues: [报告 Bug 或请求功能](https://github.com/NikolasBielski/Adversarial-Detection-Engineering-Framework/issues) - LinkedIn: [Nikolas Bielski](https://www.linkedin.com/in/nikbielski/) | [Daniel Koifman](https://www.linkedin.com/in/koifman-daniel/)

标签：ADE 框架, DNS 反向解析, DNS 解析, EDR 规则, MDR 工具, SIEM 规则, TGT, XDR 规则, 假阴性, 威胁检测工程, 子域名变形, 安全规则绕过, 安全运营, 对抗性检测工程, 扫描框架, 攻防演练, 检测逻辑漏洞, 漏报分析, 漏洞分类学, 私有化部署, 紫队视角, 网络安全, 蓝队建设, 规则审计, 防御加固, 防御规避, 隐私保护