9个映射到MITRE ATT&CK的KQL检测规则，部署在活动的Microsoft Sentinel + Defender XDR环境（控制平面、端点、身份）上，并配有PR门控的检测即代码流水线（GitHub Actions、OIDC）、SOAR剧本以及SOC 2控制映射。
检测工程基于我运营的一个实时 Microsoft Sentinel 和 Defender XDR 环境。九条自定义分析规则跨越三个平面，每条规则均映射到 MITRE ATT&CK 并经过端到端验证：受控操作触发规则，规则生成事件，事件经过调查和记录。其中七条监控 Azure 控制平面（AzureActivity），包括一条多阶段关联规则和一条基于 ARG 的内容规则；一条监控端点（Defender for Endpoint），通过 Defender 漏洞管理为狩猎库提供数据；一条监控身份（Entra ID SigninLogs）。所有规则通过同一条 PR 门控流水线部署。
一个我端到端运营的实时单租户环境。所有截图中的租户和订阅标识符以及任何个人身份信息均已隐去。
数字均可追溯：覆盖率见 ATT&CK 层，验证结果见 RESULTS.md。本仓库：单租户环境无法产生有意义的误报率，因此仓库报告的是对真实良性批次的实测误触发次数，而非编造的百分比（ 中有完整说明）。
在 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 映射]
每条检测均通过受控、可自动撤销的管理操作触发，并生成了真实事件：
工作区当前运行状态：10 条分析规则已启用，4 个活动数据连接器，1 条自动化规则，实时数据持续流入。已启用的 10 条规则包括本目录中的 9 条自定义 [DET] 计划规则，外加 Microsoft 内置的 Fusion 规则（高级多阶段攻击检测，默认开启，并非此处编写）；本文档其他处提及的 9 条仅统计自定义规则。
五次事件已撰写为完整的调查报告：
除了一次性触发外，一个验证平台在租户中驱动真实的良性 + 攻击批处理，并针对每条规则的 KQL 运行，因此误报是实测的，而非假设的。最新运行（结果）：5/5 攻击场景触发（DET-002/003/004/007/009），良性数据流上 0 次误触发（白名单所有者部署、低于阈值的删除、未授权部署）。它并不伪造生产流量，而是将“N=1 时 0% FP”转化为“在真实良性批处理上的实测 0 次误触发”。
一张明确标出空缺的覆盖率地图比一张规则列表更诚实。ATT&CK Navigator 层（如何加载）同时展示两类：
| 已覆盖（已部署规则） | 已知空缺，已跟踪为问题 |
|---|---|
| T1087 账户发现（DET-001） | T1530 来自云存储的数据，数据平面检测 |
| T1562.007 禁用/修改云防火墙（DET-002 / DET-009） | T1496 资源劫持，消费/挖矿异常 |
| T1098 账户操纵（DET-003 / DET-005 / DET-007） | T1526 云服务发现，增强启发式 |
| T1485 数据破坏（DET-004） | |
| T1003.001 LSASS 内存（DET-006） | |
| T1110 暴力破解 / T1078 有效账户（DET-008） |
这些空缺并非静态文字。每一个都是活跃的 detection-gap 问题，因此路线图是一个可点击的待办项列表。
为什么选择这些规则而非其他： docs/08，检测策略与威胁模型将目录映射到云杀伤链，并按风险对空缺进行排序。规则如何优化： docs/09，DET-005 的实测优化循环展示一条规则从“每次写入都触发”到验证平台上实测零误报的历程。
最高严重性检测实现了从检测到响应的闭环。一条 Sentinel 自动化规则在每次 DET-004（批量删除）事件触发时运行一个逻辑应用剧本：它发布一条包含建议处置措施（禁用调用者、锁定资源组、恢复、狩猎）的扩充评论。该剧本使用其自身的托管标识直接向 ARM API 进行身份验证，无需密钥，无需外部连接器。
第二个剧本将闭环扩展为检测 → 响应 → AI 调查，与 Microsoft Security Copilot 集成：一个提示手册 + 逻辑应用在相同的 DET-004 事件上调用 Copilot 提示手册，并将 AI 调查摘要作为评论发布。它的构建和部署不消耗任何计算单元；实时 AI 摘要采集运行在一个成本受限（约 $4）的付费窗口内，在采集完成前不会声明。成本及拆除操作手册：docs/06。
检测始于 Azure 控制平面；此阶段增加了端点平面。一台 Windows 主机上的 Defender for Endpoint 传感器向同一工作区提供数据，因此检测即代码流水线部署了一条端点规则 DET-006 LSASS 凭据访问，与控制平面规则并肩运行。DET-006 是多源且经过验证的：对传感器运行了三种凭据转储技术，加固的主机（LSASS RunAsPPL、AMSI、行为防护）阻止了每一种，而规则在生成的 Defender 警报上触发，从而创建一个事件（INV-03）。Defender 漏洞管理增加了第二个输入：一个狩猎库，用于根据暴露的软件、失败的安全配置基线和当前存在活跃警报的脆弱资产，发现关键 CVE。DeviceTvm* 表仅存在于 Defender 高级狩猎中，因此这些关联是狩猎查询而非部署的规则，并且仓库说明了每条查询实际在何处运行。架构与数据流：docs/07。
检测负责监控攻击；此阶段读取租户自身的态势评分并修复其标记的问题，然后证明数值已改变。通过 collect-posture.ps1 将 Defender for Cloud 安全评分基线捕获为机器可读的快照，因此前后对比是文件差异，而非截图比较。基线评分为 68.81%（21.33 / 31），各控制项细分显示 9.67 分的差距完全集中在四个控制项（静态加密、访问与权限、网络访问、审计）。修复按影响范围排序，优先进行累加式修复，并且每个修复项都映射到能捕获其回归行为的目录规则（存储暴露对应 DET-002 / DET-009，RBAC 扩散对应 DET-003 / DET-007，日志丢失对应整个目录）。本轮应用了三个修复并在资源级别验证：安全联系人与警报通知、两个 SOAR 剧本的诊断日志（+1 审计）、传感器 VM 的主机级加密（+4 静态加密）。Defender for Cloud 会在之后的 24 至 72 小时内重新评估并重新计算评分，因此后续评分将以跟进方式记录，而非现在断言。完整方法、有序计划及检测关联表格：docs/10，态势修复。
本工作支持一个公认的控制框架，因此仓库说明了对应关系。目录的每个部分都映射到 SOC 2 信任服务准则：九条规则目录和事件对应监控与响应系列（CC7.2 至 CC7.4），SOAR 剧本对应事件响应（CC7.4），PR 门控的检测即代码流水线对应变更管理（CC8.1），验证平台和态势前后对比对应控制运行有效性（CC4.1）。这被定位为映射而非合规声明：这是我个人运营的一个租户，而非经过审计的组织，因此文档映射了技术控制活动，并明确说明了真实的 SOC 2 报告所需的治理包装——这是检测仓库不包含的。完整的逐准则表格以及“在审计中如何解读”的说明：docs/11，SOC 2 控制项映射。
detections/rules 规则唯一真理来源（Sentinel YAML，由 CI 部署）
detections/*.md 每条规则一张卡片：逻辑、MITRE、触发方式、证据
detections/metrics.yaml 每条规则的度量指标（数量、误报率、真阳性、平均检测时间）
tests/ 合成日志单元测试（Kusto 模拟器，可 fork 运行）
validation/ 实时混合活动平台：良性 + 攻击流，实测真阳性/误报
cicd/ + .github 检测即代码流水线（部署、验证、回归）
sigma/ 供应商中立的 Sigma 转换（可移植至任意 SIEM）
kql/ 分析规则查询 + 狩猎库
investigations/ 端到端事件调查报告
simulations/ 精确的原子对齐触发步骤
navigator/ ATT&CK 覆盖率层（已覆盖 + 空缺）
posture/ 安全评分基线采集器 + JSON 快照 + 修复脚本
playbooks/ SOAR 响应（逻辑应用 + 自动化规则）
docs/ 架构、方法论、CI/CD、验证、数据字典、端点+TVM、检测策略、优化案例研究、态势修复、SOC 2 控制项映射
screenshots/ 可视化证据
KQL · Microsoft Sentinel 计划分析规则 · 多阶段关联规则 · Entra ID 身份检测（SigninLogs） · 白名单观察列表（_GetWatchlist） · 作为内容的 Azure Resource Graph 态势（计划操作） · Microsoft Defender XDR · Microsoft Defender for Endpoint · Defender 漏洞管理（TVM） · 高级狩猎（Device / DeviceTvm 表） · Microsoft 安全评分 · Defender for Cloud 态势修复（CSPM、MCSB） · SOC 2 通用准则控制项映射 · 检测即代码（GitHub Actions、OIDC） · SOAR（逻辑应用自动化规则） · Sigma（供应商中立） · Atomic Red Team 验证 · 事件分类与调查 · MITRE ATT&CK 映射 · Azure 控制平面（活动日志）监控。
这是一个个人作品集，但其结构使得检测变更是可审阅的拉取请求，而非门户中的一次点击。如果您 fork 了本仓库或想提出一条规则，CONTRIBUTING.md 涵盖了工作流程：编辑规则 YAML、重新生成 KQL 镜像、扩展测试数据、本地运行单元测试，并打开一个 PR 让相同的 CI 门控检查通过。
Microsoft Certified: Security Operations Analyst Associate (SC-200)。
这是我个人运营的环境，并非任何雇主或第三方的生产租户。检测通过针对我自己资源的可控、可自动撤销的管理操作进行验证；不涉及任何生产系统或第三方。所有截图中已隐去租户和订阅标识符及个人身份信息。
| 多次失败后成功登录（身份） |
| 中等 |
| 凭据访问 / 初始访问 |
| T1110 暴力破解, T1078 有效账户 |
| DET-009 | NSG 规则变更使入站来自 Any（ARG 内容） | 高 | 防御规避 | T1562.007 禁用/修改云防火墙 |