Azure Sentinel 检测工程

检测工程基于我运营的一个实时 Microsoft Sentinel 和 Defender XDR 环境。九条自定义分析规则跨越三个平面，每条规则均映射到 MITRE ATT&CK 并经过端到端验证：受控操作触发规则，规则生成事件，事件经过调查和记录。其中七条监控 Azure 控制平面（AzureActivity），包括一条多阶段关联规则和一条基于 ARG 的内容规则；一条监控端点（Defender for Endpoint），通过 Defender 漏洞管理为狩猎库提供数据；一条监控身份（Entra ID SigninLogs）。所有规则通过同一条 PR 门控流水线部署。

一个我端到端运营的实时单租户环境。所有截图中的租户和订阅标识符以及任何个人身份信息均已隐去。

数字均可追溯：覆盖率见 ATT&CK 层，验证结果见 RESULTS.md。本仓库刻意不设误报率徽章：单租户环境无法产生有意义的误报率，因此仓库报告的是对真实良性批次的实测误触发次数，而非编造的百分比（metrics.yaml 中有完整说明）。

---

快速开始

在 fork 上运行检测单元测试，无需 Azure。 每条规则的真实 KQL 在本地 Kusto 模拟器中针对合成测试数据运行，因此无需我的租户即可验证检测逻辑：

git clone https://github.com/ibondarenko1/azure-sentinel-detection-engineering
cd azure-sentinel-detection-engineering
docker run -d --rm -p 8080:8080 -e ACCEPT_EULA=Y mcr.microsoft.com/azuredataexplorer/kustainer-linux:latest
pip install pyyaml
python tests/run-detection-tests.py

这正是 CI 在每个拉取请求上运行的检查（detection-tests）：它断言每条规则在恶意测试数据上触发，在良性数据上保持静默。validation/ 中的实时测试平台更进一步，在租户中驱动真实的良性批处理和攻击批处理，并测量真阳性和误触发，但这需要您自己的 Azure 订阅和 az login（见 validation/README），因此不属于“本地”。部署流水线：docs/03。贡献规则：CONTRIBUTING。

为何存在

只有能展示规则实际触发，检测才可信。本仓库在三个平面上闭环：规则逻辑、受控触发、生成的事件、调查和 MITRE 映射。它超越了单事件规则，包含了多阶段关联（先授权再部署）和一条感知内容的规则，该规则将 Azure Resource Graph 的资源状态与变更事件关联。它是针对真实遥测（而非合成样本）的 Sentinel 分析规则、KQL 和事件响应。

检测即代码

规则并非通过门户手动点击创建。它们是由 PR 门控流水线部署的版本化 YAML。修改检测意味着发起拉取请求；CI 进行验证，审阅者批准，合并到 main 后通过 OIDC（无存储密钥） 以幂等方式按规则 GUID（API 2025-09-01）部署到 Sentinel。

flowchart LR
  D[编辑规则 YAML] --> PR[拉取请求] --> V[CI 验证] -->|审阅| M[合并到 main] --> CD[OIDC 部署] --> S[Sentinel sc200-ws]

• 唯一真理来源：detections/rules/*.yaml · 流水线：.github/workflows/deploy-detections.yml · 部署器/验证器：cicd/ · 详情：docs/03-cicd.md

一个真实的变更完整走过了该流程：PR #1 收紧了 DET-001 的阈值（从 10 降至 8）；CI 验证通过，合并后部署到实时 sc200-ws 规则。正是“规则通过已审阅的 PR 自动从 git 部署”这一步，区分了检测工程师与仅完成课程的分析师。

架构

flowchart LR
  subgraph 数据源
    A[Microsoft Defender XDR<br/>邮件 · 端点]
    B[Azure 订阅<br/>活动日志]
    C[Entra ID<br/>登录]
  end
  A --> W[Log Analytics 工作区<br/>sc200-ws]
  B --> W
  C --> W
  W --> R[9 条计划<br/>分析规则]
  R --> I[事件]
  I --> V[调查<br/>+ MITRE 映射]

检测目录

ID	检测	严重性	MITRE 战术	技术
DET-001	活动日志操作失败峰值	中等	发现	T1087 账户发现
DET-002	网络安全组规则被修改	中等	防御规避	T1562 削弱防御
DET-003	RBAC 角色分配变更	中等	权限提升 / 持久化	T1098 账户操纵
DET-004	批量资源删除	高	影响	T1485 数据破坏
DET-005	非所有者进行可疑资源部署	中等	持久化	T1098 账户操纵
DET-006	LSASS 凭据访问（端点）	高	凭据访问	T1003.001 LSASS 内存
DET-007	权限授予后跟随部署（关联）	高	权限提升 / 持久化	T1098 账户操纵
DET-008	多次失败后成功登录（身份）	中等	凭据访问 / 初始访问	T1110 暴力破解, T1078 有效账户
DET-009	NSG 规则变更使入站来自 Any（ARG 内容）	高	防御规避	T1562.007 禁用/修改云防火墙

结果

每条检测均通过受控、可自动撤销的管理操作触发，并生成了真实事件：

工作区当前运行状态：10 条分析规则已启用，4 个活动数据连接器，1 条自动化规则，实时数据持续流入。已启用的 10 条规则包括本目录中的 9 条自定义 [DET] 计划规则，外加 Microsoft 内置的 Fusion 规则（高级多阶段攻击检测，默认开启，并非此处编写）；本文档其他处提及的 9 条仅统计自定义规则。