Skip to content
CloudRunbook logo
Start Here

Security · Runbook

Sentinel analytics rules to enable first

• 9 min read

How to pick Sentinel analytics rules to enable first: content hub templates, data source checks, false-positive tuning and the Defender portal.

  • Rollback: Yes

Applies to: Microsoft Sentinel · Microsoft Defender

Sentinel SIEM Detection Defender Security
On this page
  1. What it is
  2. Who is affected
  3. Why it matters
  4. Decisions to make
  5. Runbook
  6. Checks
  7. Rollback
  8. Common pitfalls
TL;DR

Start your Sentinel analytics rules from content hub templates, not from blank queries. Enable the rules that match the data connectors you have actually connected, add the Microsoft Defender Threat Intelligence Analytics matching rule, and plan tuning from day one. Check which rule types your portal supports, because Microsoft security incident creation rules and the Fusion rule behave differently once Sentinel is in the Defender portal.

Source and what to verify

Checked on 17 October 2026 against these Microsoft Learn pages: Threat detection in Microsoft Sentinel, Create scheduled analytics rules from templates, Use matching analytics to detect threats, Quick threat detection with NRT rules, Get fine-tuning recommendations, Handle false positives, Create incidents from alerts, Roles and permissions, Connect Sentinel to the Defender portal and Sentinel in the Defender portal. Confirm in your own workspace: whether it is onboarded to the Defender portal, which data connectors are connected, and which templates your installed solutions provide.

What it is

Learn says Microsoft strongly encourages you to build Sentinel analytics rules from the templates delivered by content hub solutions. Templates are pre-built rule prototypes.

Learn lists these rule types:

  • Scheduled
  • Near-real-time (NRT)
  • Anomaly
  • Microsoft security

It also lists specialised single-instance templates: Threat intelligence, Fusion and ML behavior analytics.

The practical answer to “which rules first” is therefore about order and fit, not a magic list:

  1. Rules whose data sources you have connected.
  2. The threat intelligence matching rule, which Learn documents with explicit prerequisites.
  3. Everything else from installed solutions, enabled deliberately and tuned.

Learn also says custom detections are the best way to create new rules across Sentinel SIEM and Defender XDR. Built-in templates are still the sensible starting point. Come back to custom detections once the template baseline is running and you have a gap to fill.

Who is affected

  • SOC and security engineers who own detection coverage in Sentinel.
  • Platform teams that have just connected a workspace and have data flowing but few rules switched on.
  • Anyone running Sentinel through the Defender portal, or planning to.

On the Defender portal, Learn’s Sentinel-in-the-Defender-portal page says that after 31 March 2027 Microsoft Sentinel is no longer supported in the Azure portal and is available only in the Defender portal. Confirm where your own tenant stands in your Message Center and in the portal you use today. Separately, the onboarding page says that in many cases customers onboarding to Sentinel after 1 July 2025 are automatically onboarded to the Defender portal.

Why it matters

  • Coverage follows connectors. Learn advises enabling all rules associated with your connected data sources to get full coverage. See Sentinel cost control for the cost side of connecting data sources.
  • Rule types change in the Defender portal. Learn says Microsoft security rules are not available if you enabled Defender XDR incident integration or onboarded Sentinel to the Defender portal. Defender XDR creates the incidents instead, and such rules you defined earlier are automatically disabled.
  • Fusion is hands-off. The Advanced multistage attack detection rule is enabled by default where available. Only one instance can exist and its logic is hidden, so you cannot customise it. Learn also lists it among the rules not available after Defender portal onboarding.
  • Tuning is part of the job. Learn documents two false-positive methods and a Preview tuning feature, covered in the runbook below.

Decisions to make

DecisionWhat the sources support
Which templates firstThose matching connected data sources. Learn says the Create rule button may be disabled, or show a message, if a required data source is not enabled.
Incident creation from Microsoft alertsPortal-dependent. In an Azure-portal workspace, use the connector page’s Create incidents – Recommended option. In the Defender portal, Defender XDR creates the incidents.
Scheduled or NRTNRT rules suit fast detection but carry limits (see below). Use scheduled rules unless you need NRT.
Tuning approachAutomation rules for temporary exceptions. Query changes, ideally with a watchlist, for permanent ones.
Sources outside Defender XDRUse scheduled analytics rules instead of incident creation rules. See the pitfalls.

