avulman/adversary-detection-as-code-lab

# Adversary Detection as Code 实验室 该项目模拟了一个小型企业环境，旨在跨主机和网络遥测数据设计、验证并落地检测规则。 其重点不仅在于创建检测规则，更在于构建一个**可复现的检测工程工作流**，该流程由验证、测试和 CI/CD 提供支持。 ## 本项目演示的内容 - 跨**端点和网络遥测**的检测工程 - 使用**结构化测试数据和 PCAP 重放**进行检测验证 - 用于**检测质量保证和部署**的 CI/CD 流水线 - **Splunk (主机)** 和 **Security Onion (网络)** 的集成 - 将检测映射到 **MITRE ATT&CK 技术** - 将检测视为**版本可控、可测试的代码** - ## 为什么这很重要 许多检测工作因缺乏验证和一致性而失败。 该项目通过将检测视为代码来解决这个问题： - 版本可控 - 可测试 - 持续验证 - 通过 CI/CD 部署 目标不仅是检测威胁，还要确保检测规则随着时间的推移保持可靠和可维护。 ## 项目目标 - 在受控实验室中模拟真实的对抗行为 - 从多个来源收集并集中遥测数据 - 开发符合 MITRE ATT&CK 的检测规则 - 使用可复现的测试用例验证检测 - 跟踪覆盖范围并识别检测盲区 - 通过 CI/CD 流水线强制执行结构和质量 ## 快速开始 ### 前置条件 此项目专为**自托管 Windows GitHub Actions Runner** 和一个正常运行的实验室环境设计。 所需组件： - Python 3.11 - Git - Playwright - 用于 Playwright 的 Chromium 浏览器 - Suricata 已安装并可在 `PATH` 中访问 - Splunk Enterprise，且可通过 REST API 访问 - 已配置 Splunk HTTP Event Collector (HEC) 用于测试数据摄入 - 可从 Runner 访问 Security Onion UI ## 工作流设置 该仓库包含三个 GitHub Actions 工作流： 1. `validate` 运行仓库验证、语法验证和检测测试 2. `validate-and-deploy` (用于 Splunk) 验证并将 Splunk 检测部署为告警 3. `validate-and-deploy-securityonion` 通过 UI 自动化验证并部署 Security Onion 检测 ### 重要提示 这些工作流专为**自托管 Windows Runner** 设计，若不对默认的 GitHub 托管 Runner 进行重大修改，将无法正常运行。 ### 安装依赖 py -m pip install -r requirements.txt py -m playwright install chromium ## 遥测数据源 ### 基于主机 (Splunk) - Windows Event Logs - Sysmon - 进程创建和访问事件 - 注册表和命令行活动 ### 基于网络 (Security Onion) - Zeek 连接日志 - Suricata 告警 - 协议和流量元数据 ## 检测生命周期 此项目模拟了完整的检测工程生命周期： 1. 对抗模拟生成遥测数据 2. 网络安全分析师分析告警 3. 检测规则被开发并存储为代码 4. CI/CD 流水线使用测试数据验证检测 5. 验证后的检测被部署回环境中 这为提高检测质量创建了一个持续的反馈循环。 ## 检测验证 每个检测都包含结构化的测试覆盖： ### Splunk - 基于 JSON 的事件固件 (fixtures) - 通过 HEC 注入到测试索引 - 执行查询并进行验证 ### Suricata - 基于 PCAP 的验证 - 针对规则重放流量 - 验证告警生成 ### Sigma - JSON 事件样本 - 根据预期匹配评估规则逻辑 ## CI/CD 流水线 GitHub Actions 流水线强制执行质量并自动化部署： ### 验证流水线 - 仓库结构验证 - 检测语法验证 - Splunk 检测测试 - Suricata PCAP 验证 - Sigma 规则验证 ### 部署流水线 - 通过 API 将 Splunk 检测部署为告警 - 通过 UI 自动化部署 Security Onion 检测（由于免费版本的 API 支持有限，使用 Playwright 实现） ## Security Onion 部署方法 Security Onion 检测使用**基于 Playwright 的 UI 自动化**进行部署。 选择此方法是有意为之，旨在： - 模拟 API 可能受限的真实世界约束 - 展示跨非 API 系统的自动化能力 - 实现完整的生命周期管理（创建/更新/删除） 注意：此方法依赖于 UI 结构，可能需要针对不同版本进行调整。 ## 局限性 - 实验室环境不能完全反映企业级规模 - 检测逻辑已简化，需针对生产环境进行调优 - Security Onion 部署依赖于 UI 自动化 - ATT&CK 覆盖范围目前仅部分完成，正在扩展中 - 检测评分和优先级排序尚未实现 ## 未来改进 - 扩展跨更多战术的 ATT&CK 覆盖范围 - 增加负面测试用例（误报验证） - 引入检测评分/严重性建模 - 改进 Sigma > SIEM 转换工作流 - 增加自动化报告/仪表板 ## 总结 该项目侧重于像成熟的安全团队那样构建检测规则： - 结构化 - 经验证 - 版本可控 - 持续改进 目标不仅是可视性，更是**对检测质量的信心**。

标签：Active Directory, adversary emulation, attack simulation, attack validation, automation, blue team, Cloudflare, cyber range, detection as code, detection engineering, detection lab, DevSecOps, GitHub Actions, host detection, Metaprompt, MITRE ATT&CK, network detection, PCAP replay, PE 加载器, Plaso, Python, security lab, Security Onion, security operations, Suricata, Sysmon, telemetry, Terraform 安全, threat detection, Web报告查看器, Windows security, 上游代理, 后渗透, 无后门, 特征检测, 现代安全运营, 网络安全审计, 自动笔记, 逆向工具