Back to Details

sentinel-detection-engineering

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Sentinel Detection Engineering

Microsoft Sentinel检测工程

Sentinel detection engineering is the discipline of building high-fidelity, well-tuned, maintainable detections and response automation. This skill covers the lifecycle — content sourcing, authoring, validating, automating, and versioning detections — not the broader SIEM architecture.
Sentinel检测工程是构建高保真、调优完善、可维护的检测机制与响应自动化的学科。本技能覆盖检测内容的全生命周期——内容获取、编写、验证、自动化与版本控制——不涉及更宽泛的SIEM架构。

When to use

适用场景

Authoring or maturing analytics rules, hunting queries, automation rules, and playbooks in Microsoft Sentinel. Use for KQL detection patterns, MITRE alignment, content-hub vs custom choices, and detection-as-code rollout.
Do not use this skill for Sentinel onboarding/architecture (
sentinel
), Defender XDR custom detections in isolation (
defender-xdr
), or generic KQL learning unrelated to detection.
在Microsoft Sentinel中编写或优化分析规则、狩猎查询、自动化规则与Playbook。适用于KQL检测模式、MITRE对齐、Content Hub与自定义方案选择，以及检测即代码的落地。
不适用场景：Sentinel入门配置/架构（请使用
sentinel
相关资源）、独立的Defender XDR自定义检测（请使用
defender-xdr
相关资源）、与检测无关的通用KQL学习。

Sources of content (use in this order)

内容来源（按优先级排序）

  1. Content Hub solutions — Microsoft- and partner-published, versioned bundles of data connectors, analytics rules, hunting queries, workbooks, playbooks. Always start here. Install the solution; enable rules in Active.
  2. Microsoft Sentinel GitHub — community-contributed queries that haven't (yet) made it into a solution. Vet, then promote into your repo.
  3. Custom detections — domain-specific, authored against your own data sources or specific business logic.
Rule of thumb: If a Microsoft solution covers 80% of the use case, install the solution and override the 20% in your repo — don't fork from scratch.
  1. Content Hub解决方案——由微软及合作伙伴发布的版本化捆绑包，包含数据连接器、分析规则、狩猎查询、工作簿、Playbook。始终从这里开始。安装解决方案后，在Active状态下启用规则。
  2. Microsoft Sentinel GitHub仓库——社区贡献的查询，尚未纳入解决方案。经过验证后，可将其推广至您的仓库。
  3. 自定义检测——针对特定领域、自有数据源或特定业务逻辑编写的检测规则。
经验法则：如果微软的解决方案能覆盖80%的使用场景，请安装该解决方案并在您的仓库中修改剩余20%的内容——不要从头开始复刻。

Choose the analytics rule type

选择分析规则类型

Rule typeWhen to useLatency
ScheduledMost cases; KQL window-based5 min – 24 h
Near-real-time (NRT)High-priority, single-event detections (e.g., privileged role assignment)<1 min
Microsoft Security (legacy)Forward Defender alerts as Sentinel incidentsImmediate
FusionMulti-stage attack correlation (built-in ML)Variable
AnomaliesBehavior baselines (built-in ML)Hourly
Threat IntelligenceTI-indicator → log matchSchedule
NRT has constraints (single table, no joins to most reference tables) — verify before choosing.
规则类型适用场景延迟
计划型（Scheduled）大多数场景；基于KQL时间窗口5分钟 – 24小时
近实时（Near-real-time, NRT）高优先级单事件检测（例如：特权角色分配）<1分钟
Microsoft Security（旧版）将Defender告警转发为Sentinel事件即时
Fusion多阶段攻击关联（内置机器学习）可变
异常（Anomalies）行为基线检测（内置机器学习）每小时
威胁情报（Threat Intelligence）威胁情报指示器与日志匹配按计划执行
NRT规则存在限制（仅支持单表，无法与大多数参考表关联）——选择前请确认。

Approach

