Configure Detections in Microsoft Sentinel

Detection in Sentinel: pick the rule type by latency

A question gives you a detection requirement and a list of analytics rule types, and the fast answer comes from one question: how quickly must this fire, and do you control the logic? Microsoft Sentinel detects threats with analytics rules^[1] that query the logs you have ingested into the Log Analytics workspace and raise an alert when they find what they are looking for. Alerts are then aggregated and correlated into incidents^[2], the case files an analyst investigates.

The rule types share one model: each runs a detection over workspace data and produces a signal, and they differ in cadence and in how much you can edit them.

Scheduled rules^[3] are the workhorse: a Kusto Query Language (KQL) query that runs on an interval you set, examines a lookback window of data, and alerts when the result count passes a threshold. You control everything, so most authored detection is scheduled.
Near-real-time (NRT) rules^[4] are a constrained subset of scheduled rules that run once every minute for the most time-critical signals.
Anomaly rules^[5] use machine learning to baseline a behavior and flag deviation, but they do not raise their own alerts; they record findings in the Anomalies table.
Microsoft security rules^[6] turn alerts that other Microsoft products generate into Sentinel incidents.
Three specialized engines run as a single non-editable instance each: Fusion^[7] (advanced multistage attack correlation), ML behavior analytics, and Microsoft Threat Intelligence Analytics^[8].

One integration rule reshapes this whole list, so learn it now and the rest reconciles: once you enable Microsoft Defender XDR incident integration^[9] or onboard Sentinel to the Defender portal, the Microsoft security and Fusion rule types are not available and are auto-disabled, because Defender XDR creates those incidents instead. That is also why Microsoft now points new detection work at the unified custom detections experience in the Defender portal, which the sibling Defender XDR detections subtopic covers; here you are authoring the Sentinel-native analytics rule.

The durable rule for this objective: scheduled when you own the query and the cadence, NRT when a minute of delay is too much, anomaly or behavioral when there is no signature to match, and Microsoft security only when XDR integration is off.

Sentinel analytics rule selection by need; enabling Defender XDR incident integration auto-disables the Microsoft security and Fusion rule types.

Entities: classify and analyze data with identifiers

An entity^[10] is a data element Sentinel recognizes and classifies as a known type, such as a user account, host, IP address, URL, file, file hash, process, mailbox, or cloud application. Classifying a raw value as an entity is what lets Sentinel ask the right questions about it, correlate it across every alert that mentions it, and carry it through investigation, hunting, and the entity page that aggregates everything known about it. In the Defender portal entities split into two families: assets (internal, protected objects, like accounts and hosts) and other entities or evidence (external indicators of compromise, like IP addresses, files, and URLs).

Identifiers, strong and weak

Each entity type is recognized by identifiers^[11], the fields that pin down a specific instance. A strong identifier names the entity unambiguously on its own, for example a Microsoft Entra account's GUID or its User Principal Name (UPN); a weak identifier (a bare username, an NTDomain) is reliable only in context, though a combination of weak identifiers can together become strong. The reason this matters for detection: when two alerts identify the same user by a shared strong identifier, Sentinel merges them into one entity, so the user correlates across data sources. Identify a user by only a weak identifier such as a username with no domain, and Sentinel cannot merge it, so the same person fragments into separate entities and the correlation breaks. Prefer strong identifiers, and use several where you can.

Entity mapping in the rule

Classification happens through entity mapping^[12], part of the scheduled rule wizard's alert-enhancement step. You add an entity, pick its type, choose an identifier, and bind that identifier to a column the query returns; Sentinel then extracts the value from each alert. The limits are exam-testable:

Limit	Value
Identifiers per entity mapping	up to 3 (at least one required)
Entity mappings per rule	up to 10
Entities per alert (total)	up to 500, divided across mappings
Size of the entities field	64 KB (excess truncated)

You can map more than one entity of the same type, for instance a source IP and a destination IP as two separate IP mappings, and each counts independently against the 500 cap. The catch that trips people: the query must actually return the field you want to map, or it will not appear in the value list. Map entities well and the same accounts, hosts, and IPs populate the investigation graph and feed behavioral analytics; map them poorly and the alert arrives context-free.

