ibondarenko1/azure-sentinel-detection-engineering
GitHub: ibondarenko1/azure-sentinel-detection-engineering
在 Microsoft Sentinel + Defender XDR 环境中实现检测即代码的安全运营项目，包含九条经端到端验证的 MITRE ATT&CK 映射 KQL 检测规则、CI/CD 自动部署管线、SOAR playbook 及 SOC 2 合规映射。
Stars: 5 | Forks: 1
# Azure Sentinel 检测工程
这是我在实际运营的 Microsoft Sentinel 和 Defender XDR 环境中进行的检测工程。九条自定义分析规则跨越三个层面，每条规则均映射到 MITRE ATT&CK 并经过了端到端验证：受控操作触发规则，规则引发事件，随后对该事件进行调查和记录。其中七条监控 Azure **控制平面**（`AzureActivity`），包括多阶段关联和基于 ARG 的内容规则；一条监控**端点**（Defender for Endpoint），并由 Defender Vulnerability Management 提供数据支撑狩猎库；还有一条监控**身份**（Entra ID `SigninLogs`）。所有规则均通过同一个受 PR 限制的 pipeline 部署。
  
## 快速开始
**在 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 在每个 pull request 上运行的确切检查（[detection-tests](.github/workflows/detection-tests.yml)）：它断言每条规则在恶意测试用例上触发，并在良性用例上保持静默。[validation/](validation/) 中的实时测试工具更进一步，在租户中驱动真实的良性和攻击批次，并测量真阳性和误报，但这需要你自己的 Azure 订阅和 `az login`（参见 [validation/README](validation/README.md)），因此它不是“本地”的。部署 pipeline：[docs/03](docs/03-cicd.md)。贡献规则：[CONTRIBUTING](CONTRIBUTING.md)。
## 为什么要有这个项目
只有当你能展示检测被触发时，它才具有可信度。这个仓库闭环涵盖了三个平面：Azure 控制平面、端点和身份：规则逻辑、受控触发、生成的事件、调查以及 MITRE 映射。它通过多阶段关联（授权后部署）以及将 Azure Resource Graph 安全态势与变更事件相结合的内容感知规则，超越了单一事件规则。这是针对真实遥测数据（而非合成样本）的 Sentinel 分析规则、KQL 和事件响应。
## 检测即代码
这些规则不是在门户中点击配置的。它们是**由受 PR 限制的 pipeline 部署的带有版本的 YAML**。编辑检测意味着提交一个 pull request；CI 对其进行验证，审核者批准后，合并到 `main` 分支会通过 **OIDC（无存储的 secrets）**将其部署到 Sentinel，并通过规则的 GUID 实现 API `2025-09-01` 的幂等部署。
```
flowchart LR
D[Edit rule YAML] --> PR[Pull request] --> V[CI validate] -->|review| M[Merge main] --> CD[OIDC deploy] --> S[Sentinel sc200-ws]
```
- 真理来源：[`detections/rules/*.yaml`](detections/rules) · Pipeline：[`.github/workflows/deploy-detections.yml`](.github/workflows/deploy-detections.yml) · 部署器/验证器：[`cicd/`](cicd) · 详情：[docs/03-cicd.md](docs/03-cicd.md)
一个真实的变更已经过此流程：[PR #1](https://github.com/ibondarenko1/azure-sentinel-detection-engineering/pull/1) 收紧了 DET-001 的阈值（从 10 调整为 8）；CI 验证了它，合并后将其部署到了实时的 `sc200-ws` 规则中。这一步，即通过审核过的 PR 从 git 自动部署规则，正是区分检测**工程师**与只学完一门课程的分析师的关键。
## 架构
```
flowchart LR
subgraph Sources
A[Microsoft Defender XDR
Email · Endpoint] B[Azure subscription
Activity Log] C[Entra ID
sign-ins] end A --> W[Log Analytics workspace
sc200-ws] B --> W C --> W W --> R[9 scheduled
analytics rules] R --> I[Incidents] I --> V[Investigation
+ MITRE mapping] ```  ## 检测目录 | ID | 检测 | 严重性 | MITRE 战术 | 技术 | |----|-----------|----------|--------------|-----------| | [DET-001](detections/DET-001-failed-activity-log-spike.md) | Activity Log 失败操作激增 | 中 | Discovery | [T1087](https://attack.mitre.org/techniques/T1087/) Account Discovery | | [DET-002](detections/DET-002-nsg-rule-modified.md) | Network Security Group 规则被修改 | 中 | Defense Evasion | [T1562](https://attack.mitre.org/techniques/T1562/) Impair Defenses | | [DET-003](detections/DET-003-rbac-role-assignment-changes.md) | RBAC 角色分配更改 | 中 | Privilege Escalation / Persistence | [T1098](https://attack.mitre.org/techniques/T1098/) Account Manipulation | | [DET-004](detections/DET-004-mass-resource-deletion.md) | 批量资源删除 | **高** | Impact | [T1485](https://attack.mitre.org/techniques/T1485/) Data Destruction | | [DET-005](detections/DET-005-suspicious-deployment-non-owner.md) | 非所有者进行可疑资源部署 | 中 | Persistence | [T1098](https://attack.mitre.org/techniques/T1098/) Account Manipulation | | [DET-006](detections/DET-006-lsass-credential-access.md) | LSASS 凭据访问 (端点) | **高** | Credential Access | [T1003.001](https://attack.mitre.org/techniques/T1003/001/) LSASS Memory | | [DET-007](detections/DET-007-rbac-grant-then-deploy.md) | 授权后紧接部署 (关联) | **高** | Privilege Escalation / Persistence | [T1098](https://attack.mitre.org/techniques/T1098/) Account Manipulation | | [DET-008](detections/DET-008-signin-success-after-failures.md) | 多次失败后成功登录 (身份) | 中 | Credential Access / Initial Access | [T1110](https://attack.mitre.org/techniques/T1110/) Brute Force, [T1078](https://attack.mitre.org/techniques/T1078/) Valid Accounts | | [DET-009](detections/DET-009-nsg-opened-inbound-any.md) | NSG 规则更改为允许来自 Any 的入站流量 (ARG 内容) | **高** | Defense Evasion | [T1562.007](https://attack.mitre.org/techniques/T1562/007/) Disable/Modify Cloud Firewall |  ## 结果 每个检测都通过受控、可自动回滚的管理操作触发，并生成了真实的事件：  工作区当前的运营状态：10 个分析规则已启用，4 个数据连接器处于活动状态，一条自动化规则，以及实时流动的数据。这 10 个启用的规则是本目录中的九个自定义 `[DET]` 计划规则，加上 Microsoft 内置的 Fusion 规则（Advanced Multistage Attack Detection），该规则默认开启且非在此处创建；此 README 其他地方的数字“九”仅计算自定义规则。  五个事件已作为完整的调查记录在案： - [INV-01, 批量资源删除 (高)](investigations/INV-01-mass-resource-deletion.md) - [INV-02, RBAC 权限提升](investigations/INV-02-rbac-privilege-escalation.md) - [INV-03, LSASS 凭据访问 (高)](investigations/INV-03-lsass-credential-access.md)，端点，事件 #65 - [INV-04, NSG 入站开放自 Any (高)](investigations/INV-04-nsg-opened-inbound.md)，ARG 内容关联 (DET-009) - [INV-05, 授权后进行部署 (高)](investigations/INV-05-grant-then-deploy.md)，多阶段关联 (DET-007) 除了一次性触发外，[验证工具](validation/)还在租户中驱动真实的**良性 + 攻击**批次，并针对其运行每条规则的 KQL，因此误报是**测量出来的，而不是假设的**。最新一次运行（[结果](validation/RESULTS.md)）：5/5 攻击场景触发 (DET-002/003/004/007/009)，并且在良性流（白名单所有者部署、低于阈值的删除、无授权部署）上误报为 0。它不会伪造生产环境的流量；它将“N=1 时 0% FP”转换为实际测量到的“在真实的良性批次上零误报”。 ## ATT&CK 覆盖率 带有明确缺口的覆盖率地图比单纯的规则列表更诚实。[ATT&CK Navigator layer](navigator/coverage-layer.json)（[如何加载](navigator/README.md)）展示了两者： | 已覆盖 (已部署规则) | 已知缺口，作为 issue 追踪 | |-------------------------|---------------------------------| | T1087 Account Discovery (DET-001) | [T1530 Data from Cloud Storage](../../issues/12)，数据平面检测 | | T1562.007 Disable/Modify Cloud Firewall (DET-002 / DET-009) | [T1496 Resource Hijacking](../../issues/13)，花费/挖矿异常 | | T1098 Account Manipulation (DET-003 / DET-005 / DET-007) | [T1526 Cloud Service Discovery](../../issues/14)，加强启发式算法 | | T1485 Data Destruction (DET-004) | | | T1003.001 LSASS Memory (DET-006) | | | T1110 Brute Force / T1078 Valid Accounts (DET-008) | | 这些缺口不是静态文本。每一个都是一个活跃的 [`detection-gap` issue](../../issues?q=is%3Aissue+label%3Adetection-gap)，因此路线图是一个可点击的待办列表。 **为什么选择这些规则而不是其他规则：**[docs/08, 检测策略和威胁建模](docs/08-detection-strategy.md) 将目录映射到云杀伤链，并对缺口进行了风险排序。**如何调优规则：**[docs/09, 一个可量化的 DET-005 调优闭环](docs/09-tuning-case-study.md) 展示了如何将一条规则从“每次写入都触发”转变为在验证工具上测量出的零误报。 ## 自动响应 (SOAR) 最高严重性的检测完成了从检测到响应的闭环。一条 Sentinel 自动化规则在每个 DET-004（批量删除）事件上运行 [Logic App playbook](playbooks/mass-deletion-response)：它会发布一条包含建议遏制措施（禁用调用者、锁定资源组、还原、狩猎）的富集评论。该 playbook 使用其专用的 **managed identity** 直接向 ARM API 验证身份，无需 secrets 和外部连接器。 第二个 playbook 利用 **Microsoft Security Copilot** 将闭环扩展到了 **检测 → 响应 → AI 调查**：一个 [promptbook + Logic App](playbooks/copilot-triage) 在同一个 DET-004 事件上调用 Copilot promptbook，并发布 AI 调查摘要作为评论。它在构建和部署时不需要任何计算单元；实时的 AI 摘要捕获是在一个成本可控（约 $4）的付费窗口中运行的，未被捕获前不作任何声明。成本和清理运行手册：[docs/06](docs/06-security-copilot.md)。 ## 端点和漏洞管理 检测从 Azure 控制平面开始；此阶段增加了端点平面。Windows 主机上的 Defender for Endpoint 传感器将数据输入到同一个工作区，因此检测即代码 pipeline 在控制平面规则旁部署了一条端点规则 [DET-006 LSASS 凭据访问](detections/DET-006-lsass-credential-access.md)。DET-006 是多源且经过验证的：针对该传感器运行了三种凭据转储技术，强化过的主机（LSASS RunAsPPL, AMSI, 行为保护）阻止了每一次尝试，并且该规则在生成的 Defender 告警上触发，从而引发了事件（[INV-03](investigations/INV-03-lsass-credential-access.md)）。Defender Vulnerability Management 增加了第二个输入：一个[狩猎库](kql/hunting)，它通过暴露的软件、失败的配置安全基线以及处于活跃告警下的易受攻击资产来呈现关键的 CVE。`DeviceTvm*` 表仅存在于 Defender 高级狩猎中，因此这些关联属于狩猎，而不是已部署的规则，该仓库说明了每个查询实际运行的位置。架构和数据流：[docs/07](docs/07-endpoint-vulnerability-management.md)。   ## 态势修复 这些检测用于监控攻击；此阶段会读取租户自身的态势分数并修复其 标记的问题，然后证明数值有所提升。Defender for Cloud Secure Score 基线被 [collect-posture.ps1](posture/collect-posture.ps1) 提取为[机器可读的快照](posture/snapshots/2026-06-10-baseline.json)， 因此前后的对比是文件的差异比对而不是截图对比。在基线处，分数为 **68.81%** (21.33 / 31)，每项控制的细分将所有 9.67 分的差距置于四个控制项中 (静态加密、访问和权限、网络访问、审计)。修复工作是按 影响范围排序的，首先应用附加修复，并且每个项目都映射到目录中 能捕获其倒退的规则（存储暴露对应 DET-002 / DET-009，RBAC 泛滥对应 DET-003 / DET-007，丢失日志记录对应整个目录）。本轮应用了三个修复并在 资源级别进行了验证：安全联系人和告警通知、两个 SOAR playbook 的诊断 日志记录 (+1 审计)，以及传感器 VM 上的主机加密 (+4 静态加密)。Defender for Cloud 会在随后的 24 到 72 小时内重新评估并 重新计算分数，因此之后的分数被记录为后续跟进内容，而不是现在就断言。完整的方法、有序的计划和检测链接表： [docs/10, 态势修复](docs/10-posture-remediation.md)。   ## SOC 2 控制映射 这项工作支持一个公认的控制系统框架，因此仓库说明了其所在位置。目录中的每个部分都 映射到一个 SOC 2 信任服务标准：九条规则目录和事件映射到监控和响应 系列 (CC7.2 到 CC7.4)，SOAR playbook 映射到事件响应 (CC7.4)，受 PR 限制的检测即代码 pipeline 映射到变更管理 (CC8.1)，验证工具和态势的前后对比映射到控制 运营有效性 (CC4.1)。它被构建为一种映射，而不是合规声明：这是由我 运营的单一租户，而不是经过审计的组织，因此文档映射了技术控制活动，并 明确指出了真实 SOC 2 报告所需而检测仓库不具备的治理外壳。 完整的逐项标准表以及在审计中如何解读的说明： [docs/11, SOC 2 控制映射](docs/11-soc2-control-mapping.md)。 ## 仓库布局 ``` detections/rules rule source-of-truth (Sentinel YAML, deployed by CI) detections/*.md one card per rule: logic, MITRE, trigger, evidence detections/metrics.yaml per-detection metrics (volume, FP rate, TP, MTTD) tests/ synthetic-log unit tests (Kusto emulator, fork-runnable) validation/ live mixed-activity harness: benign + attack streams, measured TP/FP cicd/ + .github Detection-as-Code pipeline (deploy, validate, regression) sigma/ vendor-neutral Sigma conversions (portable to any SIEM) kql/ analytics-rule queries + hunting library investigations/ end-to-end incident write-ups simulations/ exact atomic-aligned trigger steps navigator/ ATT&CK coverage layer (covered + gaps) posture/ Secure Score baseline collector + JSON snapshots + remediation script playbooks/ SOAR response (Logic App + automation rule) docs/ architecture, methodology, cicd, validation, data-dictionary, endpoint+TVM, detection-strategy, tuning case study, posture remediation, SOC 2 control mapping screenshots/ visual evidence ``` ## 展示的技能 KQL · Microsoft Sentinel 计划分析规则 · 多阶段关联规则 · Entra ID 身份检测 (SigninLogs) · 白名单监控列表 (`_GetWatchlist`) · Azure Resource Graph 态势即内容 (计划的 Action) · Microsoft Defender XDR · Microsoft Defender for Endpoint · Defender Vulnerability Management (TVM) · 高级狩猎 (Device / DeviceTvm 表) · Microsoft Secure Score · Defender for Cloud 态势修复 (CSPM, MCSB) · SOC 2 常见标准控制映射 · 检测即代码 (GitHub Actions, OIDC) · SOAR (Logic Apps 自动化规则) · Sigma (供应商中立) · Atomic Red Team 验证 · 事件分诊和调查 · MITRE ATT&CK 映射 · Azure 控制平面 (Activity Log) 监控。 ## 凭证 Microsoft 认证：Security Operations Analyst Associate (SC-200)。 ## 免责声明 这是我运营的环境，不是任何雇主或第三方的生产租户。检测是通过针对我自己资源的受控、可自动回滚的管理操作进行验证的；不涉及生产系统，也不涉及第三方。所有屏幕截图中的租户和订阅标识符以及 PII 均已被脱敏。 ## 许可证 [MIT](LICENSE)
Email · Endpoint] B[Azure subscription
Activity Log] C[Entra ID
sign-ins] end A --> W[Log Analytics workspace
sc200-ws] B --> W C --> W W --> R[9 scheduled
analytics rules] R --> I[Incidents] I --> V[Investigation
+ MITRE mapping] ```  ## 检测目录 | ID | 检测 | 严重性 | MITRE 战术 | 技术 | |----|-----------|----------|--------------|-----------| | [DET-001](detections/DET-001-failed-activity-log-spike.md) | Activity Log 失败操作激增 | 中 | Discovery | [T1087](https://attack.mitre.org/techniques/T1087/) Account Discovery | | [DET-002](detections/DET-002-nsg-rule-modified.md) | Network Security Group 规则被修改 | 中 | Defense Evasion | [T1562](https://attack.mitre.org/techniques/T1562/) Impair Defenses | | [DET-003](detections/DET-003-rbac-role-assignment-changes.md) | RBAC 角色分配更改 | 中 | Privilege Escalation / Persistence | [T1098](https://attack.mitre.org/techniques/T1098/) Account Manipulation | | [DET-004](detections/DET-004-mass-resource-deletion.md) | 批量资源删除 | **高** | Impact | [T1485](https://attack.mitre.org/techniques/T1485/) Data Destruction | | [DET-005](detections/DET-005-suspicious-deployment-non-owner.md) | 非所有者进行可疑资源部署 | 中 | Persistence | [T1098](https://attack.mitre.org/techniques/T1098/) Account Manipulation | | [DET-006](detections/DET-006-lsass-credential-access.md) | LSASS 凭据访问 (端点) | **高** | Credential Access | [T1003.001](https://attack.mitre.org/techniques/T1003/001/) LSASS Memory | | [DET-007](detections/DET-007-rbac-grant-then-deploy.md) | 授权后紧接部署 (关联) | **高** | Privilege Escalation / Persistence | [T1098](https://attack.mitre.org/techniques/T1098/) Account Manipulation | | [DET-008](detections/DET-008-signin-success-after-failures.md) | 多次失败后成功登录 (身份) | 中 | Credential Access / Initial Access | [T1110](https://attack.mitre.org/techniques/T1110/) Brute Force, [T1078](https://attack.mitre.org/techniques/T1078/) Valid Accounts | | [DET-009](detections/DET-009-nsg-opened-inbound-any.md) | NSG 规则更改为允许来自 Any 的入站流量 (ARG 内容) | **高** | Defense Evasion | [T1562.007](https://attack.mitre.org/techniques/T1562/007/) Disable/Modify Cloud Firewall |  ## 结果 每个检测都通过受控、可自动回滚的管理操作触发，并生成了真实的事件：  工作区当前的运营状态：10 个分析规则已启用，4 个数据连接器处于活动状态，一条自动化规则，以及实时流动的数据。这 10 个启用的规则是本目录中的九个自定义 `[DET]` 计划规则，加上 Microsoft 内置的 Fusion 规则（Advanced Multistage Attack Detection），该规则默认开启且非在此处创建；此 README 其他地方的数字“九”仅计算自定义规则。  五个事件已作为完整的调查记录在案： - [INV-01, 批量资源删除 (高)](investigations/INV-01-mass-resource-deletion.md) - [INV-02, RBAC 权限提升](investigations/INV-02-rbac-privilege-escalation.md) - [INV-03, LSASS 凭据访问 (高)](investigations/INV-03-lsass-credential-access.md)，端点，事件 #65 - [INV-04, NSG 入站开放自 Any (高)](investigations/INV-04-nsg-opened-inbound.md)，ARG 内容关联 (DET-009) - [INV-05, 授权后进行部署 (高)](investigations/INV-05-grant-then-deploy.md)，多阶段关联 (DET-007) 除了一次性触发外，[验证工具](validation/)还在租户中驱动真实的**良性 + 攻击**批次，并针对其运行每条规则的 KQL，因此误报是**测量出来的，而不是假设的**。最新一次运行（[结果](validation/RESULTS.md)）：5/5 攻击场景触发 (DET-002/003/004/007/009)，并且在良性流（白名单所有者部署、低于阈值的删除、无授权部署）上误报为 0。它不会伪造生产环境的流量；它将“N=1 时 0% FP”转换为实际测量到的“在真实的良性批次上零误报”。 ## ATT&CK 覆盖率 带有明确缺口的覆盖率地图比单纯的规则列表更诚实。[ATT&CK Navigator layer](navigator/coverage-layer.json)（[如何加载](navigator/README.md)）展示了两者： | 已覆盖 (已部署规则) | 已知缺口，作为 issue 追踪 | |-------------------------|---------------------------------| | T1087 Account Discovery (DET-001) | [T1530 Data from Cloud Storage](../../issues/12)，数据平面检测 | | T1562.007 Disable/Modify Cloud Firewall (DET-002 / DET-009) | [T1496 Resource Hijacking](../../issues/13)，花费/挖矿异常 | | T1098 Account Manipulation (DET-003 / DET-005 / DET-007) | [T1526 Cloud Service Discovery](../../issues/14)，加强启发式算法 | | T1485 Data Destruction (DET-004) | | | T1003.001 LSASS Memory (DET-006) | | | T1110 Brute Force / T1078 Valid Accounts (DET-008) | | 这些缺口不是静态文本。每一个都是一个活跃的 [`detection-gap` issue](../../issues?q=is%3Aissue+label%3Adetection-gap)，因此路线图是一个可点击的待办列表。 **为什么选择这些规则而不是其他规则：**[docs/08, 检测策略和威胁建模](docs/08-detection-strategy.md) 将目录映射到云杀伤链，并对缺口进行了风险排序。**如何调优规则：**[docs/09, 一个可量化的 DET-005 调优闭环](docs/09-tuning-case-study.md) 展示了如何将一条规则从“每次写入都触发”转变为在验证工具上测量出的零误报。 ## 自动响应 (SOAR) 最高严重性的检测完成了从检测到响应的闭环。一条 Sentinel 自动化规则在每个 DET-004（批量删除）事件上运行 [Logic App playbook](playbooks/mass-deletion-response)：它会发布一条包含建议遏制措施（禁用调用者、锁定资源组、还原、狩猎）的富集评论。该 playbook 使用其专用的 **managed identity** 直接向 ARM API 验证身份，无需 secrets 和外部连接器。 第二个 playbook 利用 **Microsoft Security Copilot** 将闭环扩展到了 **检测 → 响应 → AI 调查**：一个 [promptbook + Logic App](playbooks/copilot-triage) 在同一个 DET-004 事件上调用 Copilot promptbook，并发布 AI 调查摘要作为评论。它在构建和部署时不需要任何计算单元；实时的 AI 摘要捕获是在一个成本可控（约 $4）的付费窗口中运行的，未被捕获前不作任何声明。成本和清理运行手册：[docs/06](docs/06-security-copilot.md)。 ## 端点和漏洞管理 检测从 Azure 控制平面开始；此阶段增加了端点平面。Windows 主机上的 Defender for Endpoint 传感器将数据输入到同一个工作区，因此检测即代码 pipeline 在控制平面规则旁部署了一条端点规则 [DET-006 LSASS 凭据访问](detections/DET-006-lsass-credential-access.md)。DET-006 是多源且经过验证的：针对该传感器运行了三种凭据转储技术，强化过的主机（LSASS RunAsPPL, AMSI, 行为保护）阻止了每一次尝试，并且该规则在生成的 Defender 告警上触发，从而引发了事件（[INV-03](investigations/INV-03-lsass-credential-access.md)）。Defender Vulnerability Management 增加了第二个输入：一个[狩猎库](kql/hunting)，它通过暴露的软件、失败的配置安全基线以及处于活跃告警下的易受攻击资产来呈现关键的 CVE。`DeviceTvm*` 表仅存在于 Defender 高级狩猎中，因此这些关联属于狩猎，而不是已部署的规则，该仓库说明了每个查询实际运行的位置。架构和数据流：[docs/07](docs/07-endpoint-vulnerability-management.md)。   ## 态势修复 这些检测用于监控攻击；此阶段会读取租户自身的态势分数并修复其 标记的问题，然后证明数值有所提升。Defender for Cloud Secure Score 基线被 [collect-posture.ps1](posture/collect-posture.ps1) 提取为[机器可读的快照](posture/snapshots/2026-06-10-baseline.json)， 因此前后的对比是文件的差异比对而不是截图对比。在基线处，分数为 **68.81%** (21.33 / 31)，每项控制的细分将所有 9.67 分的差距置于四个控制项中 (静态加密、访问和权限、网络访问、审计)。修复工作是按 影响范围排序的，首先应用附加修复，并且每个项目都映射到目录中 能捕获其倒退的规则（存储暴露对应 DET-002 / DET-009，RBAC 泛滥对应 DET-003 / DET-007，丢失日志记录对应整个目录）。本轮应用了三个修复并在 资源级别进行了验证：安全联系人和告警通知、两个 SOAR playbook 的诊断 日志记录 (+1 审计)，以及传感器 VM 上的主机加密 (+4 静态加密)。Defender for Cloud 会在随后的 24 到 72 小时内重新评估并 重新计算分数，因此之后的分数被记录为后续跟进内容，而不是现在就断言。完整的方法、有序的计划和检测链接表： [docs/10, 态势修复](docs/10-posture-remediation.md)。   ## SOC 2 控制映射 这项工作支持一个公认的控制系统框架，因此仓库说明了其所在位置。目录中的每个部分都 映射到一个 SOC 2 信任服务标准：九条规则目录和事件映射到监控和响应 系列 (CC7.2 到 CC7.4)，SOAR playbook 映射到事件响应 (CC7.4)，受 PR 限制的检测即代码 pipeline 映射到变更管理 (CC8.1)，验证工具和态势的前后对比映射到控制 运营有效性 (CC4.1)。它被构建为一种映射，而不是合规声明：这是由我 运营的单一租户，而不是经过审计的组织，因此文档映射了技术控制活动，并 明确指出了真实 SOC 2 报告所需而检测仓库不具备的治理外壳。 完整的逐项标准表以及在审计中如何解读的说明： [docs/11, SOC 2 控制映射](docs/11-soc2-control-mapping.md)。 ## 仓库布局 ``` detections/rules rule source-of-truth (Sentinel YAML, deployed by CI) detections/*.md one card per rule: logic, MITRE, trigger, evidence detections/metrics.yaml per-detection metrics (volume, FP rate, TP, MTTD) tests/ synthetic-log unit tests (Kusto emulator, fork-runnable) validation/ live mixed-activity harness: benign + attack streams, measured TP/FP cicd/ + .github Detection-as-Code pipeline (deploy, validate, regression) sigma/ vendor-neutral Sigma conversions (portable to any SIEM) kql/ analytics-rule queries + hunting library investigations/ end-to-end incident write-ups simulations/ exact atomic-aligned trigger steps navigator/ ATT&CK coverage layer (covered + gaps) posture/ Secure Score baseline collector + JSON snapshots + remediation script playbooks/ SOAR response (Logic App + automation rule) docs/ architecture, methodology, cicd, validation, data-dictionary, endpoint+TVM, detection-strategy, tuning case study, posture remediation, SOC 2 control mapping screenshots/ visual evidence ``` ## 展示的技能 KQL · Microsoft Sentinel 计划分析规则 · 多阶段关联规则 · Entra ID 身份检测 (SigninLogs) · 白名单监控列表 (`_GetWatchlist`) · Azure Resource Graph 态势即内容 (计划的 Action) · Microsoft Defender XDR · Microsoft Defender for Endpoint · Defender Vulnerability Management (TVM) · 高级狩猎 (Device / DeviceTvm 表) · Microsoft Secure Score · Defender for Cloud 态势修复 (CSPM, MCSB) · SOC 2 常见标准控制映射 · 检测即代码 (GitHub Actions, OIDC) · SOAR (Logic Apps 自动化规则) · Sigma (供应商中立) · Atomic Red Team 验证 · 事件分诊和调查 · MITRE ATT&CK 映射 · Azure 控制平面 (Activity Log) 监控。 ## 凭证 Microsoft 认证：Security Operations Analyst Associate (SC-200)。 ## 免责声明 这是我运营的环境，不是任何雇主或第三方的生产租户。检测是通过针对我自己资源的受控、可自动回滚的管理操作进行验证的；不涉及生产系统，也不涉及第三方。所有屏幕截图中的租户和订阅标识符以及 PII 均已被脱敏。 ## 许可证 [MIT](LICENSE)
标签：AMSI绕过, Detection-as-Code, DevSecOps, KQL, Microsoft Sentinel, SOAR, 上游代理, 威胁检测, 安全运营, 扫描框架, 请求拦截, 逆向工具