This chapter covers Microsoft Sentinel's incident and alert management, a core component of Microsoft's cloud-native SIEM and SOAR solution. For the SC-900 exam, understanding how Sentinel ingests alerts, correlates them into incidents, and supports investigation is critical—approximately 10-15% of questions in the 'Security Solutions' domain touch on Sentinel capabilities. You will learn the precise definitions, default configurations, and the incident creation process that the exam tests.
Jump to a section
Imagine a major international airport's security control center. Thousands of sensors (cameras, badge readers, metal detectors, baggage scanners) continuously generate events: a door opens, a bag triggers an alarm, a person enters a restricted zone. Each sensor sends raw data—an alert—to the center. A single alert might be a false alarm: a janitor opened a door with proper credentials. But the control center doesn't just react to individual alerts; it correlates them. It sees that the same person who opened the restricted door also badged into the parking garage 10 minutes earlier, and their badge was used at two locations simultaneously—a clear incident: a potential tailgating or credential theft. The center then creates an incident ticket, grouping all related alerts, and assigns a priority based on risk (e.g., red for active threat, yellow for suspicious). Analysts investigate the incident, not the individual alerts. This is exactly how Microsoft Sentinel works: it ingests alerts from various sources, uses analytics rules to correlate them into incidents, and provides a unified investigation experience. The airport's rule engine (like Sentinel's analytics) decides which alert combinations constitute an incident. Without this correlation, analysts would drown in thousands of meaningless alerts—like trying to spot a terrorist by watching every single camera feed simultaneously.
What Are Alerts and Incidents in Microsoft Sentinel?
In Microsoft Sentinel, an alert is a single, raw security signal generated by a data source or a built-in analytics rule. Alerts are the atomic units of suspicious activity—for example, a Windows Security Event ID 4625 (failed logon) or a Microsoft Defender for Cloud recommendation. Each alert contains fields like time, severity, source, and description.
An incident is a group of related alerts that together represent a actionable security threat. Sentinel automatically creates incidents from alerts using correlation rules (called analytics rules). The key distinction for the exam: alerts are individual events; incidents are the cases that analysts investigate.
How Sentinel Creates Incidents from Alerts
The process is automated and rule-driven:
Data Ingestion: Sentinel ingests logs from various connectors (Azure, Microsoft 365, third-party). These logs are stored in Log Analytics workspaces.
Analytics Rules: Pre-built or custom Kusto Query Language (KQL) queries run on a schedule (e.g., every 5 minutes). When a query matches a pattern, it generates an alert.
Incident Creation: By default, when an analytics rule generates an alert, Sentinel automatically creates an incident. This can be disabled per rule. The incident groups alerts based on a configurable grouping mechanism: by entity (e.g., same user, same IP) or by time window (default 5 hours).
Severity Assignment: Each alert has a severity (Informational, Low, Medium, High). The incident inherits the highest severity among its alerts.
Status and Classification: Incidents start as 'New'. Analysts can change status to 'Active', 'Closed', etc. Classification includes 'True Positive', 'False Positive', 'Benign Positive'.
Key Components and Defaults
- Analytics Rules: There are four types: Scheduled query rules, Microsoft security rules (from Microsoft products), Fusion (advanced multi-stage attack detection), and ML Behavior Analytics. For SC-900, focus on Scheduled and Fusion. - Alert Grouping: In a scheduled rule, you can configure: - Group alerts into incidents: Enabled by default. - Alert grouping by: Entities (e.g., Account, IP, Host) or time (default 5 hours). - Re-open closed matching incidents: If a new alert matches an existing closed incident, it can re-open it (default off). - Incident Creation Threshold: Some rules require a minimum number of alerts (e.g., 5 failed logons in 5 minutes) before creating an incident. - Fusion: Uses advanced ML to correlate alerts across different products, detecting multi-stage attacks. It creates incidents automatically and cannot be disabled.
Configuration and Verification
To view incidents: Navigate to Microsoft Sentinel > Incidents. The blade shows a list with severity, status, owner, and created time.
To view alerts: Within an incident, click 'View full details' to see all associated alerts. Alternatively, query the SecurityAlert table in Log Analytics.
To create a custom analytics rule:
1. Go to Analytics > Create > Scheduled query rule.
2. Define the KQL query (e.g., SigninLogs | where ResultType != 0).
3. Set the run frequency (e.g., every 5 minutes) and lookback period (e.g., last 5 minutes).
4. Configure alert grouping: by entities or time.
5. Set severity and tactics (MITRE ATT&CK).
6. Enable incident creation (default on).
Example KQL to list all incidents:
SecurityIncident
| where TimeGenerated > ago(7d)
| summarize count() by SeverityInteraction with Related Technologies
Microsoft Defender XDR: Alerts from Defender for Endpoint, Office 365, Identity, etc., are ingested into Sentinel via the Microsoft security connector. These alerts can create incidents directly.
Azure Logic Apps: Incidents can trigger automated playbooks (SOAR). For example, when a High severity incident is created, a Logic App can isolate a compromised user.
Microsoft Copilot for Security: Can summarize incidents and suggest response actions.
Exam-Relevant Numbers and Defaults
Default incident creation: Enabled for scheduled rules.
Default alert grouping time window: 5 hours.
Fusion is always on for all workspaces.
Alert severity levels: Informational, Low, Medium, High.
Incident statuses: New, Active, Closed.
Classification reasons: True Positive, False Positive, Benign Positive.
Common Trap on the Exam
A common wrong answer is that alerts and incidents are the same thing. Another is that you must manually create incidents. The exam tests that incidents are automatically created by default, and that Fusion cannot be disabled. Also, candidates often confuse 'alert' with 'incident' when discussing investigation—the exam expects you to know that investigation starts at the incident level.
Ingest Security Data
First, data sources are connected to Sentinel via connectors. This includes Azure services (Azure Activity, Azure AD), Microsoft 365 (Exchange, Teams), third-party firewalls, and syslog. Each connector sends logs to a Log Analytics workspace. For example, the Windows Security Events connector streams event IDs like 4624 (logon) and 4625 (failed logon). Sentinel does not store the logs itself; it queries the Log Analytics workspace. The ingestion rate matters: if logs exceed the workspace's retention policy (default 30 days for interactive retention, up to 2 years for long-term), they may be archived.
Run Analytics Rules
Analytics rules are scheduled KQL queries that run at a defined interval (e.g., every 5 minutes). Each rule has a lookback period (e.g., last 5 minutes). When the query returns results (e.g., more than 10 failed logons from a single IP), it generates an alert. The alert includes the query results as evidence. For Fusion rules, the correlation happens in real-time using ML models, not scheduled queries. The exam expects you to know that scheduled rules are the most common type.
Create Incident from Alerts
By default, when an analytics rule generates an alert, Sentinel automatically creates an incident. The incident groups all alerts from that rule run that match the grouping criteria (e.g., same source IP). If grouping by entities is enabled, alerts with the same entity (e.g., same user account) are grouped into one incident. The default time window for grouping is 5 hours. If a new alert matches an existing incident (same entities), it is added to that incident, not a new one. This prevents alert fatigue.
Assign Severity and Tactics
Each alert has a severity set in the analytics rule. The incident inherits the highest severity among its alerts. For example, if one alert is High and another is Medium, the incident is High. The rule also maps to MITRE ATT&CK tactics (e.g., Initial Access, Persistence). This helps analysts prioritize. Severities are not recalculated after incident creation unless new alerts are added. The exam may ask how severity is determined for an incident.
Investigate and Respond
Analysts open the incident in the Sentinel UI. The 'Incident details' pane shows all alerts, entities, and a timeline. They can use the investigation graph to visually map relationships between entities (users, IPs, hosts). Playbooks (Logic Apps) can be triggered manually or automatically. For example, a playbook might block a malicious IP. The incident status changes from 'New' to 'Active' when investigation begins. Finally, the analyst closes the incident with a classification (True Positive, False Positive, Benign Positive) and a comment.
Enterprise Scenario 1: Detecting Brute-Force Attacks
A multinational company uses Sentinel to monitor Azure AD sign-ins. They create a scheduled analytics rule that queries SigninLogs for failed logons (ResultType != 0) from the same IP address in the last 5 minutes. If the count exceeds 10, the rule generates an alert. Sentinel automatically creates an incident with severity Medium. The incident groups all alerts from that IP within a 5-hour window. The SOC analyst opens the incident, sees 50 failed logons from IP 203.0.113.5, and runs a playbook to block the IP in Azure Firewall. Without Sentinel, the analyst would have to manually correlate sign-in logs from different sources. At scale, this company ingests 10 TB of logs daily, so alert grouping is critical to avoid thousands of incidents per day. Misconfiguration: if the grouping time window is too short (e.g., 1 hour), the same attacker might create multiple incidents, overwhelming the SOC.
Scenario 2: Multi-Stage Attack Detection with Fusion
A financial institution uses Sentinel with Fusion enabled. Fusion correlates alerts from Microsoft Defender for Endpoint (e.g., malware detected on a workstation) and Azure AD Identity Protection (e.g., impossible travel). When both alerts occur within a short time for the same user, Fusion creates a single High severity incident titled 'Multi-stage incident involving [user]'. The incident includes both alerts and suggests that the user's credentials are compromised. The SOC can then reset the user's password and isolate the workstation. Fusion's ML model reduces false positives by learning normal behavior. If Fusion were disabled (it cannot be), the SOC would see two separate incidents and might miss the connection.
Scenario 3: Compliance and False Positive Management
A healthcare organization must meet HIPAA requirements. They configure analytics rules to detect unauthorized access to patient records. When a rule triggers, Sentinel creates an incident. However, many incidents are false positives (e.g., legitimate admin access). The SOC uses the 'Benign Positive' classification to document these. Over time, they tune the rule by excluding certain IPs or users. They also set up a playbook to automatically close incidents from known admin accounts. This reduces noise. A common mistake is not tuning rules, leading to hundreds of false positives daily. The exam emphasizes that incident classification is part of the workflow.
SC-900 Objective Coverage
This topic maps to objective 3.2 Describe the detection and mitigation capabilities of Microsoft Sentinel. Specifically, the exam tests:
Differentiate between alerts and incidents.
Understand automatic incident creation from analytics rules.
Know the default alert grouping time window (5 hours).
Recognize that Fusion is always enabled and cannot be disabled.
Identify that incidents can be closed with classifications (True Positive, False Positive, Benign Positive).
Common Wrong Answers
'Alerts and incidents are the same.' This is the most common trap. The exam expects you to know that alerts are raw signals; incidents are correlated groups.
'You must manually create incidents from alerts.' Incorrect. By default, incidents are created automatically when an analytics rule fires.
'Fusion can be disabled to reduce cost.' False. Fusion is a core feature that cannot be turned off.
'Incidents are created only from Microsoft security alerts.' Wrong. Sentinel can create incidents from any analytics rule, including custom KQL.
Specific Numbers and Terms
Default grouping time window: 5 hours.
Severity levels: Informational, Low, Medium, High.
Incident statuses: New, Active, Closed.
Classification reasons: True Positive, False Positive, Benign Positive.
Analytics rule types: Scheduled, Microsoft security, Fusion, ML Behavior Analytics.
Edge Cases and Exceptions
If you disable 'Create incident from alerts triggered by this rule' in a scheduled rule, no incidents are created—only alerts. This is useful for rules that generate too many false positives.
If an alert is generated from a rule that has grouping disabled, each alert becomes its own incident.
If a closed incident is reopened by a new matching alert (if configured), the status changes back to 'Active'.
Fusion incidents cannot be manually created or modified; they are system-generated.
How to Eliminate Wrong Answers
If a question asks about 'raw signals', the answer is 'alerts'.
If a question mentions 'correlated group of alerts', the answer is 'incidents'.
Look for keywords like 'automatically', 'default', 'cannot be disabled' to identify correct statements about incident creation and Fusion.
When given a scenario with multiple failed logons, the correct answer often involves 'incident created automatically'.
Alerts are individual signals; incidents are correlated groups of alerts.
By default, every alert from an analytics rule creates an incident.
Default alert grouping time window is 5 hours.
Fusion is always enabled and cannot be disabled.
Incident severity is the highest severity among its alerts.
Incident statuses: New, Active, Closed.
Classification reasons: True Positive, False Positive, Benign Positive.
Analytics rule types include Scheduled, Microsoft security, Fusion, and ML Behavior Analytics.
The investigation graph visualizes entity relationships within an incident.
Playbooks (Logic Apps) can automate response to incidents.
Log Analytics workspace stores the underlying data for alerts and incidents.
MITRE ATT&CK tactics can be assigned to analytics rules.
These come up on the exam all the time. Here's how to tell them apart.
Alert
Single security signal from a data source or analytics rule.
Contains fields like severity, time, and source.
Does not imply correlation with other alerts.
Can exist without being part of an incident.
Example: 'Failed logon from IP 10.0.0.1'.
Incident
Group of related alerts that represent a security case.
Includes metadata like status, owner, and classification.
Created automatically by default from one or more alerts.
Is the primary unit for investigation and response.
Example: 'Brute-force attack from IP 10.0.0.1 (10 alerts)'.
Mistake
Alerts and incidents are interchangeable terms in Microsoft Sentinel.
Correct
Alerts are individual security signals generated by analytics rules or data sources. Incidents are collections of related alerts that represent an actionable threat. The exam clearly distinguishes them.
Mistake
You must manually create incidents from alerts using the Sentinel UI.
Correct
By default, Sentinel automatically creates an incident for every alert generated by an analytics rule. Manual creation is possible but not required.
Mistake
Fusion can be disabled to reduce noise.
Correct
Fusion is a built-in, always-on feature that uses machine learning to correlate alerts across Microsoft products. It cannot be disabled.
Mistake
Incidents are only created from Microsoft security alerts (Defender, Azure AD, etc.).
Correct
Incidents can be created from any analytics rule, including custom KQL rules, third-party data sources, and Microsoft security alerts.
Mistake
The default alert grouping time window is 24 hours.
Correct
The default grouping time window is 5 hours. This is a specific value tested on the exam.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An alert is a single security signal generated by an analytics rule or data source. An incident is a collection of related alerts that together represent an actionable threat. For example, 10 failed logon alerts from the same IP may be grouped into one 'Brute-force' incident. The exam tests that incidents are automatically created by default and are the primary object for investigation.
When an analytics rule runs and generates alerts, Sentinel checks if incident creation is enabled (default on). It then groups alerts based on the rule's grouping configuration—by entities (e.g., same user) or within a time window (default 5 hours). The grouped alerts form a single incident. If a new alert matches an existing incident (same entities), it is added to that incident.
Yes, in the analytics rule creation wizard, under 'Incident settings', you can uncheck 'Create incident from alerts triggered by this rule'. This means the rule will generate alerts only, and no incident will be created. This is useful for rules that generate many false positives or for testing.
Fusion is an advanced analytics rule type that uses machine learning to correlate alerts across multiple Microsoft security products (Defender for Endpoint, Azure AD Identity Protection, etc.) to detect multi-stage attacks. It is always enabled and cannot be disabled. Fusion creates incidents automatically, and these incidents are marked with the 'Fusion' source.
Each alert has a severity (Informational, Low, Medium, High). The incident inherits the highest severity among all its alerts. For example, if an incident contains one High alert and two Medium alerts, the incident severity is High. Severity is set in the analytics rule and can be customized.
Statuses: New, Active, Closed. When closing, you must choose a classification: True Positive (confirmed threat), False Positive (alert was incorrect), or Benign Positive (alert correct but expected/non-malicious, e.g., admin activity). You can also add a comment. The exam expects you to know these three classifications.
The default time window for grouping alerts into an incident is 5 hours. This means alerts generated within 5 hours of each other and matching the grouping criteria (e.g., same entity) will be grouped into one incident. You can configure this value per rule.
You've just covered Sentinel Incidents and Alerts Overview — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?