Sentinel Analytics & Threat Intelligence

Analytics rules: the Sentinel detection engine

The four analytics rule types

Each rule type serves a different detection need — use all four for comprehensive coverage

Feature	Scheduled	NRT	Threat Intelligence	Machine Learning
Query language	Full KQL	Simplified KQL (some operators restricted)	Automatic (no query needed)	Automatic (built-in models)
Frequency	5 min to 14 days	Every ~1 minute	Continuous matching	Configurable
Latency	Minutes to hours	Seconds to ~1 minute	Near real-time	Varies
Customisation	Full — write any KQL logic	Limited — no joins, limited operators	None — rule matches indicators against data	Tune thresholds and parameters
Best for	Complex, multi-table detection logic	Time-critical single-table detections	Known IOC matching (IPs, domains, hashes)	Detecting unknown behavioural anomalies
Entity mapping	Yes — full control	Yes — full control	Automatic	Automatic

Scheduled rules (most common)

Scheduled rules are the workhorses. You write a KQL query, set the frequency, define the lookback window, and map entities.

Key configuration:

• Query frequency — how often the rule runs (e.g., every 5 minutes)
• Lookback period — how far back in time the query searches (e.g., last 5 minutes)
• Alert threshold — minimum results to trigger (e.g., greater than 0)
• Entity mapping — connect query columns to Sentinel entities
• Event grouping — group all events into one alert, or create one alert per result

Example: brute force detection

SigninLogs
| where TimeGenerated > ago(5m)
| where ResultType == "50126"  // Invalid username or password
| summarize FailedAttempts = count() by UserPrincipalName, IPAddress
| where FailedAttempts > 10

NRT rules (near-real time)

NRT rules sacrifice flexibility for speed. They run every minute with almost zero lag.

Restrictions compared to scheduled:

• No cross-resource queries
• No joins with other tables
• Limited operators
• Only one table per query

Best for: single-table, time-critical detections like “admin account logged in from a new country” or “high-severity alert from a critical server.”

Threat intelligence rules

TI rules automatically match your ingested threat indicators against incoming data. No KQL required — you configure which indicator types to match and which data tables to search.

Machine learning rules

ML rules use Microsoft’s behavioural models to detect anomalies — unusual patterns that rules-based logic might miss. Examples: unusual login times, abnormal data volumes, first-time access to sensitive resources.

💡 Exam tip: NRT vs scheduled

The exam tests whether you know when to use NRT vs scheduled:

• “Detect X within minutes” → NRT (if the logic is simple and single-table)
• “Correlate events across multiple tables” → Scheduled (NRT does not support joins)
• “Detect anomalous behaviour” → ML rules
• “Match known IOCs” → Threat intelligence rules

Threat intelligence ingestion

Before TI rules can detect anything, you need threat indicators in Sentinel.

Ingestion methods

Method	Source	What It Provides
Microsoft Defender Threat Intelligence (MDTI)	Microsoft’s own TI	High-fidelity indicators from Microsoft’s security research
STIX/TAXII feeds	Industry threat intel sharing (ISACs, open-source feeds)	IP addresses, domains, file hashes, URLs from community sources
Threat Intelligence Platforms (TIPs)	Commercial TI (Recorded Future, Anomali, MISP)	Enriched indicators with context and confidence scores
Threat Intelligence Upload Indicators API	Manual or scripted upload	Custom indicators from your own research
Manual indicators	Sentinel TI blade	Individual indicators added by analysts

Indicator lifecycle

Every indicator has:

• Type — IP, domain, URL, file hash, email address
• Confidence — how reliable the indicator is (0-100)
• Valid from/to — time window the indicator is active
• Threat type — malware, C2, phishing, botnet, etc.
• Source — where the indicator came from

💡 Scenario: Anika's TI setup for Sentinel Shield

Anika configures threat intelligence for her MSSP clients:

• MDTI connector — enabled for all workspaces (high-quality Microsoft indicators)
• STIX/TAXII feed from the Financial Services ISAC (FS-ISAC) — for financial clients only
• Custom indicators — Anika’s team adds IOCs from their own incident investigations via the Upload API
• TI analytics rule — matches all ingested indicators against CommonSecurityLog (firewall), Syslog, and SigninLogs

When a client’s firewall logs show a connection to a known C2 IP from the FS-ISAC feed, an incident is automatically created.

Question

What are the four types of Sentinel analytics rules?

Click or press Enter to reveal answer

Answer

1. Scheduled — KQL queries on a configurable schedule. 2. NRT (Near-Real Time) — simplified queries running every minute. 3. Threat Intelligence — automatic IOC matching against log data. 4. Machine Learning — behavioural anomaly detection using Microsoft's models.

Click to flip back

Question

Why would you choose an NRT rule over a scheduled rule?

Click or press Enter to reveal answer

Answer

NRT rules run every ~1 minute with minimal latency, making them ideal for time-critical detections. However, they cannot use joins, cross-resource queries, or some KQL operators. Choose NRT when speed matters more than query complexity.

Click to flip back

Question

What are three ways to ingest threat indicators into Sentinel?

Click or press Enter to reveal answer

Answer

1. Microsoft Defender Threat Intelligence (MDTI) connector — Microsoft's own TI. 2. STIX/TAXII feeds — industry and open-source threat intel. 3. Threat Intelligence Upload Indicators API — custom/manual indicators from your own research.

Click to flip back

Knowledge Check

Anika needs a detection that alerts within 60 seconds when an admin account logs in from a new country. The logic only involves the SigninLogs table. What rule type should she use?

AScheduled rule running every 5 minutesBThreat intelligence analytics ruleCNRT (near-real time) analytics ruleDMachine learning anomaly rule

Check Answer

Knowledge Check

James wants to detect when any device in Pacific Meridian connects to a known command-and-control IP address from a threat intelligence feed. What should he configure?

AA scheduled analytics rule with a hardcoded list of IPsBAn NRT rule checking DeviceNetworkEvents for specific IPsCA threat intelligence analytics rule with TI indicators ingested from a STIX/TAXII feedDA custom detection rule in Defender XDR

Check Answer

Knowledge Check

Anika has an NRT rule detecting admin logins from new countries. It fires 15 times per week — 13 are legitimate VPN connections from travelling executives. She wants to reduce noise without losing detection for real attacks. What is the BEST approach?

AChange the NRT rule to a scheduled rule running every 24 hoursBDisable the analytics rule entirely — it generates too many false positivesCAdd exclusions for the known executive accounts in the rule query, and create a separate rule for those accounts with a higher thresholdDConvert it to a threat intelligence matching rule

Check Answer

🎬 Video coming soon

Next up: Your detections are running. But how do you know if they actually cover the threats that matter? Let’s map your coverage against the MITRE ATT&CK framework.