Suliman8/purple-team-detection-as-code

GitHub: Suliman8/purple-team-detection-as-code

一个紫队检测即代码平台,在每次 PR 时自动发起攻击并验证 Sigma 和 Falco 检测规则是否正确触发,将检测质量的回归测试嵌入 CI 流水线。

Stars: 0 | Forks: 0

# 紫队 检测即代码 **一个在每次 Pull Request 时都会自我攻击的自测试安全平台 —— 如果检测效果出现回归,将阻止代码合并。** 作为 **DevOps Advance** 项目组合的项目 3,历时 8 周构建。 ## 核心成果 — 前后覆盖率对比 下面的 MITRE ATT&CK 矩阵展示了我们的检测范围。绿色 = 规则存在 **且** CI 证明其已触发。黄色 = 规则存在,但未经测试。灰色 = 无规则。 ### 第 7 周之前 *5 个经过验证的检测,12 条未经测试的规则。* ![Before — 5 green, 12 yellow](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/59c7eca5d4173646.png) ### 第 7 周之后 *15 个经过验证的检测,7 条未经测试的规则 —— 一周内经过验证的覆盖率增加了两倍,并在一个误报可能被发布到生产环境之前将其拦截。* ![After — 15 green, 7 yellow](https://static.pigsec.cn/wp-content/uploads/repos/2026/05/3047735602173651.png) ## 影响力指标 | 指标 | 最终结果 | |--------|------:| | Sigma 源规则 | **20** | | Falco 运行时规则(生产环境) | **20** | | 覆盖的 MITRE ATT&CK 技术 | **22** | | 其中,**经 CI 验证在实际攻击中触发** | **15** | | 每条规则编译到的 SIEM 方言 | **4** (Elastic EQL, Kibana Lucene, Splunk SPL, Grafana LogQL) | | 每次 PR 在 CI 中自动编译的规则数 | **80** (20 个源规则 × 4 个后端) | | CI 拦截到的与生产环境相关的误报 | **1** (T1053.003 在宿主机级别的 dockerd 上触发) | | 每次 PR 的平均 CI 耗时 | ~3 分钟 (紫队) + ~50秒 (编译门禁) | ## 这个仓库究竟是什么 一个由三个相辅相成的部分组成的**紫队 CI 流水线**: 1. **检测规则**(`rules/` — Sigma + `falco/custom-rules/` — Falco)—— 用于捕获特定攻击者技术的告警。 2. **编译流水线**(`scripts/compile.sh`)—— 将每条 Sigma 规则翻译为四种 SIEM 方言,并在每次 PR 时由 `.github/workflows/rules-ci.yml` 进行验证。 3. **实战攻击与检测门禁**(`.github/workflows/purple-team.yml`)—— 在全新的 GitHub runner 上启动 Falco,在 Docker 容器内运行脚本化的攻击爆发,如果任何预期应触发的规则未触发,或任何不应触发的规则被触发,则**构建失败**。 核心理念:**未经测试的规则比没有规则更危险**(你会*以为*自己受到了保护)。本项目将规则从“我们拥有它”转变为“CI 在每次更改时都证明它有效”。 ## 架构图 (一图胜千言) ``` Developer opens a PR │ ▼ ┌─────────────────────────────────────────┐ │ GitHub Actions (free tier) │ ├─────────────────────────────────────────┤ │ │ │ ┌─ Workflow 1 ──────────────────┐ │ │ │ Rules CI │ │ │ │ ┌── pySigma ──────────┐ │ │ │ │ │ rules/*.yml ─► dist/│ │ │ │ │ │ ├ eql/ │ │ │ │ │ │ ├ lucene/ │ │ │ │ │ │ ├ splunk/ │ │ │ │ │ │ └ loki/ │ │ │ │ │ └─────────────────────┘ │ │ │ │ ┌── falco -V ────────┐ │ │ │ │ │ Lint Falco rules │ │ │ │ │ └────────────────────┘ │ │ │ └───────────────────────────────┘ │ │ │ │ ┌─ Workflow 2 ──────────────────┐ │ │ │ Purple Team │ │ │ │ ┌── Falco on host ─────────┐ │ │ │ │ │ modern_ebpf, our rules, │ │ │ │ │ │ rule_matching=all │ │ │ │ │ └────────────┬─────────────┘ │ │ │ │ ▼ │ │ │ │ ┌── docker run ubuntu ─────┐ │ │ │ │ │ scripted attack burst │ │ │ │ │ │ (whoami, cat /etc/shadow,│ │ │ │ │ │ find id_rsa, base64|sh, │ │ │ │ │ │ ifconfig, useradd ...) │ │ │ │ │ └────────────┬─────────────┘ │ │ │ │ ▼ │ │ │ │ ┌── jq + bash assertion ───┐ │ │ │ │ │ EXPECTED set fired? ✅/❌│ │ │ │ │ │ UNEXPECTED set silent?✅ │ │ │ │ │ └────────────┬─────────────┘ │ │ │ └──────────────┼────────────────┘ │ │ ▼ │ │ ┌─ Sticky PR comment ──────────┐ │ │ │ Markdown coverage table │ │ │ └──────────────────────────────┘ │ │ │ └─────────────────────────────────────────┘ │ ┌───────┴────────┐ ▼ ▼ ✅ merge ❌ blocked ``` ## 8 周构建历程 每周的深入探讨文档存放在 [`docs/`](docs/) 中。 | 周次 | 主题 | 文档 | |------|-------|-----| | 1 | Kubernetes 网络靶场 (kind 集群, NetworkPolicy 隔离, Juice Shop 目标) | [WEEK1.md](docs/WEEK1.md) | | 2 | MITRE Caldera + Sandcat agent + Atomic Red Team 集成 | [WEEK2.md](docs/WEEK2.md) | | 3 | 涵盖顶级 Linux ATT&CK 技术的前 16 条 Sigma + Falco 规则 | [WEEK3.md](docs/WEEK3.md) | | 4 | Sigma → 4 后端编译流水线;通过 Helm 部署实时 Falco DaemonSet | [WEEK4.md](docs/WEEK4.md) | | 5 | GitHub Actions CI — 编译门禁 + 实战攻击与检测门禁 | [WEEK5.md](docs/WEEK5.md) | | 6 | MITRE ATT&CK 覆盖率热力图 (Navigator layer 导出) | [WEEK6.md](docs/WEEK6.md) | | 7 | 盲区分析 + 5 条新规则 + 5 次从黄变绿的转变 | [WEEK7.md](docs/WEEK7.md) | | 8 | 项目组合撰写 (本 README) | [WEEK8.md](docs/WEEK8.md) | ## 如何在本地运行 ### 快速开始 — 两条命令 ``` ./scripts/setup.sh # one-time: installs Falco, jq, pySigma toolchain (uses sudo) ./scripts/demo.sh # any time: compile + live attack & detect + heatmap export ``` `demo.sh` 将会: 1. 将所有 20 条 Sigma 规则编译为 4 种 SIEM 方言(约 10 秒) 2. 在宿主机上启动 Falco,在 `ubuntu:22.04` 容器内运行脚本化的攻击爆发,断言所有预期的规则均已触发(约 30 秒) 3. 将 MITRE ATT&CK 覆盖率热力图导出至 `dist/attack-coverage.json` 它会在退出时清理 Falco(通过 trap),并且可以安全地重复运行。 ### 前置条件 - 已安装 Docker 的 Linux 系统(在 Kali 6.12 / Ubuntu 22.04+ 上测试) - Python 3.11+ - `sudo` 权限(Falco 的 eBPF 探针需要 root 权限) ### 运行各个独立部分(高级) ``` # 仅 compilation pipeline ./scripts/compile.sh # 仅 heatmap 导出(假定 rules/ 已存在) python3 scripts/export-attack-coverage.py # 仅 attack-and-assert(假定 Falco 已在运行,log file 环境变量已设置) FALCO_LOG_FILE=/tmp/falco-demo.log ./scripts/ci-attack-and-assert.sh ``` ### 查看热力图 在 `demo.sh` 运行完毕后,前往 https://mitre-attack.github.io/attack-navigator/ 上传 `dist/attack-coverage.json`(Open Existing Layer → Upload from local),然后按 `E` 键展开子技术。 ## 仓库布局 ``` . ├── rules/ ← 20 Sigma source rules (one per technique) ├── falco/ │ ├── custom-rules/ ← Hand-authored Falco runtime rules │ ├── values.yaml ← Helm config for production cluster │ └── values-ci.yaml ← Helm overrides for CI (legacy ebpf etc) ├── scripts/ │ ├── compile.sh ← Sigma → 4 SIEM backends pipeline │ ├── ci-attack-and-assert.sh ← Attack runner + coverage assertion │ └── export-attack-coverage.py ← Heatmap JSON generator ├── apps/ ← Vulnerable target manifests (Juice Shop) ├── cluster/ ← Namespace, NetworkPolicy, ResourceQuota ├── caldera/ ← MITRE Caldera docker-compose ├── Localstack/ ← Local AWS sandbox for cloud-side rules ├── .github/workflows/ │ ├── rules-ci.yml ← Workflow 1 — compile + lint gate │ └── purple-team.yml ← Workflow 2 — live attack & detect ├── docs/ ← Per-week deep-dive writeups + screenshots ├── requirements.txt ← Pinned pySigma toolchain └── README.md ← This file ``` ## 这个项目教会了我什么 花了八周时间编写检测规则并看着它们在 CI 中失败,这比阅读任何 SOC 教科书让我学到的都多。有三个教训尤为突出: **1. 黄色比灰色更危险。** 一条你写过但从未测试过的规则比没有规则*更糟* —— 当你没有受到保护时,你会*以为*自己已经做好了防护。项目的整个后半段(第 5-7 周)都是在将黄色转变为绿色,因为真正的价值就在这里。 **2. CI 门禁能发现代码审查无法发现的问题。** 同样的规则在经历了一周的手动冒烟测试后都没有出现问题。但在我们扩展 CI 攻击爆发范围的那一刻,T1053.003 在 GHA 宿主机的 `dockerd` 上触发了。这是一个人类审查员永远无法发现的生产级误报 —— 测试环境率先发现了它。CI 门禁本身就是这个项目的核心,其重要性甚至超过了规则本身。 **3. 完美镜像生产环境的 CI 只是个虚荣指标。** 第 5 周紫队工作流的第一次尝试试图完美复现生产环境:kind 集群 + Helm Falco DaemonSet + kubectl exec。它连续**失败了八次**,原因是嵌套容器的内核限制。重新设计后的方案 —— 在 runner 宿主机上运行 Falco,在 `docker run` 容器中执行攻击 —— 在结构上与生产环境不同,但它对**相同的规则测试了相同的系统调用**。CI 不必*成为*生产环境;它只需要*执行*生产环境运行的规则逻辑。理解这一区别花了半天时间,这也是这里最大的一个 CI 经验教训。 ## 许可证 MIT —— 可以将本仓库中的任何内容用于你自己的紫队工作。 ## 作者 **Suliman Khalid Noor** —— 作为 DevOps Advance / DevSecOps 工程项目组合的一部分构建。完整的每周构建历程(包含所有的死胡同、八次 CI 迭代和失败的尝试)记录在 [`docs/WEEK1.md`](docs/WEEK1.md) 到 [`docs/WEEK8.md`](docs/WEEK8.md) 中。
标签:Atomic Red Team, CI/CD安全, Detection-as-Code, DevOps安全, DevSecOps, Docker, Docker镜像, Elastic EQL, Falco, GitHub Actions, Grafana LogQL, Kibana Lucene, Llama, MITRE Caldera, Sigma规则, SOAR, Splunk SPL, TGT, Web截图, 上游代理, 子域名突变, 安全合规, 安全编排与自动化, 安全规则编译, 安全防御评估, 容器安全, 应用安全, 开源框架, 持续集成, 攻防演练, 敏感词过滤, 数据泄露检测, 检测即代码, 目标导入, 紫队, 网络代理, 网络安全, 网络靶场, 自动化攻击, 自动笔记, 误报测试, 请求拦截, 逆向工具, 隐私保护