Entity mapping binds returned columns to entity types via identifiers; Sentinel merges matching strong identifiers and feeds the investigation graph.

Configure and manage analytics rules

A scheduled analytics rule is more than its query, and SC-200 tests the settings around the KQL. Build it in the analytics rule wizard^[13] or start from a rule template^[14] in the Content hub, which ships expert-written queries you activate and can then customize.

Query, schedule, and threshold

The rule has a run frequency (how often the query executes) and a lookback period (how far back each run reads); the alert threshold fires when the result count crosses the value you set. A core consistency rule: align the lookback to the frequency so you neither miss events between runs nor double-count overlapping windows.

Event grouping

Event grouping decides how query rows become alerts: group all matching events into a single alert, or trigger a separate alert for each row returned (up to 150 alerts per rule run). One alert per row is what you want when each row is an independently investigatable event and you intend to map its entities individually.

Alert grouping into incidents

Separately, incident settings control whether alerts from this rule become incidents and how they are grouped. You can group alerts produced within a chosen time window into a single incident, optionally grouping only when entities or details match, which keeps a noisy rule from spawning hundreds of near-duplicate incidents.

Suppression and MITRE

Turn on query scheduling suppression^[15] to stop a rule re-running for a set period after it fires, useful for a known recurring benign pattern. Tag the rule with MITRE ATT&CK^[16] tactics and techniques so the MITRE coverage view shows where your detections are thin.

Automated response

A rule can carry automated response^[17]: automation rules that run on alert or incident creation (assign owner, change severity, run a playbook) so the rule does more than alert. An access permissions token^[1] is saved with the rule so it keeps reading the workspace even if its author later loses access, except in cross-tenant or cross-subscription rules, where the rule auto-disables when the creating user loses access.

Manage as code

You can export a rule to an Azure Resource Manager (ARM) template^[18] and import rules from template files, the path for deploying detections as code across workspaces.

Scheduled rule pipeline: query and lookback, threshold, event grouping, entity mapping, alert, incident grouping, and automation; suppression can pause re-runs.

Query Sentinel data with ASIM parsers

The same logical attack looks different in every product's logs, and the Advanced Security Information Model (ASIM)^[19] is the layer that hides those differences. ASIM sits between diverse sources and your queries, applying the robustness principle: be strict in what you send, flexible in what you accept. The payoff for detection: write a rule against ASIM once and it works on any current or future source that supports the schema, so a normalized rule catches brute force or impossible travel across Okta, AWS, and Azure with one query.

Schemas and query-time parsers

ASIM has normalized schemas^[20], standard sets of fields for predictable event types, including Authentication, DNS Activity, Network Session, Process Event, Web Session, File Activity, DHCP, Registry, and Audit. Parsers do the mapping, and the key fact is that ASIM parsing happens at query time^[21]: parsers are KQL user-defined functions that transform existing tables (CommonSecurityLog, Syslog, custom logs) into a schema view without touching the stored data. You query the parser name instead of the raw table name. Because nothing is rewritten, a parser fix applies retroactively to data already collected.

The naming convention to memorize

ASIM has two parser levels. The unifying parser, named _Im_<schema> (for example _Im_Dns, _Im_Authentication), is what you normally call: it queries all sources for that schema by calling each source-specific parser underneath. Source-specific parsers follow _Im_<schema>_<source>V<version> and can be used alone when you want one source. The _Im_ parsers are parameterized, meaning they accept filtering parameters (such as a time range or a field value) that push the filter down for performance on large data sets. A parallel set named _ASim_<schema> exists too, but it does not support filtering parameters and is kept only for backward compatibility, so for new work prefer the _Im_ filtering parsers. Built-in parsers ship in every workspace; workspace-deployed parsers (deployed from GitHub by ARM template) are functionally equivalent with slightly different names, used during parser development.

The exam's distinction to keep straight: filtering (_Im_, parameterized) parsers are the performant default; non-filtering (_ASim_) parsers are legacy and slower because the filter cannot be applied at the source.

Ingest-time normalization