实施步骤

  1. Start from a use case, not a query. Phrase the detection as: "Detect <attacker behavior> on <data source> with <expected fidelity>." Map to MITRE ATT&CK technique IDs before opening the KQL editor.
  2. Confirm data coverage. Does the connector emit the fields you need? Run a 
    take 100
    first, look at the schema, and check ingestion latency for that table.
  3. Author the KQL with detection patterns:
    • Filter early, project late.
    • Use 
      summarize
      + 
      bin(TimeGenerated, 5m)
      for rate-based detections.
    • Use 
      materialize()
      once for joined intermediate results.
    • For lookup-rich rules (allowlists, asset criticality), use watchlists via 
      _GetWatchlist("name")
      .
    • Avoid 
      *
      joins on huge tables — pre-filter both sides.
  4. Map entities. Set User, Host, IP, FileHash, Url entities in the rule UI so the incident graph and investigation experience work. Without entity mapping, Sentinel incidents are flat blobs.
  5. Set incident creation thoughtfully. Group alerts into a single incident using 
    Group all alerts triggered by this rule into a single incident
    for high-volume rules with bursty behavior, or per-entity grouping for "one-incident-per-user."
  6. Validate. Run the rule's KQL over a 7-day historical window. Look at:
    • Average alerts/day → must be triageable (target <10 for high severity).
    • False-positive samples — if 50% are FP, tune; don't ship.
    • Coverage — does it actually fire on a known attack scenario? Use Attack Simulation Training logs or replay an exported red-team event.
  7. Wire automation.
    • Automation rule (no-code) for assignment, severity tweak, suppression windows, bulk close.
    • Playbook (Logic App) for actions — disable user, isolate device (via Defender for Endpoint), enrich from MDTI, post to Teams/Slack, open ITSM ticket.
    • Use incident-trigger playbooks (run once per incident) over alert-trigger for anything with shared context.
  8. Detection-as-code. Connect Sentinel to a GitHub or Azure DevOps repo via the Repositories feature. Source of truth is the repo; deployments are pipelines. Branch protection + PR review = no more "someone tweaked the rule in the portal."
  9. Lifecycle.
    • Tag rules with version (in metadata) and owner.
    • Re-validate quarterly: data-source schema changes break detections silently.
    • Retire rules with sustained zero alerts and no FN coverage.
  1. 从用例出发，而非查询。将检测需求表述为："检测<攻击者行为>在<数据源>上的发生，达到<预期保真度>。" 在打开KQL编辑器前，先映射到MITRE ATT&CK技术ID。
  2. 确认数据覆盖范围。连接器是否会输出您需要的字段？先运行
    take 100
    查看数据，检查 schema，并确认该表的 ingestion 延迟。
  3. 使用检测模式编写KQL查询：
    • 尽早过滤数据，晚些再选择字段（Filter early, project late）。
    • 对于基于速率的检测，使用
      summarize
      + 
      bin(TimeGenerated, 5m)
      。
    • 对于关联的中间结果，仅使用一次
      materialize()
      。
    • 对于依赖查找的规则（允许列表、资产优先级），通过
      _GetWatchlist("name")
      使用监视列表。
    • 避免在大型表上使用
      *
      关联——先对两边的数据进行预过滤。
  4. 映射实体。在规则UI中设置User、Host、IP、FileHash、Url实体，确保事件图谱与调查体验正常工作。没有实体映射的话，Sentinel事件只是扁平的信息块。
  5. 合理设置事件创建规则。对于高流量且突发的规则，使用
    将此规则触发的所有告警分组到单个事件中
    ；对于“每个用户对应一个事件”的场景，按实体分组。
  6. 验证规则。在7天的历史时间窗口上运行规则的KQL查询，检查：
    • 日均告警数→必须可进行分流处理（高严重性规则目标<10条）。
    • 误报样本→如果50%是误报，需调优规则，不要直接部署。
    • 覆盖范围→规则是否会在已知攻击场景下触发？使用Attack Simulation Training日志或重放导出的红队事件。
  7. 配置自动化。
  • 自动化规则（无代码）用于分配任务、调整严重性、设置抑制窗口、批量关闭事件。
  • **Playbook（Logic App）**用于执行操作——禁用用户、隔离设备（通过Defender for Endpoint）、从MDTI获取增强信息、发布到Teams/Slack、创建ITSM工单。
  • 对于需要共享上下文的操作，使用事件触发的Playbook（每个事件运行一次），而非告警触发的Playbook。
  1. 检测即代码。通过Repositories功能将Sentinel连接到GitHub或Azure DevOps仓库。仓库为事实数据源，部署通过流水线完成。分支保护+PR审核=避免“有人在门户中修改了规则”的问题。
  2. 生命周期管理。
    • 在元数据中为规则标记版本和所有者。
    • 每季度重新验证：数据源schema变更可能会静默破坏检测规则。
    • 停用持续无告警且无漏报覆盖的规则。

Guardrails

