DE1.1 Sentinel Analytics Rule Types

Five rule types, five architectures

Sentinel analytics rules are not a single mechanism. They are five distinct mechanisms that share a common interface (the Analytics blade in the Sentinel portal) but differ fundamentally in how they execute, what they can query, and what operational characteristics they produce.

Figure DE1.1 — Five Sentinel analytics rule types with architecture characteristics. Scheduled rules are the primary detection engineering mechanism. NRT rules serve critical, high-confidence detections. The remaining three types complement custom rules but do not replace them.

Scheduled rules: the detection engineer’s primary tool

Scheduled rules execute a KQL query on a configurable timer. The query runs against the Sentinel workspace, and if the results meet the trigger condition (typically: at least 1 row returned), an alert is created. The alert is mapped to entities, tagged with MITRE ATT&CK techniques, assigned a severity, and grouped into an incident.

Scheduled rules are the most flexible and most powerful rule type. They can query any table in the workspace — Microsoft telemetry, third-party logs, custom tables. They support full KQL including joins, aggregations, time-series functions, and subqueries. They provide complete control over entity mapping, severity, and alert content. Over 90% of the detection rules you build in this course will be scheduled rules.

The key architectural decisions for scheduled rules are: query logic (what the KQL looks for), frequency (how often the query runs), lookback window (how far back the query searches), trigger threshold (how many results constitute a detection), entity mapping (what fields are extracted as entities for correlation), and severity (how the alert is prioritized in the SOC queue). DE1.2 and DE1.3 cover these in detail.

NRT rules: sub-minute detection

Near-Real-Time rules sacrifice flexibility for speed. They run approximately every minute against the most recent events (since the last run). They do not support joins, aggregations, or time-series functions. They trigger on any row returned — no threshold configuration. They are limited to a subset of tables.

The trade-off is explicit: NRT rules detect faster but with simpler logic. A scheduled rule can correlate events across multiple tables with time-windowed joins — detecting that a risky sign-in occurred AND the user created an inbox rule AND the user sent a suspicious email within 60 minutes. An NRT rule cannot do this. An NRT rule can detect a single high-confidence event: vssadmin.exe deleting shadow copies, a process accessing LSASS memory, or a known malicious command-line pattern.

Use NRT for detections where sub-minute latency matters and the detection logic is a single-event pattern. Use scheduled rules for everything else. DE1.6 covers NRT architecture in depth.

Microsoft Security rules: vendor alert integration

Microsoft Security rules are not custom detections — they are alert pass-through mechanisms. They import alerts from Microsoft security products (Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, Entra ID Protection) and create Sentinel incidents from them. No custom KQL. No entity mapping control. The alert arrives as-is from the source product.

These rules are essential for integrating vendor detection into your Sentinel incident queue. Without them, Defender XDR alerts remain in the Defender portal and Sentinel only sees what custom rules detect. With them, the SOC operates from a single incident queue in Sentinel that contains both vendor alerts and custom detection alerts.

Configure Microsoft Security rules for each Defender product you use. Filter by severity if the low-severity vendor alerts create noise (common with Defender for Endpoint informational alerts). These rules are part of your detection library but they are not detection engineering — they are integration configuration.

Anomaly rules: behavioral baselines

Anomaly rules use machine learning to detect deviations from established behavioral baselines. Sentinel provides built-in anomaly templates (unusual sign-in location, anomalous number of resources accessed, first-time access to a resource). You enable them, configure the sensitivity threshold (high sensitivity = more detections + more false positives, low sensitivity = fewer of both), and let the ML model build a baseline during a learning period (typically 14-21 days).

Anomaly rules produce anomaly records in the Anomalies table — not direct alerts. To create incidents from anomaly detections, you build a scheduled rule that queries the Anomalies table and applies additional filtering. This two-stage pattern (anomaly model flags unusual behavior → scheduled rule applies context to determine if it is malicious) is the recommended architecture for behavioral detection.

Fusion: multi-stage ML correlation

Fusion is Sentinel’s built-in multi-stage attack detection engine. It correlates low-confidence signals from multiple data sources to identify attack patterns that no single alert would surface. Fusion detects known multi-stage attack scenarios (credential theft followed by data exfiltration, lateral movement followed by ransomware) by recognizing the correlation pattern across alerts and anomalies.

Fusion is enabled or disabled — there is no custom configuration beyond on/off. It operates on Microsoft’s ML models, which are updated as new attack patterns are characterized. It is a valuable complement to custom detection but it cannot be engineered — it is a vendor capability that runs alongside your custom rules.

NE rule type breakdown: what 23 rules actually look like

Northgate Engineering’s 23 analytics rules break down as follows:

12 Scheduled (template). Microsoft-provided rule templates enabled during the 2023 Sentinel deployment. Templates include: “Multiple failed sign-ins from single IP” (password spray), “Suspicious sign-in from unknown location” (impossible travel), “New inbox rule created” (persistence), “High severity alert from any product” (pass-through), and 8 others. None have been modified from their default configuration — the KQL, thresholds, frequency, lookback, entity mapping, and severity are all template defaults. These 12 rules cover approximately 8 distinct ATT&CK techniques.