Query-time parsing can slow very large queries, so Sentinel complements it with ingest-time normalization into native tables such as ASimDnsActivityLogs, ASimAuthenticationEventLogs, and ASimNetworkSessionLogs, populated by data collection rule transformations. Querying those tables is faster because the normalization is already done.

An ASIM unifying Im parser normalizes many source tables to one schema at query time, so a single rule detects across all of them.

Implement behavioral analytics (UEBA)

Some attacks have no signature, only a person behaving unlike themselves, and User and Entity Behavior Analytics (UEBA)^[22] is the detection layer for them. UEBA uses machine learning to build dynamic behavioral profiles for users, hosts, IP addresses, applications, and other entities, then flags activity that deviates from the entity's own baseline, its peer group, and the organization. That three-ring context (the entity, its peers, the org) is how it surfaces compromised accounts, insider attacks, and lateral movement.

Enable it and feed it

You enable UEBA^[23] and connect the sources it learns from: Microsoft Entra ID sign-in and audit logs, Security events, Microsoft Defender for Identity, and Office 365 activity. It is built into Sentinel and the Defender portal, and it is included with Sentinel at no extra charge; you pay only for the Log Analytics storage of the tables it writes.

UEBA writes tables, it does not alert

The rule to keep straight: classic analytics rules raise alerts, but UEBA enriches data into tables you query and correlate, rather than raising its own alerts. The tables an SC-200 candidate should recognize:

Table	What it holds	Score
`BehaviorAnalytics`	Per-event behavioral enrichment with geolocation and threat intel	`InvestigationPriority` 0 to 10
`Anomalies`	Events flagged anomalous by the ML engine	`AnomalyScore` 0 to 1
`IdentityInfo`	Detailed entity profiles (users, devices, groups)	from Entra ID, optionally on-prem AD via Defender for Identity
`UserPeerAnalytics`	Dynamically computed peer groups	top 20 peers, TF-IDF weighting

Two scores, two jobs

The scores answer different questions. InvestigationPriority (0 to 10, in BehaviorAnalytics) is near-real-time and event-level: how unusual is this single event, combining how rare the entities are with abnormal time-series patterns; use it for quick triage. AnomalyScore (0 to 1, in Anomalies) is batch and behavior-level: holistic anomaly across many events via ML. They correlate but are not the same, and a classic example shows why: a user's first-ever Azure operation scores high investigation priority (a first-time event) yet low anomaly score (occasional first-time actions are common and not inherently risky).

UEBA vs anomaly rules

Do not confuse the two ML detections. UEBA is the always-on profiling engine that populates these tables and enriches investigations; customizable anomaly analytics rules are individual templates you enable (and can duplicate to tune in Flighting mode) that write to the Anomalies table. The blueprint's behavioral-analytics requirement is satisfied by enabling UEBA, installing the UEBA Essentials hunting solution, and joining these tables into your detections and hunts.

UEBA baselines each entity against itself, its peers, and the organization, writing scored tables (it enriches data; it does not raise its own alerts).

Exam pattern recognition

Sentinel detection questions cluster into four shapes. Read for the keyword, then map.

Rule-type stems

The stem describes a requirement and asks which rule type. "Detect a condition within a minute" is a near-real-time (NRT) rule (runs every minute), not a scheduled rule on a short interval. "Flag behavior that deviates from a learned baseline" is an anomaly rule or UEBA, not a threshold-based scheduled rule. "Create Sentinel incidents from Defender for Cloud alerts" is a Microsoft security rule, but watch the qualifier: if Defender XDR incident integration is enabled, that rule type is gone and XDR makes the incidents. "Correlate low-fidelity alerts across products into one high-fidelity incident" is Fusion (advanced multistage attack detection).

Entity-mapping stems

When a scenario complains that alerts arrive without user or host context, or that the same user does not correlate across rules, the answer is entity mapping, and often the fix is using a strong identifier (UPN or GUID) instead of a weak one (a bare username) so Sentinel can merge the entity. Recall the numbers when offered as distractors: up to 10 mappings, 3 identifiers each, 500 entities and 64 KB per alert.

ASIM stems