注意事项

  • Don't ship a rule without a 7-day backtest. "Looks right in the editor" → noise storm in production.
  • High-volume tables (
    SecurityEvent
    , 
    Syslog
    , 
    CommonSecurityLog
    ) — filter early.     Whole-table scans cost LA money and run slow.
  • NRT has limits. Don't try to bend a 5-table-join detection into NRT; use scheduled.
  • Always map entities. No entities = no investigation graph = analyst pain.
  • Don't auto-disable users from a low-confidence rule. SOAR power × low fidelity = outages. Pair with high-fidelity rules only.
  • Watchlists are not append-only logs. They have row limits (~10 MB / 1M rows depending). Use Log Analytics tables for big reference data.
  • Microsoft-published rules update via solutions. If you fork by editing in-place, you lose updates. Clone/rename or override in repo.
  • Defender XDR custom detections vs Sentinel rules — author where the data lives. If the data is XDR-only and triage happens in XDR, do the custom detection in XDR; don't duplicate.
  • 未经过7天回溯测试的规则不要部署。“编辑器中看起来没问题”→生产环境中的噪音风暴。
  • 高流量表（
    SecurityEvent
    、
    Syslog
    、
    CommonSecurityLog
    ）——尽早过滤数据    。全表扫描会增加Log Analytics成本且运行缓慢。
  • NRT规则存在限制。不要试图将涉及5表关联的检测规则改为NRT类型；使用计划型规则。
  • 始终映射实体。没有实体→没有调查图谱→分析师工作负担加重。
  • 不要基于低置信度规则自动禁用用户。SOAR的强大功能×低保真度=服务中断。仅与高置信度规则配合使用。
  • 监视列表不是追加式日志。它们有行限制（约10 MB / 100万行，具体取决于配置）。大型参考数据请使用Log Analytics表。
  • 微软发布的规则通过解决方案更新。如果您在门户中直接编辑复刻规则，会失去更新支持。请克隆/重命名或在仓库中覆盖。
  • Defender XDR自定义检测与Sentinel规则——在数据所在的环境中编写规则。如果数据仅存在于XDR且分流在XDR中完成，请在XDR中创建自定义检测；不要重复创建。

Common anti-patterns

常见反模式

  • "Wrote 200 rules, all P2 severity" — meaningless prioritization. Severity reflects business impact + fidelity, not count.
  • "Used 
    where TimeGenerated > ago(90d)
    in a 5-minute scheduled rule"     — destroys cost. Match the lookback to the rule cadence.
  • "Authored detections only in the portal, no source control" — change history, rollback, and review are gone.
  • "Group-all-alerts on a noisy rule" — single mega-incident with thousands of alerts; triage impossible.
  • "Auto-isolate-device playbook on day-one detection" — false-positive outage. Audit-mode SOAR first.
  • "Threat-intel match rule against every IOC" — terabytes of indicators × millions of log rows. Filter by indicator type/confidence and scope tables.
  • "Skipped MITRE mapping because 'we know what it does'" — blocks coverage analysis and stakeholder reporting.
  • “编写了200条规则，全部为P2严重性”——优先级划分毫无意义。严重性应反映业务影响+保真度，而非数量。
  • “在5分钟计划型规则中使用
    where TimeGenerated > ago(90d)
    ”    ——成本极高。回溯时间应与规则周期匹配。
  • “仅在门户中编写检测规则，不使用源代码控制”——失去变更历史、回滚和审核能力。
  • “对噪音大的规则使用‘全部告警分组’”——生成包含数千条告警的巨型事件；无法进行分流处理。
  • “在新部署的检测规则上配置自动隔离设备的Playbook”——误报导致服务中断。先使用审计模式的SOAR。
  • “针对每个IOC创建威胁情报匹配规则”——TB级的指示器×数百万条日志行。按指示器类型/置信度和表范围进行过滤。
  • “跳过MITRE映射，因为‘我们知道它的作用’”——阻碍覆盖范围分析和利益相关者报告。

Example prompts

示例请求

  • Author a Sentinel scheduled rule for impossible-travel using SigninLogs with proper entity mapping.
  • Convert a noisy detection (avg 800 alerts/day) into actionable form via tuning and grouping.
  • Build the playbook to isolate a Defender for Endpoint device on a Sentinel incident, with an approval step in Teams.
  • Set up Sentinel Repositories to deploy analytics rules from GitHub via PR.
  • Write an NRT rule for newly-added Global Administrator that fires within 1 minute.
  • Map a custom detection to MITRE ATT&CK techniques and validate coverage gaps.
  • Build a hunting workbook for living-off-the-land binary usage across endpoints.
  • Quarterly content review: identify zero-alert rules, validate they're not silently broken, retire or refactor.
  • 编写一个基于SigninLogs的Sentinel计划型规则，用于检测不可能旅行，并配置正确的实体映射。
  • 通过调优和分组，将一个噪音大的检测规则（日均800条告警）转换为可操作的形式。
  • 构建一个Playbook，在Sentinel事件触发时隔离Defender for Endpoint设备，并在Teams中设置审批步骤。
  • 配置Sentinel Repositories，通过PR从GitHub部署分析规则。
  • 编写一个NRT规则，用于检测新增的全局管理员，要求1分钟内触发。
  • 将自定义检测规则映射到MITRE ATT&CK技术，并验证覆盖范围缺口。
  • 构建一个工作簿，用于狩猎终端上的合法工具滥用（living-off-the-land binary）行为。
  • 季度内容审核：识别无告警规则，验证是否静默失效，停用或重构。

Microsoft Learn

Microsoft Learn资源