7 Scheduled (custom). Written by Rachel Okafor (CISO) during 2024 in response to specific incidents and threat intelligence. These include custom password spray detection with NE-specific thresholds, an inbox rule detection focused on forwarding rules, and identity anomaly detections using SigninLogs. Basic KQL, basic thresholds, minimal entity mapping. These 7 rules cover 7 techniques, but 5 overlap with the template rules — only 2 are unique beyond the template coverage (T1071.004 DNS and T1484.001 Group Policy modification).

4 Microsoft Security. Pass-through rules forwarding alerts from Defender for Endpoint (High + Critical severity only), Defender for Office 365 (all severities), Defender for Identity (all severities), and Entra ID Protection (medium + high risk only). These do not add custom detection — they integrate vendor alerts into the Sentinel incident queue. Essential for unified SOC operations but not detection engineering.

0 NRT. No near-real-time rules. The ransomware pre-encryption pattern that justifies NRT is currently detected by a scheduled template rule running every 5 hours — an average detection latency of 2.5 hours for the most time-critical detection in the library. This is the single highest-priority architecture fix in the NE detection program.

0 Anomaly (custom-configured). Built-in anomaly templates are available but none have been enabled. The anomaly Anomalies table is empty. No behavioral baseline detection exists.

Fusion: Enabled. Fusion is active and has generated 3 incidents in the past 90 days — all correlated correctly with multi-stage attack simulations during a tabletop exercise. Fusion works, but it is one capability among many.

The detection engineering program (DE3-DE11) will transform this breakdown: 3-5 NRT rules for critical detections, 40-50 custom scheduled rules with full specifications, anomaly templates enabled as Stage 1 signal sources, and the existing 12 templates reviewed — some retained and tuned, some replaced by more precise custom rules, some retired.

Rule type audit query

Use this query to assess your current rule type distribution:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

// RULE TYPE AUDIT — classify your analytics rules
let rules = SecurityAlert
    | where TimeGenerated > ago(90d)
    | where ProviderName startswith "ASI"
    | extend RuleType = case(
        ProviderName == "ASI Scheduled Alerts", "Scheduled",
        ProviderName == "ASI NRT Alerts", "NRT",
        ProviderName has "Fusion", "Fusion",
        "Microsoft Security"
    )
    | distinct AlertName, RuleType;
rules
| summarize RuleCount = count() by RuleType
| extend Percentage = round(RuleCount * 100.0 / toscalar(rules | count), 1)
| sort by RuleCount desc
// Target distribution for a mature program:
//   Scheduled (custom): 35-45 rules (70-80%)
//   NRT: 3-5 rules (5-8%)
//   Microsoft Security: 4-6 rules (8-10%)
//   Anomaly (via Stage 2 scheduled): 3-5 rules (5-8%)
//   Fusion: 1 (always-on, not counted as a "rule")

The rule type decision flowchart

When building a new detection rule, the type selection follows a decision tree:

Step 1: Does the detection require cross-source correlation or aggregation? Yes → Scheduled rule (only type that supports joins and summarize). No → Continue to Step 2.

Step 2: Is the detection a single-event pattern with >90% confidence and catastrophic impact? Yes → NRT rule (sub-minute detection for the most critical patterns). No → Continue to Step 3.

Step 3: Is the detection endpoint-only with a Defender-native response action needed? Yes → Consider Defender XDR custom detection (DE1.8) in addition to a Sentinel rule. No → Scheduled rule (default choice for all custom detection engineering).

Step 4: Is the detection a behavioral baseline deviation? Yes → Enable the relevant anomaly template and build a Stage 2 scheduled rule (DE1.7). No → Scheduled rule.

The decision tree produces the same answer for 90%+ of detections: scheduled rule. NRT, anomaly, and Defender custom detections serve specific narrow use cases. When in doubt, default to scheduled.

Troubleshooting: “Which type should I use?”

Default: Scheduled. Unless you have a specific reason to use another type, use a scheduled rule. It provides the most flexibility and control.

Use NRT when: the technique is high-confidence (low FP rate), high-impact (catastrophic if missed), and detectable from a single event pattern (no correlation needed). Examples: vssadmin shadow copy deletion, LSASS memory access by non-system process, known C2 beacon command-line.

Use Microsoft Security when: you need vendor alerts in Sentinel’s incident queue. Configure per-product. Filter by severity to control volume.

Use Anomaly when: you want behavioral baseline detection as an input to a custom scheduled rule. Anomaly rules produce data. Scheduled rules act on that data with your environmental context.

References used in this subsection

• Microsoft Sentinel analytics rules documentation
• Course cross-references: DE0.5 (vendor vs custom detection), DE1.2-1.3 (scheduled rule configuration), DE1.6 (NRT deep dive), DE1.7 (anomaly and Fusion)