JpsBookOfLife/aws-detection-engineering-lab

# AWS 检测工程与事件响应实验室 这是一个实战型的、**检测即代码 (detection-as-code)** 实验室，它在 AWS 上构建了云 SOC pipeline，提交映射到 **MITRE ATT&CK** 的版本化检测规则，安全地模拟这些检测旨在捕获的攻击，并通过**事件响应剧本 (incident-response playbooks)**、**威胁狩猎 (threat-hunting)** runbook 以及跨平台的**取证分类 (forensic triage)** 工具形成闭环。 旨在真实还原 **防御性安全分析师 / SOC 检测工程师** 的日常工作： ## 为什么创建此仓库 大多数云安全实验室仅停留在“在控制台中四处点击并截图”的层面。真正的 SOC 工作是**工程化**的：检测规则保存在版本控制系统中，通过自动化部署，针对模拟的对抗行为进行测试，并配有值班分析师在凌晨 3 点确实能够遵循的 runbook。本仓库正是按照这种方式端到端构建的。 | 能力 | 在此处的演示方式 | |---|---| | **检测工程** | 8 个版本化 YAML 格式的检测规则，在 CI 中进行 schema 验证，并映射到 ATT&CK | | **安全自动化 / IaC** | Terraform 搭建整个遥测 pipeline；Python 从 YAML 部署规则 | | **SIEM 运营** | CloudWatch Logs + metric filters + alarms 充当 SIEM；Athena 用于回溯狩猎 | | **对手模拟** | `simulate.py` 生成每个攻击的无害标记版本，以证明检测会触发 | | **威胁狩猎** | 基于假设的 CloudTrail Athena/SQL runbook；`hunt.py` CLI | | **事件响应** | 三个 PICERL 剧本（root 凭据泄露、S3 曝光、凭据滥用） | | **数字取证** | Bash + PowerShell 实时响应收集器，带有完整性哈希的证据清单 | | **脚本广度** | Python、Bash 和 PowerShell — 岗位要求中提到的三种语言 | ## 架构 ``` ┌──────────────────────────────────────────────┐ │ AWS Account │ │ │ API activity ┌────────┴────────┐ logs ┌──────────────────┐ │ (any service) │ CloudTrail │──────────▶│ CloudWatch Logs │ │ │ (multi-region) │ │ (trail group) │ │ └────────┬────────┘ └────────┬─────────┘ │ │ delivers │ metric filters │ ▼ ▼ │ ┌─────────────────┐ ┌──────────────────┐ │ │ S3 (immutable │ │ CloudWatch │ │ │ log archive, │ │ Alarms │ │ │ Object Lock) │ └────────┬─────────┘ │ └────────┬────────┘ │ breach │ │ query ▼ │ ┌────────┴────────┐ ┌──────────────────┐ │ │ Athena │ │ SNS topic │──────┼──▶ Email / Slack / PagerDuty │ (retro hunting) │ │ (alert fan-out) │ │ └─────────────────┘ └──────────────────┘ │ ▲ │ │ ┌──────────────────┐ │ │ │ GuardDuty │──────┼──▶ SNS (managed findings) └─────────────────────┤ (managed detect) │ │ └──────────────────┘ │ └──────────────────────────────────────────────┘ detections/*.yml ──► tooling/deploy_detections.py ──► CloudWatch metric filters + alarms simulate.py ──► generates benign, tagged attack telemetry ──► detections fire ──► SNS ``` **真实 SOC 中至关重要的设计选择** - **不可变的日志归档。** S3 trail bucket 使用版本控制 + Object Lock，因此即使攻击者获得了写权限，也无法悄悄删除审计历史记录（ATT&CK *T1562.008 – Disable/Modify Cloud Logs*）。 - **检测即代码。** 每个告警都是一个可审查的 YAML 文件，而不是手动点击配置的控制台 规则。更改通过 pull request 提交，在 CI 中进行 schema 验证，并以可重现的方式部署。 - **检测伴随测试。** 每条规则都有对应的无害模拟，以便你 可以在依赖它*之前*证明它会触发 — 这相当于检测工程中的单元测试。 - **托管 + 自定义。** GuardDuty 覆盖广泛的、ML 驱动的基线；自定义 YAML 检测覆盖经过调优的 SOC 所关注的特定、高信号行为。 ## 检测目录 所有规则都以 YAML 格式保存在 [`detections/`](detections/) 中，并映射到 MITRE ATT&CK。 | ID | 检测 | 战术 | 技术 | 严重性 | |----|-----------|--------|-----------|----------| | `DET-001` | Root 账户使用 | 权限提升 | [T1078.004](https://attack.mitre.org/techniques/T1078/004/) Valid Accounts: Cloud | 严重 | | `DET-002` | CloudTrail 禁用 / 删除 | 防御规避 | [T1562.008](https://attack.mitre.org/techniques/T1562/008/) Disable Cloud Logs | 严重 | | `DET-003` | 未使用 MFA 的控制台登录 | 初始访问 | [T1078.004](https://attack.mitre.org/techniques/T1078/004/) Valid Accounts: Cloud | 高 | | `DET-004` | 控制台登录暴力破解 | 凭据访问 | [T1110](https://attack.mitre.org/techniques/T1110/) Brute Force | 高 | | `DET-005` | S3 存储桶设为公开 | 数据泄露 | [T1530](https://attack.mitre.org/techniques/T1530/) Data from Cloud Storage | 高 | | `DET-006` | IAM 权限提升（附加策略） | 权限提升 | [T1098](https://attack.mitre.org/techniques/T1098/) Account Manipulation | 高 | | `DET-007` | 安全组开放至 0.0.0.0/0 | 持久化 / 横向移动 | [T1562.007](https://attack.mitre.org/techniques/T1562/007/) Disable Cloud Firewall | 中 | | `DET-008` | 来自新区域的访问密钥活动 | 防御规避 | [T1535](https://attack.mitre.org/techniques/T1535/) Unused/Unsupported Cloud Regions | 中 | 针对 ATT&CK Cloud 矩阵的可视化覆盖率：[`docs/attack-coverage.md`](docs/attack-coverage.md)。 ## 仓库结构 ``` aws-detection-engineering-lab/ ├── terraform/ # IaC: CloudTrail, S3 (Object Lock), CloudWatch, SNS, GuardDuty, Athena ├── detections/ # Detection-as-code: one ATT&CK-mapped YAML rule per file │ └── schema/ # JSON Schema the rules are validated against ├── tooling/ # Python: deploy detections, simulate attacks, hunt CLI ├── forensics/ # Live-response triage collectors (Bash + PowerShell) ├── playbooks/ # Incident-response runbooks (PICERL) ├── hunts/ # Hypothesis-driven threat-hunting runbooks (Athena SQL) ├── tests/ # pytest: rule schema + ATT&CK mapping validation ├── docs/ # Architecture, ATT&CK coverage, threat model, detection dev lifecycle └── .github/workflows/ # CI: validate rules, lint scripts, run tests ``` ## 快速开始 ``` # 0. 前提条件：terraform >= 1.5, python >= 3.9, 为 LAB 账户配置的 awscli python3 -m venv .venv && source .venv/bin/activate pip install -r tooling/requirements.txt # 1. 搭建 telemetry pipeline cd terraform terraform init terraform apply -var="alert_email=you@example.com" # confirm the SNS subscription email # 2. 将 detections 从 YAML 部署到 CloudWatch cd .. python tooling/deploy_detections.py --detections-dir detections/ --apply # 3. 通过模拟攻击（良性）来证明 detections 有效 python tooling/simulate.py --scenario root-usage python tooling/simulate.py --scenario cloudtrail-tamper python tooling/simulate.py --all # you should receive SNS alerts for each # 4. 跨历史活动进行 Hunt python tooling/hunt.py --hunt stale-access-keys --days 30 # 5. 全部销毁 cd terraform && terraform destroy ``` 无需任何 AWS 账户即可验证仓库： ``` pip install -r tooling/requirements.txt python tooling/deploy_detections.py --detections-dir detections/ --dry-run # renders, no AWS calls pytest -q # schema + mapping tests ``` ## 各部分展示的能力（面向审阅者 / 招聘经理） - **[`terraform/`](terraform/)** — 我能够*掌控基础设施*：检测 pipeline 是 可重现的、经过代码审查的，并且是可销毁的，而不是一堆手动修改控制台的产物。 - **[`detections/`](detections/)** — 我将告警视为一种**产品**：每个检测 都有负责人、严重性、ATT&CK 映射、调优说明和已知的误报。 - **[`tooling/deploy_detections.py`](tooling/deploy_detections.py)** — 检测内容 与其运行的平台解耦；相同的 YAML 可以通过不同的后端适配 Splunk/Sentinel。 - **[`tooling/simulate.py`](tooling/simulate.py)** — 我针对真实的 对手行为验证检测，而不是指望它们能起作用。 - **[`forensics/`](forensics/)** — 当告警演变为事件时，我可以在 Linux 和 Windows **两者**上提取主机证据，并具备无懈可击的、经过哈希处理的监管链。 - **[`playbooks/`](playbooks/)** & **[`hunts/`](hunts/)** — 我不仅能发出告警，还能进行响应和狩猎。 ## 路线图 - [ ] Sigma 规则导出，使检测规则能够移植到 Splunk / Elastic / Sentinel - [ ] 用于多账户 (AWS Organizations) trail 聚合的 Terraform 模块 - [ ] 从 YAML 自动生成检测覆盖率报告并导入 ATT&CK Navigator 层 - [ ] 添加 EKS/Kubernetes 审计日志检测 ## 免责声明 这是一个个人学习实验室。请仅在你拥有并获得授权进行测试的 AWS 账户中运行它。 这些模拟是刻意设计为非破坏性的；请勿将此工具用于未经书面授权测试的系统。 **作者：** Jan Paul Sanchez Sierra — 作为云检测与响应工作的作品集项目构建。 欢迎反馈和 PR。

标签：AI合规, 安全规则引擎, 应用安全, 逆向工具