This chapter covers Microsoft Sentinel Analytics Rules, a core component of detection and response in a SIEM. For the SC-200 exam, understanding analytics rules is critical because approximately 20% of questions relate to creating, configuring, and managing these rules. You'll learn the types of rules, how they work internally, and how to optimize them for threat detection. Mastery of analytics rules directly impacts your ability to pass the exam and succeed as a Security Operations Analyst.
Jump to a section
Think of Microsoft Sentinel Analytics Rules as a building's fire detection system. The building (your environment) has many rooms (data sources like Azure Activity, Windows Security Events, and Office 365 logs). Sensors (data connectors) continuously monitor for smoke (suspicious activities). But raw sensor data is meaningless until a fire alarm panel (analytics rule) processes it. Each rule defines a specific fire scenario: for example, if smoke is detected in a server room AND the temperature rises above 150°F within 5 minutes, trigger the sprinklers (generate an incident). The panel doesn't just sound a generic alarm; it identifies the exact location, time, and severity. In Sentinel, each analytics rule consists of a KQL query (the detection logic), a frequency (how often to run the query, e.g., every 5 minutes), a lookback period (how far back to analyze data, e.g., past 5 minutes), and an alert threshold (e.g., trigger when query returns more than 0 results). Just as a fire panel might have a delay to avoid false positives from burnt toast, analytics rules have settings like alert suppression (to avoid flooding responders with duplicate alerts) and entity mapping (to correlate alerts to the same user or IP, similar to the panel identifying the same smoke source across multiple sensors). If misconfigured, you might miss a real fire (false negative) or get overwhelmed by false alarms (alert fatigue), both of which the SC-200 exam tests heavily.
What Are Microsoft Sentinel Analytics Rules?
Microsoft Sentinel Analytics Rules are the heart of threat detection in the SIEM. They are scheduled KQL queries that run against ingested data to identify suspicious activities, anomalies, or known attack patterns. When a rule matches, it can generate an alert, which can then be grouped into incidents for investigation. The SC-200 exam expects you to know the types, configuration parameters, and best practices for these rules.
Types of Analytics Rules
Sentinel offers five types of analytics rules:
Scheduled: The most common type. You define a KQL query, set a run frequency (e.g., every 5 minutes), and specify a lookback period (e.g., past 5 minutes). The query runs on a schedule and alerts if results exceed a threshold.
Microsoft Security: Built-in rules that create incidents from alerts generated by other Microsoft security products like Microsoft Defender for Cloud, Microsoft 365 Defender, and Azure Active Directory Identity Protection. You cannot modify the query, but you can enable/disable and set severity.
Near-Real-Time (NRT): Similar to scheduled but runs once per minute with a 1-minute lookback. Used for scenarios requiring faster response. Limited to 20 rules per workspace.
Anomaly: Uses machine learning to detect unusual behavior. You can enable built-in anomaly models (e.g., unusual number of failed logons) and customize thresholds.
Fusion: Advanced multistage attack detection that correlates alerts from multiple products. Uses Microsoft's research to detect complex attack chains. You can enable/disable but not modify.
How Scheduled Rules Work Internally
When you create a scheduled rule, Sentinel performs the following steps:
Query Execution: At the scheduled time (e.g., every 5 minutes), the KQL query runs against the Log Analytics workspace, scanning data within the lookback window (e.g., last 5 minutes).
Aggregation and Threshold Check: The query returns aggregated results (e.g., count of events). If the count meets or exceeds the threshold (default: 0, meaning any result triggers), an alert is created.
Alert Grouping: Alerts can be grouped into incidents using entity mapping. For example, if multiple alerts involve the same user account, they can be grouped into one incident.
Alert Suppression: To prevent duplicate alerts, you can set a suppression duration (e.g., 4 hours) during which no new alerts are generated for the same entity combination.
Incident Creation: By default, alerts are automatically converted to incidents. You can disable this and use automation rules to create incidents conditionally.
Key Configuration Parameters
Rule Query: The KQL query that defines the detection logic. Must be efficient to avoid performance issues.
Run Frequency: How often the query runs. Common values: 5 minutes, 15 minutes, 1 hour. Cannot exceed 14 days.
Lookback Period: How far back in time the query examines. Must be greater than or equal to run frequency (recommended: equal).
Alert Threshold: Minimum number of results to trigger an alert. Default is 0.
Event Grouping: How alerts are grouped into incidents. Options: Group all alerts into a single incident, or create one incident per alert.
Entity Mapping: Maps fields in the query result to entities like Account, IP, Host, etc. This enriches incidents and enables correlation.
Alert Details: Customizable alert name, description, severity, and tactics (MITRE ATT&CK).
Suppression Duration: Time to suppress duplicate alerts. Values: 1 hour to 24 hours.
Performance Considerations
Scheduled rules consume query resources. Limit the number of rules and optimize queries by using summarized data and filtering early.
Near-real-time rules are limited to 20 per workspace to prevent resource exhaustion.
Use functions and saved queries to avoid repeating complex logic.
Integration with Automation Rules
Analytics rules work hand-in-hand with automation rules, which are triggered when an alert or incident is created. Automation rules can run playbooks (Logic Apps) to respond automatically, such as blocking an IP or disabling a user account. The exam tests scenarios where you choose between using automation rules vs. playbooks directly.
Common Misconfigurations
Threshold too low (0): Every benign event triggers an alert, causing noise.
Lookback period too long: Query may miss recent data or take too long.
Suppression not configured: Duplicate alerts flood the queue.
Entity mapping missing: Incidents lack context for investigation.
Exam-Relevant Details
The default alert threshold is 0.
Maximum number of NRT rules per workspace is 20.
Run frequency cannot exceed 14 days.
Lookback period must be >= run frequency.
Suppression duration can be set in hours (1-24).
MITRE ATT&CK tactics can be assigned to rules for mapping to the kill chain.
Define the Detection Scenario
Start by identifying a security scenario you want to detect, such as multiple failed logons from a single IP. Determine the data source (e.g., SecurityEvent table) and the time window (e.g., 5 minutes). This step is crucial because the KQL query will directly reflect this scenario. On the exam, you may be given a scenario and asked to choose the appropriate query or rule settings.
Write the KQL Query
Write a KQL query that returns the relevant events. For example: `SecurityEvent | where EventID == 4625 | summarize Count = count() by IpAddress, Account | where Count > 5`. The query must be optimized: use `where` filters early, avoid joins on large tables, and use `summarize` for aggregation. The exam tests your ability to identify correct KQL syntax and logic for a given detection.
Configure Rule Settings in Sentinel
In the Sentinel portal, navigate to Analytics > Create > Scheduled query rule. Enter the query, set the run frequency (e.g., 5 minutes) and lookback period (e.g., 5 minutes). Set the alert threshold to 0 (any result triggers an alert). Configure entity mapping: map `IpAddress` to IP entity, `Account` to Account entity. Set alert details: name, severity (Medium), and MITRE tactic (Credential Access). Enable suppression for 1 hour to avoid duplicates. This step tests your knowledge of rule configuration options.
Review and Test the Rule
Before enabling, use the 'Test with current data' feature to see how many alerts would have been generated in the past. Adjust threshold or query if too many or too few results. You can also run the query manually in Logs to verify. The exam may ask about testing methods or how to validate rule effectiveness.
Enable and Monitor the Rule
Once satisfied, enable the rule. Monitor its performance via the Analytics page: check the number of alerts generated, average execution time, and any failures. Use the 'Rule runs' tab to see each execution. If the rule generates too many false positives, adjust the threshold or query. The exam emphasizes monitoring and tuning rules to reduce noise.
Enterprise Scenario 1: Detecting Brute Force Attacks
A large enterprise with 50,000 employees uses Sentinel to detect brute force attacks against their Azure AD. They create a scheduled rule that runs every 5 minutes with a 5-minute lookback, querying SigninLogs for failed logons (>10 from a single IP). They map the IP and user account entities. Initially, they set threshold to 0, but this generated 500 alerts per day—many from legitimate failed attempts (e.g., forgotten passwords). They increased threshold to 10 and added suppression for 4 hours, reducing alerts to 20 per day, all actionable. The key lesson: threshold tuning is critical to avoid alert fatigue.
Enterprise Scenario 2: Detecting Malware Beaconing
A financial services company monitors for malware beaconing using proxy logs. They create an NRT rule (1-minute frequency) that queries CommonSecurityLog for repeated connections to known bad IPs (from threat intelligence). Because NRT rules are limited to 20, they prioritize this rule. Performance is critical: the query must run within 30 seconds. They use a pre-filtered threat intelligence table to avoid scanning all logs. This rule catches beaconing within minutes, allowing rapid response.
Enterprise Scenario 3: Correlating Alerts with Fusion
A healthcare organization uses Fusion rules to detect multistage attacks. For example, a suspicious sign-in followed by data exfiltration from SharePoint. They enable the built-in Fusion rule for Microsoft 365 Defender. They do not modify the rule but tune it by excluding benign entities (e.g., internal IPs) via automation rules. Fusion rules are powerful but can generate complex incidents; analysts need training to investigate them. Misconfiguration occurs when organizations disable Fusion because of noise, missing critical attacks.
Common Pitfalls
Overusing NRT rules: Exceeding the 20-rule limit forces you to prioritize, potentially missing detections.
Ignoring entity mapping: Without it, incidents lack context, making investigation slow.
Not using suppression: Duplicate alerts overwhelm the queue, leading to missed critical alerts.
Setting frequency too high: Every 5 minutes is common; every minute (NRT) can cause resource issues.
What SC-200 Tests on Analytics Rules (Objective 2.3)
The exam focuses on: - Creating and configuring scheduled rules: Given a scenario, choose the correct KQL query, frequency, lookback, and threshold. - Understanding rule types: Distinguish between Scheduled, NRT, Microsoft Security, Anomaly, and Fusion. Know when to use each. - Entity mapping and alert grouping: How entities correlate alerts and how grouping affects incident creation. - Alert suppression: When and how to set suppression duration. - Performance and limits: Maximum NRT rules (20), frequency limits (max 14 days), and query optimization. - Integration with automation: How automation rules and playbooks respond to alerts.
Common Wrong Answers and Why
Choosing NRT for a query that runs every 5 minutes: NRT runs every 1 minute, not 5. Candidates confuse NRT with scheduled rules. The correct answer is scheduled with 5-minute frequency.
Setting lookback period shorter than run frequency: For example, frequency=5 min, lookback=2 min. This misses data. The correct rule: lookback >= frequency.
Using Microsoft Security rule for custom queries: Microsoft Security rules are read-only; you cannot modify the query. Candidates try to create a custom detection using this type; the correct choice is scheduled.
Disabling alert suppression thinking it improves detection: Suppression reduces duplicates; disabling it causes alert fatigue. The exam emphasizes that suppression is beneficial.
Specific Numbers and Values to Memorize
Default alert threshold: 0
Maximum NRT rules per workspace: 20
Maximum run frequency: 14 days
Suppression duration range: 1-24 hours
Lookback period must be >= run frequency
NRT frequency: 1 minute, lookback: 1 minute
Edge Cases the Exam Loves
When to use Fusion vs. scheduled: Fusion is for multistage attacks; scheduled for single-stage.
What happens if query returns no results: No alert is created.
Can you change a rule type after creation?: No; you must delete and recreate.
Entity mapping with multiple entities: If multiple entities are mapped, alerts are grouped if they share at least one entity.
Eliminating Wrong Answers
If the scenario requires near-instant detection, eliminate scheduled rules; choose NRT.
If the detection involves multiple products, consider Fusion.
If the rule needs custom logic, eliminate Microsoft Security and Fusion.
If the question mentions 'limit of 20', it's about NRT rules.
Scheduled rules are the most common; they run a KQL query on a timer.
NRT rules run every minute and are limited to 20 per workspace.
Alert threshold default is 0; tune to reduce noise.
Lookback period must be >= run frequency.
Suppression duration can be set from 1 to 24 hours.
Entity mapping enriches incidents and enables grouping.
Microsoft Security rules are read-only; use scheduled for custom logic.
Fusion rules detect multistage attacks using ML.
Anomaly rules use ML models to detect unusual behavior.
Automation rules can trigger playbooks on alert/incident creation.
These come up on the exam all the time. Here's how to tell them apart.
Scheduled Rule
Runs on a schedule (e.g., every 5 minutes).
Lookback period can be up to 14 days.
No hard limit on number of rules (soft limit depends on performance).
Suitable for most detection scenarios.
Less resource-intensive than NRT.
Near-Real-Time (NRT) Rule
Runs every 1 minute with 1-minute lookback.
Limited to 20 rules per workspace.
Provides faster detection (within 1 minute).
Used for time-critical detections like beaconing.
More resource-intensive; query must be efficient.
Mistake
Analytics rules can only use data from one table.
Correct
KQL queries can join multiple tables (e.g., SecurityEvent and SigninLogs) to correlate events from different sources. However, performance may degrade; use `join` carefully.
Mistake
Alert threshold must always be 0 to catch all threats.
Correct
A threshold of 0 triggers an alert for every single result, causing noise. In production, thresholds are often set higher (e.g., >5) to reduce false positives.
Mistake
NRT rules are always better than scheduled rules.
Correct
NRT rules are limited to 20 per workspace and consume more resources. Use scheduled rules for most detections; reserve NRT for time-critical scenarios.
Mistake
Entity mapping is optional and doesn't affect incident grouping.
Correct
Entity mapping is critical for grouping alerts into meaningful incidents. Without it, each alert becomes a separate incident, overwhelming analysts.
Mistake
You can modify a Microsoft Security rule's query.
Correct
Microsoft Security rules are read-only. You can only enable/disable and adjust severity. To customize, create a scheduled rule.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A scheduled rule runs on a user-defined frequency (e.g., every 5 minutes) with a lookback period (e.g., past 5 minutes). NRT rules run every minute with a 1-minute lookback. NRT rules are limited to 20 per workspace and are used for time-critical detections. Scheduled rules are more flexible and can handle longer lookback periods.
Increase the alert threshold (e.g., from 0 to 5) so that only events exceeding that count trigger an alert. Also, refine the KQL query to filter out known benign activities. Use alert suppression to prevent duplicate alerts for the same entity within a set time window.
No. Microsoft Security rules are read-only. You can only enable or disable them, and adjust the severity. To create a custom detection, you must create a scheduled rule with your own KQL query.
No alert is generated. The rule execution is logged but no incident is created. This is normal; it means the detection condition was not met during that run.
You can create up to 20 NRT rules per workspace. This limit is enforced to prevent resource exhaustion. If you need more, consider using scheduled rules with a frequency of 1 minute (but note that scheduled rules cannot achieve true 1-minute latency due to scheduling overhead).
Entity mapping links fields in your query results to standard entities like User, IP, Host, etc. This enriches alerts and incidents with context, and enables grouping of related alerts into a single incident. Without entity mapping, each alert becomes a separate incident, overwhelming analysts.
Yes. Automation rules can be triggered when an alert or incident is created by an analytics rule. They can run playbooks (Logic Apps) to perform actions like blocking an IP, disabling a user, or sending a notification. This is a key integration point tested on the exam.
You've just covered Sentinel Analytics Rules — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?