This chapter covers Microsoft Sentinel analytics rules and incidents, a core topic for the AZ-500 exam. Understanding how to create and manage analytics rules to generate incidents is critical, as approximately 15-20% of exam questions touch on Sentinel configuration and incident management. You will learn the different types of analytics rules, how they process data, how incidents are created and managed, and best practices for tuning rules to reduce false positives. Mastery of this content is essential for the Security Operations domain.
Jump to a section
Imagine a large office building equipped with a fire alarm system. The system has various sensors (smoke detectors, heat sensors, manual pull stations) that generate raw signals. These signals are sent to a central fire alarm control panel. The control panel uses predefined rules to interpret the signals: a single smoke detector going off might trigger a 'verify' alarm, but if two detectors in the same zone activate within 30 seconds, it triggers a full evacuation. The panel also logs every signal and action. In this analogy, the sensors are data sources (like Azure VMs, firewalls, and Office 365), the control panel is Microsoft Sentinel, the rules are Analytics Rules, and the evacuation is an Incident. Just as a fire alarm panel must filter out false alarms (e.g., burnt toast) while quickly escalating real fires, Sentinel must distinguish between benign events and genuine threats using analytics rules. The panel's logs are analogous to Sentinel's incidents, which security analysts investigate. If the panel is misconfigured—say, thresholds set too low—false alarms overwhelm the response team. If thresholds are too high, real fires go undetected. Similarly, in Sentinel, poorly tuned analytics rules lead to alert fatigue or missed attacks. The analogy highlights the need for precise rule logic, grouping of related signals into incidents, and automated responses to contain threats before they spread.
What are Sentinel Analytics Rules and Incidents?
Microsoft Sentinel is a cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response) solution. Analytics rules are the core mechanism that transforms raw data from connected data sources into actionable security incidents. An analytics rule is essentially a query (written in Kusto Query Language, KQL) that runs on a schedule or in near real-time to detect suspicious activity. When the query returns results that meet certain thresholds, Sentinel creates an incident—a case file that security analysts can investigate, triage, and respond to.
Incidents are the central entity in Sentinel's incident management workflow. Each incident aggregates related alerts (which are the outputs of analytics rules) and provides a unified view of a potential security threat. Incidents have properties such as severity, status (New, Active, Closed), owner, and tactics (MITRE ATT&CK). The goal is to reduce the noise of raw alerts by grouping them into meaningful incidents that represent actual attacks.
How Analytics Rules Work Internally
Analytics rules operate on data ingested into Sentinel's Log Analytics workspace. The data is stored in tables like SecurityEvent, CommonSecurityLog, or custom tables. Each analytics rule has the following components:
Data source: The table(s) the rule queries.
Query: A KQL query that defines the detection logic.
Alert enrichment: Optional mappings to MITRE ATT&CK tactics, entity mappings (e.g., account, IP, host), and custom details.
Schedule: How often the query runs (e.g., every 5 minutes).
Lookup period: The time window of data the query examines (e.g., last 5 minutes).
Threshold: The number of query results required to trigger an alert (e.g., > 0).
Grouping: Whether to group alerts into a single incident or create separate incidents per event.
Suppression: A period during which duplicate alerts are suppressed after an incident is created.
When the query runs, it scans the specified time range. If the result count meets the threshold, Sentinel creates an alert. Depending on the grouping configuration, one or more alerts are then aggregated into an incident. The incident is assigned a severity based on the rule's severity setting or dynamic severity from the query.
Types of Analytics Rules
Sentinel offers several types of analytics rules, each suited for different detection scenarios:
Scheduled query rules: The most common type. They run on a schedule (e.g., every 5 minutes) and query data over a specified lookback period. You can configure alert grouping, suppression, and incident creation.
Near-real-time (NRT) rules: These run every minute with a 1-minute lookback, providing faster detection for time-sensitive threats. They have limited query complexity and cannot use some advanced features like alert grouping.
Microsoft Security rules: Automatically created from Microsoft security products like Microsoft Defender for Cloud, Microsoft 365 Defender, and Azure Active Directory Identity Protection. These rules are managed by Microsoft but can be customized.
Anomaly rules: Use machine learning to detect unusual patterns based on historical baselines. They are created from built-in anomaly templates.
Fusion rules: Use advanced machine learning to correlate multiple low-fidelity alerts into a high-fidelity incident. Fusion is a correlation engine that reduces alert fatigue.
Scheduled with entity mapping: Rules that explicitly map entities (user, host, IP, etc.) to allow better correlation and investigation.
Configuring Analytics Rules
To create a scheduled query rule in the Azure portal:
Navigate to Sentinel > Analytics > Create > Scheduled query rule.
General tab: Provide name, description, tactics, and severity.
Set rule logic tab:
- Write the KQL query. - Set the query schedule (e.g., run every 5 minutes, look up last 5 minutes). - Set the alert threshold (e.g., generate alert if query results > 0). - Configure event grouping: group all events into a single alert (recommended) or trigger an alert for each event. 4. Incident settings tab: Enable incident creation from alerts triggered by this rule. Optionally set alert grouping (group alerts into a single incident if they match a given time window and entity). 5. Automated responses tab: Configure automation rules or playbooks to run when an incident is created.
Example KQL query for detecting multiple failed logins:
SecurityEvent
| where EventID == 4625
| summarize Count = count() by Account, Computer, bin(TimeGenerated, 5m)
| where Count > 10This query runs every 5 minutes, looking at the last 5 minutes of data, and triggers an alert if any account on any computer has more than 10 failed logins in that window.
Incident Management
Once an incident is created, it appears in the Incidents blade in Sentinel. Each incident has: - ID: Unique identifier. - Title: Generated from the rule name or custom title. - Severity: High, Medium, Low, Informational. - Status: New, Active, Closed. - Owner: Assigned analyst. - Created time: Timestamp. - Tactics: MITRE ATT&CK techniques. - Alerts: List of alerts that make up the incident. - Entities: Users, hosts, IPs, etc. involved.
Analysts can change the status, assign ownership, add comments, and close incidents with a classification (e.g., True Positive, False Positive, Benign Positive). Incidents can be investigated using the Investigation graph, which shows relationships between entities and alerts.
Automation with Automation Rules and Playbooks
Automation rules allow you to automate incident management tasks based on conditions. For example, automatically assign incidents with severity High to a specific analyst team, or run a playbook to block a malicious IP. Playbooks are workflows built in Azure Logic Apps that can perform actions like sending emails, creating tickets, or blocking accounts.
Best Practices for Tuning Analytics Rules
Start with Microsoft-provided rules and modify thresholds based on your environment.
Use alert grouping to reduce incident volume. For example, group all failed login attempts from the same IP within 5 minutes into one incident.
Use suppression to prevent duplicate incidents for the same event within a time window.
Leverage entity mapping to improve investigation and correlation.
Regularly review incident metrics (e.g., mean time to acknowledge, false positive rate) to adjust rules.
Test rules in a development workspace before deploying to production.
Integration with Other Azure Services
Sentinel analytics rules can reference data from multiple sources: Azure Activity logs, Azure AD logs, Microsoft 365 Defender, Azure Firewall, and custom logs. Rules can also trigger automation in Azure Logic Apps, Azure Functions, or Microsoft Teams. The MITRE ATT&CK framework is integrated to help map detection coverage.
Key Numbers and Defaults
Scheduled query rule default schedule: every 5 minutes, lookback 5 minutes.
NRT rule: runs every 1 minute, lookback 1 minute.
Alert grouping time window: up to 5 hours (configurable).
Suppression duration: up to 24 hours.
Maximum number of analytics rules per workspace: 1000.
Maximum incidents per day per workspace: no hard limit, but performance degrades above 100,000.
Command-Line and API Management
Analytics rules can be managed via Azure CLI, PowerShell, or REST API. Example using Azure CLI:
az sentinel alert-rule create --resource-group myRG --workspace-name myWorkspace --rule-name "MyRule" --kind Scheduled --query "SecurityEvent | where EventID == 4625" --schedule-interval 5 --schedule-time 5 --trigger-operator GreaterThan --trigger-threshold 0Common Misconfigurations
Setting thresholds too low causes alert fatigue; too high causes missed detections.
Not using event grouping leads to thousands of incidents per day.
Ignoring suppression results in duplicate incidents.
Using overly complex queries that time out (query timeout is 10 minutes for scheduled rules).
Failing to map entities, making investigation difficult.
Connect Data Sources
Before analytics rules can work, you must connect data sources to Sentinel. This involves installing data connectors for Azure services (e.g., Azure Activity, Azure AD), third-party products (e.g., Syslog, CEF), or custom logs. Each connector ingests logs into specific tables in the Log Analytics workspace. For example, the Azure Activity connector populates the AzureActivity table. Without data, analytics rules will never trigger. Ensure data connectors are healthy by checking the status in Sentinel's Data connectors blade. Common issues include misconfigured agents, firewall blocking, or missing permissions.
Create or Enable Analytics Rule
You can either enable a built-in rule template or create a custom scheduled query rule. Built-in templates are provided by Microsoft for common detections (e.g., 'Multiple failed login attempts'). To use them, navigate to Analytics > Rule templates, select a template, and click Create rule. Custom rules require writing a KQL query and configuring schedule, threshold, and grouping. The rule is saved but not active until you enable it. After creation, the rule will run on its schedule. You can test the query in Logs before creating the rule.
Query Execution and Alert Generation
At the scheduled interval, Sentinel executes the KQL query against the specified tables over the lookback period. The query returns a result set. If the number of rows meets or exceeds the threshold (e.g., > 0), Sentinel generates one or more alerts based on the grouping configuration. For example, if grouping is set to 'Group all events into a single alert', one alert is created containing all matching events. If grouping is 'Trigger an alert for each event', each row becomes a separate alert. The alert includes metadata like severity, tactics, and entities.
Incident Creation from Alerts
When alerts are generated, Sentinel checks the incident creation settings. If incident creation is enabled, Sentinel creates a new incident (or adds alerts to an existing incident if alert grouping is configured). Alert grouping allows multiple alerts that occur within a specified time window (up to 5 hours) and share common entities (e.g., same user or IP) to be merged into a single incident. This reduces noise. The incident inherits the highest severity among its alerts. The incident is assigned a unique ID and appears in the Incidents blade with status 'New'.
Incident Investigation and Response
Security analysts work in the Incidents blade. They can change the status to 'Active', assign an owner, and start investigation. The investigation graph shows relationships between entities and alerts. Analysts can run advanced hunting queries, view the raw logs, and use playbooks for automated response. After analysis, the incident is closed with a classification (True Positive, False Positive, etc.) and a comment. Automation rules can automatically perform actions like changing severity or assigning to a team based on conditions.
In a large enterprise with 50,000 endpoints and thousands of cloud resources, Sentinel ingests millions of logs daily. Without proper analytics rules, security analysts would be overwhelmed. One common scenario is detecting lateral movement. A company deploys a scheduled query rule that looks for a user logging into multiple workstations within a short time window. The rule groups alerts by user account and triggers an incident if more than 5 distinct workstations are accessed within 10 minutes. This reduces thousands of individual logon events into manageable incidents.
Another scenario is a financial institution that must comply with PCI DSS. They use Microsoft Security rules from Microsoft Defender for Cloud to detect suspicious activities like unusual file downloads. They also create custom rules to monitor for failed SSH attempts on Linux servers. With alert grouping and suppression, they keep incident volume under 200 per day, allowing a small team to investigate each one.
A common pitfall is misconfiguring the query schedule. For example, a rule that runs every 1 hour with a 1-hour lookback may miss events that occur in the last minute of the hour if the query takes time to execute. Additionally, if the threshold is set to 1, a single benign event (like a legitimate failed login) creates an incident. This leads to alert fatigue. To avoid this, thresholds should be tuned based on baseline data. Also, forgetting to enable incident creation means alerts are generated but no incidents appear—a common mistake in exam scenarios.
Performance considerations: Scheduled rules can query up to 10 minutes of data; if the query takes longer, it may timeout. Use indexing and avoid cross-workspace queries in high-frequency rules. For very large environments, consider using NRT rules only for critical detections.
The AZ-500 exam tests your ability to configure and manage Sentinel analytics rules and incidents under objective 4.2. Key areas include:
Understanding rule types: You need to know the difference between scheduled, NRT, Microsoft Security, anomaly, and Fusion rules. Common question: 'Which rule type should you use for near-real-time detection?' Answer: NRT rule.
Incident creation settings: The exam often asks about how to reduce incident volume. Options include alert grouping, suppression, and tuning thresholds. The trick is that alert grouping merges alerts into a single incident, while suppression prevents duplicate alerts after an incident is created. Many candidates confuse these.
Entity mapping: Questions may ask which entities are supported (Account, Host, IP, URL, etc.) and why mapping is important (improves investigation).
Automation rules: You may be asked to configure an automation rule that runs a playbook when an incident is created. Remember that automation rules can have conditions based on severity, status, or tactics.
KQL basics: While not heavily tested, you should be able to read a simple KQL query and understand what it does (e.g., filter by EventID, summarize count).
Common wrong answers: 1. Choosing 'suppression' when the question asks for reducing the number of incidents from multiple similar events. Suppression prevents duplicates of the same alert, while grouping combines multiple alerts into one incident. 2. Selecting 'Microsoft Security rule' when the scenario requires a custom detection. Microsoft Security rules are pre-built from Microsoft products; for custom logic, use scheduled rule. 3. Thinking that NRT rules can use complex joins. NRT rules have limitations; they cannot use joins or unions across multiple tables. 4. Forgetting that incidents are created from alerts, but if incident creation is disabled, only alerts appear in the Alerts blade.
Edge cases:
If a rule's query returns zero results, no alert is generated.
If alert grouping is set to 'Group all events into a single alert' and the threshold is met, one alert is created even if there are 10,000 matching events.
Suppression works at the alert level; once an incident is created, the same alert is suppressed for the configured duration, but a different alert (even from the same rule) can create a new incident.
To eliminate wrong answers, focus on the mechanism: understand the flow from query to alert to incident, and know the exact settings that affect each stage.
Analytics rules are KQL queries that run on a schedule to detect threats; incidents are created from alerts generated by these rules.
There are five types of analytics rules: Scheduled, NRT, Microsoft Security, Anomaly, and Fusion.
Scheduled rules run every 5 minutes by default with a 5-minute lookback; NRT rules run every minute with a 1-minute lookback.
Alert grouping merges multiple alerts into one incident; suppression prevents duplicate incidents for the same alert within a set time (up to 24 hours).
Incident creation must be explicitly enabled in the rule settings; otherwise, only alerts appear.
Entity mapping improves investigation by linking alerts to users, hosts, IPs, etc.
Automation rules automate incident management tasks like assigning severity or running a playbook.
Common mistakes: confusing grouping with suppression, forgetting to enable incident creation, and using NRT for complex queries.
These come up on the exam all the time. Here's how to tell them apart.
Scheduled Query Rule
Can run every 5 minutes or longer (configurable).
Supports complex KQL queries including joins and unions.
Lookback period can be up to 14 days.
Supports alert grouping and suppression.
Best for non-critical detections where delay is acceptable.
Near-Real-Time (NRT) Rule
Runs every 1 minute with 1-minute lookback.
Limited to simple queries; no joins or unions.
Cannot use alert grouping or suppression.
Lower latency (under 2 minutes).
Best for critical detections requiring immediate response.
Mistake
Analytics rules automatically create incidents without any configuration.
Correct
By default, incident creation is enabled for new rules, but you must explicitly configure it. In the rule creation wizard, the 'Incident settings' tab has an option 'Create incident from alerts triggered by this rule'. If unchecked, no incidents are created, only alerts.
Mistake
Alert grouping and suppression are the same thing.
Correct
They are different. Alert grouping combines multiple alerts that occur within a time window into a single incident. Suppression prevents the same alert (based on the rule and matching criteria) from creating another incident for a set duration after an incident is created.
Mistake
NRT rules can run any KQL query like scheduled rules.
Correct
NRT rules have limitations: they cannot use joins, unions, or complex aggregations. They are designed for simple, high-frequency detections. Scheduled rules are more flexible.
Mistake
Fusion rules are available in all Sentinel workspaces by default.
Correct
Fusion rules require specific data sources (e.g., Microsoft Defender for Endpoint, Azure AD Identity Protection) and may need to be enabled. Not all workspaces have Fusion available; it depends on the pricing tier and data connectors.
Mistake
Once an incident is closed, it cannot be reopened.
Correct
Closed incidents can be reopened by changing their status back to Active. This is useful if new evidence emerges.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
To reduce incident volume, use alert grouping to combine multiple alerts into a single incident. Also, increase the threshold (e.g., require more than 10 failed logins instead of 1). Enable suppression to prevent duplicate incidents for the same alert within a time window. Additionally, consider using a longer schedule interval or lookback period to reduce frequency. For example, instead of running every 5 minutes, run every 30 minutes with a 30-minute lookback.
An alert is the output of an analytics rule when the query returns results meeting the threshold. It contains the raw events and metadata. An incident is a case file that aggregates one or more related alerts for investigation. Incidents have status, owner, and severity, and are the primary entity analysts work with. Alerts can exist without incidents if incident creation is disabled.
Yes, you can create a playbook in Azure Logic Apps that closes incidents with a specific classification. Then, configure an automation rule to run that playbook when an incident meets certain conditions (e.g., severity Low). This is useful for automatically closing false positives.
If a scheduled rule query takes longer than 10 minutes, it will timeout and fail. The rule will not generate alerts for that run. Sentinel will retry on the next scheduled interval. To avoid timeouts, optimize the KQL query by using filters, reducing the lookback period, or using materialized views.
You can test the KQL query in the Logs blade by running it manually over the desired time range. In the rule creation wizard, you can also use the 'Test with current data' option to simulate the rule execution and see how many alerts would be generated. This helps validate the logic and threshold.
The maximum is 1000 rules per workspace. If you exceed this, you must disable or delete unused rules. Consider consolidating similar detections into fewer rules with more complex queries.
Yes, you can use cross-workspace queries in a scheduled rule by specifying the workspace identifier in the query (e.g., using the workspace() function). However, this may impact performance and is not supported for NRT rules.
You've just covered Sentinel Analytics Rules and Incidents — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?