"Write one detection that works across many log sources" points to ASIM and a normalized schema, and the right call is the unifying _Im_<schema> parser. A finer trap distinguishes _Im_ (filtering, parameterized, performant, the default) from _ASim_ (no filtering parameters, backward compatibility only): choose _Im_ for new work. If the stem asks why a query is slow over huge data, ingest-time normalization into the native ASim...Logs tables is the speed answer.

Behavioral-analytics stems

"Detect a compromised account, insider, or lateral movement with no signature" is UEBA. If the stem asks where the signal lands, remember UEBA writes tables rather than alerts: BehaviorAnalytics (InvestigationPriority 0 to 10) for near-real-time event triage and Anomalies (AnomalyScore 0 to 1) for ML behavior-level anomalies, with IdentityInfo for entity profiles. The classic distractor is expecting a UEBA alert to appear in the queue; instead you query and join its tables.

Which Microsoft Sentinel analytics rule type to choose

Rule type	What it does	Cadence / latency	Raises an alert?	Customizable?
Scheduled	Runs your KQL query over a lookback window and alerts past a threshold	Interval you set (minutes to days)	Yes, creates alerts and incidents	Fully (query, schedule, threshold, mapping)
Near-real-time (NRT)	Constrained scheduled rule for time-critical detection	Every 1 minute, fixed	Yes, creates alerts and incidents	Yes, with NRT-specific limits
Anomaly	ML baselines a behavior and flags deviation	Continuous, after a learning period	No, writes to the Anomalies table	Duplicate then tune; run as Flighting vs Production
Microsoft security	Turns another Microsoft product's alerts into Sentinel incidents	Real time as alerts arrive	Creates incidents from existing alerts	Limited (filter by product/severity)
Fusion / ML behavior / Threat intelligence	Built-in correlation and matching engines	Continuous, Microsoft-managed	Yes, high-fidelity incidents/alerts	No, single non-editable instance each

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Scheduled analytics rules are the workhorse: KQL query on an interval with a threshold

A Microsoft Sentinel scheduled analytics rule runs a KQL query against the workspace tables on a frequency you set, reads a lookback window of data, and raises an alert when the result count crosses a threshold. It is the rule type you reach for whenever you author detection logic yourself, because you control the query, the cadence, the threshold, entity mapping, and the response. Align the lookback to the run frequency so events between runs are neither missed nor double-counted.

Use a near-real-time (NRT) rule when one minute of delay is too much

Near-real-time rules are a constrained subset of scheduled rules that run once every minute, the lowest latency Sentinel offers for query-based detection. Choose NRT only when the requirement is sub-minute detection, because it carries feature limits a full scheduled rule does not, such as a maximum of 50 NRT rules per workspace and producing up to 30 single-event alerts per run. For ordinary detection where a few minutes is fine, a scheduled rule is the right default.

Trap Setting a scheduled rule to a very short interval to fake real time; NRT is the purpose-built once-a-minute rule type, and a short scheduled interval still incurs scheduled-rule latency.

4 questions test this

Anomaly rules write to the Anomalies table instead of raising alerts

An anomaly analytics rule uses machine learning to learn a baseline over an observation period, then flags behavior outside that baseline, but it does not generate its own alerts; it records findings in the Anomalies table for you to query and join into detections. You cannot edit a built-in anomaly rule directly, so to tune one you duplicate it, run the copy in Flighting mode alongside the original in Production, then promote the copy if you like the results.

Trap Expecting an anomaly rule to drop alerts into the incident queue; it populates the Anomalies table, and you bring that context into other rules or hunts.

7 questions test this

Microsoft security rules turn other Microsoft products' alerts into Sentinel incidents

A Microsoft security analytics rule creates Microsoft Sentinel incidents in real time from alerts that other Microsoft solutions generate, since externally generated alerts do not create their own incidents. The decisive caveat: this rule type is unavailable, and existing ones auto-disable, once you enable Defender XDR incident integration or onboard Sentinel to the Defender portal, because Defender XDR then creates the incidents itself.

Trap Choosing a Microsoft security rule to create incidents when Defender XDR incident integration is already on; that rule type is disabled in that state and XDR makes the incidents.

Fusion correlates many low-fidelity signals into high-fidelity multistage incidents