Runbook

  1. Check roles

    Learn’s roles page says installing and managing content hub content needs Microsoft Sentinel Contributor at resource group level. Creating or editing analytics rules also needs Microsoft Sentinel Contributor. Reader and Responder cannot do it. Assign the role at the resource group that contains the workspace.

    Onboarding a workspace to the Defender portal is a separate permission set. Learn says it needs at least Security Administrator in Entra ID, plus either an unconditional Owner assignment at subscription scope, or User Access Administrator and Microsoft Sentinel Contributor. If the tenant has more than one Sentinel workspace, Security Administrator is also required. Read the onboarding page before you start.

  2. Work out which portal you are in

    Check whether your workspace is onboarded to the Defender portal. In the Defender portal, Sentinel settings sit under System > Settings > Microsoft Sentinel. This decides which rule types apply to you, so settle it before you enable anything.

  3. Install the solutions for your data sources

    Templates come from content hub solutions. For each connector you have connected, install the matching solution. Choose the solutions from what your own connectors cover.

  4. Open the rule templates

    • Defender portal: go to Microsoft Sentinel > Configuration > Analytics, then the Rule templates tab.
    • Azure portal: go to Configuration > Analytics > Rule templates.

  5. Enable rules from templates

    Select a template, then Create rule on the details pane. The wizard opens autofilled. Learn says required data sources are checked automatically, and Create rule may be disabled if one is not enabled. Learn also says the most efficient way to enable all rules for a connected source is from the data connector page, which lists the related rules.

    Record why you enabled each rule and who owns its alerts.

  6. Add the threat intelligence matching rule

    Learn’s matching analytics page describes the Microsoft Defender Threat Intelligence Analytics rule. It matches Microsoft threat intelligence domain, IP and URL indicators against your ingested logs.

    Prerequisites from that page:

    • Install one or more supported data connectors, and the content hub solution.
    • You do not need a premium Microsoft Defender Threat Intelligence licence.

    Learn lists supported sources including CEF, Syslog, Windows DNS via AMA, Microsoft 365, Azure activity logs and ASIM Network sessions. Read the page for the full list.

    To enable it, go to Configuration > Analytics > Rule templates and search for “threat intelligence”. Select the template, choose Create rule, then Review > Create. Learn says the rule is read-only and enabled by default.

  7. Handle NRT and anomaly rules with care

    NRT: Learn says these run every minute, with a two-minute delay, on ingestion time. A customer can define no more than 50 NRT rules. They work properly only on sources with ingestion delay under 12 hours. A rule can produce up to 30 single-event alerts. If the query returns more than 30 events, the first 29 get alerts and the 30th summarises the rest.

    Anomaly: Learn says these rules do not generate alerts. They write results to the Anomalies table. Built-in anomaly rule configurations cannot be changed. To tune one, duplicate it and run the duplicate in Flighting mode alongside the original in Production mode.

  8. Plan tuning before alert volume arrives

    Learn describes two methods for false positives:

    • Automation rules add exceptions without editing the analytics rule.
    • Query modifications give more detailed, permanent exceptions and can use watchlists.

    For exceptions inside a query, Learn’s preferred approach is a watchlist called with _GetWatchlist('<watchlist name>'). An analyst can then change the exceptions without editing the rule, and one watchlist can serve several rules.

    On automation-rule exceptions, Learn says the rule expires after 24 hours by default. Set Rule expiration later if the exception needs to last. Learn also says exceptions close incidents with a recorded reason and comment. The “create an automation rule from an incident” workflow is documented as supported in the Azure portal only. In the Defender portal, create the automation rule from scratch.

    Tuning insights are a Preview feature, so they carry preview terms. Learn says rules with a lightbulb icon in Analytics have insights over a 14-day window. They can recommend entities to exclude, based on incidents you closed as false positive. Open the rule in the wizard and look on the Set rule logic tab. Learn’s page describes only the generic Analytics navigation, so check whether the experience matches in your Defender portal.

Checks

  • You know whether the workspace is onboarded to the Defender portal, and the rule types you enabled match that.

  • Every connected data connector has had its related rules reviewed.

  • The Microsoft Defender Threat Intelligence Analytics rule appears under Analytics > Active rules.

  • No rules are enabled for data sources that are not connected.

  • Each enabled rule has a named owner and an agreed route for its alerts.

  • Any automation-rule exception has a Rule expiration that matches the intent, not the 24-hour default.

  • Anomaly tuning uses a duplicate in Flighting mode, with the original left in Production mode.

  • NRT rule count is well below Learn's limit of 50 per customer.

  • Your tenant's Message Center and portal show where the Azure portal move to the Defender portal stands for you.

Rollback

Learn’s create-from-template page says a rule you create from a template appears in the Active rules tab under Analytics. Start there if you enabled a rule by mistake. Learn’s “Create scheduled analytics rules” page says that, for a custom scheduled rule created from scratch, you can enable, disable or delete each rule from the list in the Active rules tab. That passage is written about rules created from scratch. Neither page states that the same options apply to a rule created from a template, so check what your portal offers for the rule, and record the change.

For an exception built as an automation rule, let it expire or remove it. For a watchlist-based exception, Learn says an analyst can change the exceptions without editing the rule, so make the change in the watchlist and confirm the result in your workspace.

Offboarding the workspace from the Defender portal is not a tidy undo. Learn says it also disconnects the Defender XDR connector, if configured, and you must reconnect it to receive Defender XDR incidents in Sentinel again.

Common pitfalls

  • Expecting Microsoft security rules in the Defender portal. Learn says they are not available there, and earlier ones are automatically disabled. Defender XDR creates the incidents.
  • Sources outside Defender XDR. Learn says that for Microsoft sources not integrated into Defender XDR, such as Purview Insider Risk Management, you should replace incident creation rules with scheduled analytics rules before onboarding.
  • Missing alerts in an Azure-portal workspace. Learn says that without incident creation rules, alerts from connected Microsoft security solutions land in the SecurityAlert table and do not create incidents. The connector page has a Create incidents – Recommended Enable button for the default rule, and severity filters can limit which alerts create incidents.
  • Trying to edit a built-in anomaly rule. You cannot. Duplicate it.
  • Assuming the Fusion rule is yours to tune. It is hidden logic, one instance only.
  • Relying on 24-hour exceptions. They lapse by default and the noise comes back.
  • Treating preview tuning insights as settled. Detection tuning is Preview. Treat its suggestions as input to a review, not an automatic exclusion.
  • Alerting twice on break-glass sign-ins. If you already alert on them as set out in break-glass accounts done properly, check for overlap before adding a Sentinel rule for the same sign-ins.