Detection rules in Defender XDR or Sentinel? Building a rule set from scratch without duplicates or noise

Before a detection engineering project at an insurance company, their information security project manager sent us a tidy list of questions. You can build the rules in Defender XDR, in Sentinel or in both, so what goes where? How do you avoid duplicate rules? What are the minimum permissions, and can we use PIM? And what does the final deliverable look like?

These are exactly the questions every organization with Microsoft Defender and Sentinel should ask before writing its first rule, and they come up in almost every Microsoft 365 security project we run. Here are the answers.

Defender XDR or Sentinel: where each rule belongs

The “Defender or Sentinel” question matters less and less. Microsoft is moving Sentinel into the Defender portal (after 31 March 2027 it will only be available there), and incidents from both are already merged into one. Since October 2025 Microsoft recommends building new rules as custom detections, one engine that works on both Defender XDR and Sentinel data. So the real question is where the data the rule needs lives:

Rule type	Where to build it	Why
Suspicious behavior on endpoints and servers	Custom detection on Defender XDR data	The data is already in advanced hunting with no ingestion cost, and you can attach an automatic response such as isolating the device
Unusual identity, email and cloud app activity	Custom detection on Defender XDR data	Feeds straight into the same incident with automatic entity mapping
Fast detections on a single table	Custom detection at near real-time (NRT) frequency	Runs on data as it arrives, with no limit on the number of rules. Limited to one supported table, with no joins
Firewalls, VPN, Linux servers, OT and third-party sources	Sentinel (custom detection or analytics rule on Sentinel data)	This data only lands in Sentinel
Correlation between Defender and external sources	Sentinel	You need both data sources in the same query
Logic that needs months of history	Sentinel, with summary rules or watchlists	A custom detection looks back up to 30 days and an analytics rule up to 14. Long history is built from summaries and lists in Sentinel

Rule of thumb: if the data already exists in Defender XDR, don’t ingest it into Sentinel just to write a rule on it. That saves ingestion costs and avoids the common case where one event raises two alerts from two systems.

There are still cases where an analytics rule is the better fit: automation triggered on incident creation, Content Hub templates, Bicep deployment and multi-workspace rules. Custom detections don’t support these yet.

Start from what’s built in, not a blank page

The most common mistake in a detection project is writing hundreds of custom rules before checking what the product already detects on its own. Defender XDR ships with a large set of built-in detections, and Sentinel with ready-made rule templates. The order we recommend:

Map your sources. Which systems and services you want to monitor, and which Defender products are actually active: Endpoint, Identity, Office 365, Cloud Apps.
Check built-in coverage. What the products already detect today, and what’s in Sentinel’s templates and Content Hub solutions.
Map to MITRE ATT&CK. Map existing detections to techniques, and mark the techniques relevant to your environment. Not every technique matters to every organization.
Gap analysis. The gap between relevant techniques and existing detections is your work list. Every gap becomes a use case.
Prioritize. Start with use cases that cover high risk using data you already have, such as account takeover, privilege escalation and lateral movement.
Write, test and tune. Only now write the custom rules, and test each one before turning it on.

The result is a rule set that complements the product instead of duplicating it.

Permissions: the bare minimum, and only for the work window

At this customer, the security engineer building the rules started the project with Global Reader only. That’s a good starting point: read-only, so you can see everything and change nothing. For Sentinel data you also need Microsoft Sentinel Reader, because access to it is controlled by Azure RBAC. What you add depends on where the rules are built:

Task	Minimum permission	Where it’s set
Create and manage custom detections, alert tuning and IOCs	Detection tuning (manage) in a custom role	Unified RBAC in the Defender portal
Run advanced hunting queries	Security data basics (read)	Unified RBAC in the Defender portal
Create analytics rules on Sentinel data	Microsoft Sentinel Contributor on the workspace’s resource group only	Azure RBAC
Set up automation (playbooks)	Logic App Contributor to build playbooks, Microsoft Sentinel Contributor to attach them to rules, and Microsoft Sentinel Playbook Operator to run them manually	Azure RBAC

The advantage of Detection tuning (manage) is that it lets you manage rules without the broad Core security settings (manage) permission, and certainly without Security Administrator. You may need extra permissions for a specific product’s data, for example when device groups are set up in Defender for Endpoint.

For an outside vendor working in your environment, our recommendation is clear: a custom role with minimum permissions, activated through PIM for the work window only, not a standing assignment. Unified RBAC roles can be assigned to an Entra group, and the group activated through PIM for Groups (requires Entra ID P2). Every activation is logged, and no permissions are left open when the project ends.

Tuning: less noise, more alerts you can act on

A rule whose alerts nobody handles does more harm than good: it trains the SOC to ignore alerts. A few rules that work:

Run it quietly first: run the query over the last 30 days in advanced hunting and see how many results it would have produced. A rule that would have fired hundreds of times a month isn’t ready. Note that a new custom detection runs over the last 30 days as soon as you save it, and can raise up to 150 alerts per run.
Severity by action: High only for what needs an immediate response. Everything else is Medium or Low, or kept for hunting only.
Narrow exclusions: exclude a specific service account, server or process, not a whole folder or a broadly privileged user. Document every exclusion with a reason and an owner.
Entity mapping: define the user, device and IP in every rule, so related alerts merge into one incident instead of ten separate ones.
No duplicates: before writing a rule, check whether a built-in detection already covers it. If it does, improve it with alert tuning instead of writing a new rule.
Regular review: once a quarter, go through the rules by alert volume and false positive rate, and update or turn off what doesn’t earn its place.

The deliverable: a rule catalog

A detection project doesn’t deliver only the rules running in the system, but a catalog that lets the team maintain them after the project ends. Each rule in the catalog records:

Field	What’s recorded
Use case	What the rule detects, in one sentence
Platform	Custom detection or analytics rule, and on which data
KQL query	The full query, under version control
MITRE mapping	The tactic and technique the rule covers
Data sources	The tables and connectors the rule depends on
Severity	And what it’s based on
Frequency	NRT, hourly, daily
Exclusions	What’s excluded and why
Owner	Who owns the rule and handles its alerts
Tuning history	What changed, when and why
Response	An automatic action or a manual runbook

A catalog like this also answers what auditors and regulators ask: what exactly are you monitoring, and how do you know it works?

The bottom line

A good rule set starts with what the product already detects, continues with a gap analysis against MITRE, and builds rules only for the gaps. What runs on Defender XDR data is built as a custom detection, and Sentinel stays for external sources, correlation and long time ranges. Permissions are minimal and go through PIM, and every rule is documented in the catalog.

Planning a detection rules project? Book a call with the OnCloud team and we’ll build the methodology, permissions and priorities that fit your environment.

Book a call