Advanced multistage attack detection, the Fusion engine, uses scalable machine learning to correlate low-fidelity alerts and events across multiple products into a small number of high-fidelity, actionable incidents. It is enabled by default, runs as a single non-editable instance because its logic is hidden, and like the Microsoft security rule it is unavailable once Defender XDR incident integration is enabled.

Trap Reaching for a scheduled rule to tie together alerts from several products into one incident; cross-product multistage correlation is exactly what Fusion does automatically.

Entities classify alert data into types Sentinel can correlate and investigate

An entity is a data element Sentinel recognizes as a known type, such as Account, Host, IP, URL, File, File hash, Process, or Mailbox, which lets it correlate that element across every alert and surface it in the investigation graph and entity pages. In the Defender portal entities split into assets (internal protected objects like accounts and hosts) and other entities or evidence (external indicators like IPs, files, and URLs).

Prefer strong identifiers so Sentinel merges the same entity across sources

A strong identifier names an entity uniquely on its own, such as an Entra account's GUID or its User Principal Name (UPN); a weak identifier like a bare username or NTDomain is reliable only in context, though several weak identifiers can combine into a strong one. This matters because Sentinel merges two alerts that share a strong identifier into one entity, so the user correlates across data sources; identify a user by a weak identifier alone and the same person fragments into separate, uncorrelated entities.

Trap Mapping a user by username only when a UPN or GUID column is available; the bare username is a weak identifier and Sentinel cannot reliably merge it across sources.

7 questions test this

Entity mapping limits: up to 10 mappings, 3 identifiers each, 500 entities per alert

Entity mapping in a scheduled rule binds query columns to entity types via identifiers. The testable limits: up to 10 entity mappings per rule, up to 3 identifiers per mapping with at least one required, and at most 500 entities collectively per alert, divided across the mappings, inside a 64 KB entities field that truncates beyond that. You can map several entities of the same type, for example a source IP and a destination IP as two IP mappings, and each counts separately toward the 500.

4 questions test this

Map only columns the query actually returns

Entity mapping can bind an identifier only to a field that the rule's KQL query returns, so a column you want to map must be projected by the query or it will not appear in the value list. This is the common reason an alert arrives without expected user or host context: the field was never returned, so it could not be mapped to an entity.

Trap Assuming an entity will populate from a field the query filters on but does not return; mapping needs the column in the result set, not just in the where clause.

ASIM normalizes many sources to one schema so a single rule detects across all of them

The Advanced Security Information Model (ASIM) is a query-time layer of KQL parser functions that map disparate source tables onto normalized schemas, so detection written against schema fields works on any current or future source that supports that schema. That is why one ASIM-based rule can catch brute force or impossible travel across Okta, AWS, and Azure at once, and why built-in ASIM content automatically expands to new sources without a rewrite.

Call the unifying Im parser to query all sources for a schema

ASIM has two parser levels. The unifying parser, named _Im_<schema> (for example _Im_Dns or _Im_Authentication), is the one you normally query: it calls every source-specific parser underneath so your query covers all sources for that schema. Source-specific parsers follow _Im_<schema>_<source>V<version> and can be used alone when you want a single source. You query by parser name in place of the raw table name.

Trap Querying a raw source table directly when the goal is cross-source coverage; only the unifying Im parser pulls in every source for that schema.

2 questions test this

Use the filtering Im parsers, not the legacy ASim ones

The _Im_ ASIM parsers are parameterized, meaning they accept filtering parameters such as a time range or field value that push the filter down to the source for performance on large data sets. A parallel set named _ASim_<schema> does not support filtering parameters and exists only for backward compatibility, so it is slower. For new detection work, prefer the filtering _Im_ parsers.

Trap Using an ASim parser for new work; it has no filtering parameters and is kept only for backward compatibility, so it scans more than the parameterized Im parser.

ASIM parsing happens at query time, so fixes apply to data already stored

ASIM parsers are KQL user-defined functions that transform existing tables into a normalized view at query time, without modifying the stored source data. Because nothing is rewritten on ingest, a parser can be developed and tested against existing data, and a fix to a parser applies retroactively to data already collected. When query-time parsing is too slow on very large data, Sentinel offers ingest-time normalization into native tables like ASimDnsActivityLogs for faster queries.

