Sentinel Near-Real-Time (NRT) Analytics Rules

Near-Real-Time (NRT) analytics rules are a type of detection rule in Microsoft Sentinel designed to provide faster alert generation than scheduled analytics rules, while being simpler and more cost-effective than full stream-processing solutions. NRT rules run every 5 minutes by default and query data ingested in the last 5 minutes, producing alerts with a latency of typically under 2 minutes from when the triggering event occurs. They are ideal for scenarios where a delay of a few minutes is acceptable, such as detecting multiple failed logins from a single source or identifying known malicious IP addresses.

Before NRT rules, Sentinel offered two main rule types: scheduled analytics rules (run every 5 minutes or longer) and Microsoft Security rules (based on alerts from other Microsoft security products). Scheduled rules could be configured to run as frequently as every 5 minutes, but they still incurred the overhead of querying the entire workspace for the lookback period. NRT rules were introduced to provide a dedicated, optimized path for low-latency detection without the need for complex streaming analytics. They bridge the gap between scheduled rules (which can have delays up to 14 minutes due to ingestion and query scheduling) and real-time processing (which requires Azure Stream Analytics or similar).

NRT rules use a specialized pipeline within Sentinel that reduces latency by:

The key difference from scheduled rules is that NRT rules do not wait for the full query interval to elapse before checking results. Instead, they execute the query at a higher frequency (every 1 minute) but only against a sliding 5-minute window. This means that an event occurring at time T will be included in the query window at T+1 minute (if the rule runs at T+1) and could generate an alert as early as T+1 minute, but the maximum delay is 5 minutes (if the event occurs immediately after a query execution).

To create an NRT rule in Sentinel: 1. Navigate to Analytics > Create > NRT rule. 2. Provide a name, description, and severity. 3. Write the KQL query. Example:

SigninLogs
| where TimeGenerated > ago(5m)
| where ResultType == "50057"
| summarize FailedCount = count() by UserPrincipalName
| where FailedCount > 5

To verify the rule is working:

NRT rules complement other rule types: - Scheduled Rules: For use cases where a delay of up to 14 minutes is acceptable, or when you need to query data older than 5 minutes (e.g., looking back 24 hours). NRT cannot query beyond 5 minutes. - Microsoft Security Rules: These are based on alerts from products like Microsoft Defender for Endpoint. NRT rules are independent but can be used to correlate with those alerts. - Anomaly Rules: Use machine learning to detect unusual patterns. NRT rules are deterministic and do not use ML. - Fusion Rules: Correlate multiple alerts. NRT rules can feed into Fusion.

NRT rules are not suitable for:

A large enterprise uses Sentinel to monitor VPN authentication logs. They need to detect when a single user account has more than 10 failed login attempts within 5 minutes. NRT rules are ideal here because the attack pattern is time-bound and requires quick response. The rule queries SigninLogs for events with ResultType == '50057' and groups by UserPrincipalName. If the count exceeds 10, an alert is generated. The SOC team then investigates and potentially blocks the user account. With NRT, the alert arrives within 2-3 minutes of the attack, allowing the team to respond before the attacker succeeds.

A financial services company maintains a threat intelligence feed of known malicious IP addresses. They ingest this feed into Sentinel as a custom log table. An NRT rule correlates incoming network traffic logs with the threat intelligence table. If a match is found in the last 5 minutes, an alert is generated. This is a simple, low-latency detection that does not require complex processing. The rule runs every minute, ensuring that even if the threat feed is updated, the detection is nearly real-time.