ASIM schemas cover the common event types you detect on

ASIM defines normalized schemas for predictable event categories including Authentication, DNS Activity, Network Session, Process Event, Web Session, File Activity, DHCP, Registry, and Audit. Writing a detection against one of these schemas (through its parser) is what makes the rule source-agnostic, because every schema defines the same field names regardless of which product produced the event.

UEBA detects the no-signature threat by baselining normal behavior

User and Entity Behavior Analytics (UEBA) builds dynamic ML behavioral profiles for users, hosts, IP addresses, and other entities, then flags activity that deviates from the entity's own history, its peer group, and the organization. That three-ring context is how it surfaces compromised accounts, insider attacks, and lateral movement that a static threshold rule cannot express. You enable UEBA and connect its feeding sources: Entra ID sign-in and audit logs, Security events, Defender for Identity, and Office 365.

1 question tests this

You have a Microsoft Sentinel workspace. You enable UEBA and configure Microsoft Entra ID as the directory service with the supported data…

UEBA enriches tables; it does not raise its own alerts

Unlike scheduled and NRT rules, UEBA does not generate alerts in the incident queue. It writes enrichment into tables you query and join into detections and hunts: BehaviorAnalytics for per-event behavioral data, Anomalies for ML-flagged anomalous events, IdentityInfo for entity profiles, and UserPeerAnalytics for computed peer groups. The way to act on UEBA is to query these tables, often joining the Anomalies table into a hunting or detection query.

Trap Waiting for a UEBA alert to appear in the queue; UEBA surfaces signal through its tables, so you query BehaviorAnalytics and Anomalies rather than triaging UEBA alerts.

1 question tests this

You have a Microsoft Sentinel workspace with UEBA enabled. During an incident investigation, you need to determine which users are…

Two UEBA scores: InvestigationPriority 0-10 and AnomalyScore 0-1

UEBA exposes two scores for different jobs. InvestigationPriority, in the BehaviorAnalytics table, runs 0 to 10 and is near-real-time and event-level, combining how rare the entities are with abnormal time-series patterns, so it suits quick triage of a single event. AnomalyScore, in the Anomalies table, runs 0 to 1 and is batch and behavior-level, a holistic ML anomaly across many events. A first-ever Azure action scores high investigation priority yet low anomaly score, which shows why both exist.

4 questions test this

Do not confuse UEBA with anomaly analytics rules

UEBA is the always-on profiling engine that populates BehaviorAnalytics, Anomalies, IdentityInfo, and UserPeerAnalytics and enriches investigations org-wide. Anomaly analytics rules are individual customizable templates you enable per behavior, which also write to the Anomalies table and can be duplicated to tune in Flighting mode. The blueprint's behavioral-analytics requirement is met by enabling UEBA, installing the UEBA Essentials hunting solution, and joining these tables into detections.

Trap Treating enabling a single anomaly rule template as the same as enabling UEBA; UEBA is the broader profiling engine, separately enabled, that feeds the entity-behavior tables.

IdentityInfo profiles entities from Entra ID and optionally on-prem AD

The IdentityInfo table holds detailed profiles of entities (users, devices, groups), built from Microsoft Entra ID and, optionally, on-premises Active Directory synchronized through Microsoft Defender for Identity. It is the table you join to enrich an alert's account with role, group membership, and manager context during investigation, which is why connecting Entra ID and Defender for Identity is part of getting full value from UEBA.

1 question tests this

You have a Microsoft Sentinel workspace with User and Entity Behavior Analytics (UEBA) enabled. Your organization has a hybrid identity…

Event grouping decides single alert vs one alert per row

A scheduled rule's event-grouping setting controls how query rows become alerts: group all matching events into a single alert, or trigger a separate alert for each row returned, up to 150 alerts per rule run. Choose one alert per row when each row is an independently investigatable event whose entities you want mapped individually; group into a single alert when the rows are facets of one finding.

Trap Leaving event grouping at single alert when each returned row is a distinct incident to investigate; you then lose per-row entities and per-event triage.

1 question tests this

You have a Microsoft Sentinel workspace. You create a scheduled analytics rule with a KQL query that returns individual sign-in failure…

Group alerts into incidents to keep a noisy rule from flooding the queue

A rule's incident settings decide whether its alerts create incidents and how they group. You can fold alerts produced within a chosen time window into a single incident, and optionally group only when entities or details match, so a chatty rule produces one incident per campaign rather than hundreds of near-duplicates. This is distinct from event grouping, which is about rows-to-alerts; incident grouping is about alerts-to-incidents.

Trap Confusing event grouping (rows into alerts) with alert grouping (alerts into incidents); they are separate settings that solve different noise problems.

2 questions test this

Suppression pauses a rule after it fires for a known recurring pattern

Query scheduling suppression stops a scheduled rule from re-running for a set period after it triggers, useful when a benign pattern would otherwise re-alert every interval. Tag rules with MITRE ATT&CK tactics and techniques so the MITRE coverage view shows where detection is thin, and attach automation rules or playbooks to act on alert or incident creation, for example to assign an owner or change severity.

Start from Content hub rule templates, then customize

Rather than writing every detection from scratch, activate analytics rule templates from solutions in the Content hub; these carry expert-written KQL designed around known threats, and you can customize the query, schedule, and threshold after activating. Export a finished rule to an Azure Resource Manager (ARM) template to manage and deploy detections as code across workspaces, and import rules from template files to edit them in the UI.

3 questions test this

A scheduled rule's query interval must be shorter than or equal to its lookback period

In a Sentinel scheduled analytics rule, 'Run query every' (interval) cannot exceed 'Lookup data from the last' (lookback); the lookback must be longer than or equal to the interval, otherwise validation fails because gaps would be left where events are never examined.

Trap Both 'Run query every' and 'Lookup data from the last' accept the same range, 5 minutes to 14 days; the lookback just can't be set shorter than the interval.

4 questions test this

Workspace-deployed source-specific ASIM parsers use vim for filtering and ASim<...> for parameter-less

For each schema, a workspace-deployed source-specific ASIM parser comes in two versions: the filtering (parameterized) parser named vim (for example vimDnsInfobloxNIOS) and the parameter-less parser named ASim (for example ASimDnsInfobloxNIOS).

Trap Confusing these source-specific names with the unifying parsers a query normally calls: workspace-deployed unifying parsers are im, and the built-in unifying parsers are Im (filtering) and ASim (parameter-less).

5 questions test this

Private IP addresses need the AddressScope identifier to be strongly identified

For private, non-globally-routable IP addresses (RFC 1918), the Address identifier alone is a weak identifier, so the same address is not reliably correlated across alerts. Map both Address and AddressScope on the IP entity to make it a strong identifier.

Trap AddressScope is only needed for private IPs; public/global addresses are strongly identified by Address alone.

4 questions test this

Use the MITRE ATT&CK page's Simulated rules menu to preview coverage from not-yet-configured detections

On the MITRE ATT&CK page under Threat management, select items in the Simulated rules menu to project your possible coverage if you configured all available-but-not-yet-enabled detections, so you can find gaps before turning rules on.

Trap By default the matrix shows only currently active scheduled-query and NRT rules; Simulated is what models the prospective coverage from available detections.

4 questions test this

Detection in Sentinel: pick the rule type by latency

Entities: classify and analyze data with identifiers

Identifiers, strong and weak

Entity mapping in the rule

Configure and manage analytics rules

Query, schedule, and threshold

Event grouping

Alert grouping into incidents

Suppression and MITRE

Automated response

Manage as code

Query Sentinel data with ASIM parsers

Schemas and query-time parsers

The naming convention to memorize

Ingest-time normalization

Implement behavioral analytics (UEBA)

Enable it and feed it

UEBA writes tables, it does not alert

Two scores, two jobs

UEBA vs anomaly rules

Exam pattern recognition

Rule-type stems

Entity-mapping stems

ASIM stems

Behavioral-analytics stems

Which Microsoft Sentinel analytics rule type to choose

Decision tree

Cheat sheet

References