Study guide
Technical reference and lesson notes
Purpose of This Lesson
Microsoft Sentinel analytics rules are used to detect suspicious activity, anomalies, known attack patterns, and indicators of compromise across connected data sources.
For the SC-200 exam, this topic is important because analytics rules are one of the main ways Microsoft Sentinel turns raw security data into actionable alerts and incidents. A Microsoft Security Operations Analyst needs to understand how analytics rules support detection, investigation, response, automation, threat hunting, and continuous improvement inside a SOC.
Analytics rules help answer questions such as:
- Is suspicious activity occurring in the environment?
- Should this activity generate an alert?
- Should multiple alerts be grouped into an incident?
- Should an automated response run?
- Is this detection logic best handled by Microsoft, machine learning, KQL, or near real-time detection?
Key Concepts
What Are Microsoft Sentinel Analytics Rules?
Microsoft Sentinel analytics rules are detection rules that analyze ingested security data and generate alerts or incidents when suspicious activity is found.
Microsoft Sentinel collects data from many sources, such as Microsoft Defender XDR, Microsoft Entra ID, endpoints, firewalls, servers, cloud workloads, and third-party tools. Analytics rules evaluate that data to identify threats, unusual patterns, known attack techniques, or indicators of compromise.
In plain English, analytics rules are the detection engine that helps Sentinel move from “we collected logs” to “this activity may require investigation.”
Why Analytics Rules Matter
Without analytics rules, Sentinel would mostly be a centralized log collection and search platform. Analytics rules give Sentinel operational value by continuously evaluating data and surfacing security events that matter.
Analytics rules can help detect:
- Suspicious sign-in activity
- Known attack techniques
- Malware indicators
- Unusual user or device behavior
- Multi-stage attacks
- Threat intelligence matches
- Patterns that exceed normal thresholds
- Security events that require SOC review
For SC-200, remember that analytics rules are about detection and alert generation. They are different from automation rules and playbooks, which are more focused on response and workflow automation.
Types of Microsoft Sentinel Analytics Rules
Microsoft Sentinel supports several analytics rule types. Each rule type is designed for a different detection scenario.
Scheduled Query Rules
Scheduled query rules use KQL, or Kusto Query Language, to search log data on a defined schedule.
These rules are commonly used when an organization wants to run custom detection logic against Sentinel data. The rule runs at specific intervals, evaluates the query results, and generates alerts when the configured conditions are met.
Example use cases include:
- Detecting repeated failed sign-ins
- Finding suspicious PowerShell activity
- Identifying unusual administrator activity
- Alerting when a threshold is exceeded
- Detecting known indicators of compromise
- Searching for specific attack behaviors mapped to MITRE ATT&CK techniques
Scheduled query rules are one of the most important analytics rule types for the SC-200 exam because they combine Sentinel detection logic with KQL.
Important Scheduled Query Rule Concepts
A scheduled query rule usually includes:
- A KQL query
- A query frequency
- A query lookback period
- Alert threshold logic
- Entity mapping
- Severity
- MITRE ATT&CK tactics and techniques
- Incident creation settings
- Optional automation response
The query defines what Sentinel is looking for. The schedule defines how often Sentinel checks for it.
Microsoft Security Incident Creation Rules
Microsoft security incident creation rules generate Sentinel incidents from alerts produced by Microsoft security products, such as Microsoft Defender XDR.
These rules are useful when Microsoft Defender products already detect suspicious activity, and Sentinel is being used as the centralized SIEM/SOAR platform.
Example sources may include:
- Microsoft Defender for Endpoint
- Microsoft Defender for Identity
- Microsoft Defender for Office 365
- Microsoft Defender for Cloud Apps
- Microsoft Entra ID Protection
- Microsoft Defender XDR incidents and alerts
The key idea is that Sentinel can ingest Microsoft security alerts and create incidents for SOC investigation.
For the exam, understand that this rule type is not mainly about writing custom KQL. It is about creating Sentinel incidents from Microsoft security alerts.
Fusion Rules
Fusion rules use machine learning to correlate multiple lower-confidence alerts into higher-confidence incidents.
Fusion is especially useful for multi-stage attacks where no single alert tells the full story. An attacker might begin with suspicious sign-in activity, move to endpoint activity, access cloud resources, and then attempt data exfiltration. Individually, some events may look weak or incomplete. Fusion attempts to connect related activity into a more meaningful incident.
Fusion can help identify:
- Multi-stage attacks
- Attack chains across multiple products
- Related low-fidelity alerts
- Activity spanning identity, endpoint, email, and cloud resources
- Complex threats that would be difficult to detect with one simple rule
For SC-200, associate Fusion with machine learning correlation and multi-stage attack detection.
Machine Learning Behavior Analytics Rules
Machine learning behavior analytics rules use advanced analytics to identify unusual behavior that deviates from expected patterns.
These detections are useful when suspicious activity is not based on a simple static indicator, such as a known IP address or file hash. Instead, the suspicious behavior is based on abnormal activity compared to baseline behavior.
Example scenarios include:
- A user signing in from an unusual location
- A device communicating in an abnormal pattern
- A user accessing resources they do not normally access
- A sudden change in administrative activity
- A pattern that does not match historical behavior
For the exam, remember that behavior analytics is useful when the goal is to detect abnormal behavior rather than a specific known signature.
Near Real-Time Analytics Rules
Near real-time analytics rules, often called NRT rules, are designed to detect threats quickly after relevant events are ingested.
These rules are used when the SOC needs faster detection than a standard scheduled query rule. NRT rules are useful for high-priority detection scenarios where waiting several minutes or longer could increase risk.
Example use cases include:
- High-risk sign-in activity
- Suspicious privilege escalation
- Malware-related activity
- Critical endpoint alerts
- Rapid detection of known attack behavior
NRT rules are not the same as traditional scheduled analytics rules. The main advantage is speed. They are intended to alert quickly after the data becomes available in Sentinel.
Alerts and Incidents in Sentinel
What Happens When an Analytics Rule Triggers?
When an analytics rule matches suspicious activity, it can generate an alert. Those alerts can then be grouped into an incident.
This relationship is important:
- Analytics rule: Detection logic
- Alert: A detection result generated by a rule
- Incident: A case or investigation container that may include one or more alerts
- Entities: Related objects such as users, devices, IP addresses, files, URLs, and cloud resources
- Evidence: Supporting details used during investigation
A single incident may contain multiple alerts. This helps analysts investigate related activity together instead of treating every alert as a separate isolated event.
Why Incidents Are Important
Incidents provide the SOC workflow container for investigation and response. An analyst can use the incident to review affected entities, inspect related alerts, understand the timeline, assign ownership, update status, and document findings.
This matters because SOC work is not only about seeing alerts. It is about determining whether the activity is malicious, understanding scope and impact, responding appropriately, and improving future detection.
Customization and Configuration
Analytics rules can be customized to fit the organization’s environment.
Security teams may configure rules based on:
- Severity
- Event frequency
- Thresholds
- Query logic
- Entity mapping
- MITRE ATT&CK tactics and techniques
- Suppression settings
- Incident creation behavior
- Automated response
- Environment-specific allowlists or watchlists
Customization is important because every environment is different. A rule that is useful in one tenant may create too much noise in another. SOC teams often tune analytics rules to reduce false positives and improve investigation quality.
Threshold-Based Detection
Many analytics rules depend on thresholds. For example, a SOC may not want an alert for one failed sign-in, but it may want an alert if one account has 20 failed sign-ins within 10 minutes.
Thresholds help reduce alert noise by focusing on patterns that are more likely to be suspicious.
Example threshold logic:
- More than 10 failed sign-ins within 15 minutes
- More than 5 admin role changes in one hour
- More than 3 malware detections on one device
- Multiple failed logons followed by a successful logon
- Multiple alerts involving the same account or IP address
For the exam, pay attention to wording such as “detect when activity exceeds a specific number within a time window.” That usually points toward a scheduled query rule using KQL and threshold logic.
Response Automation, Automation Rules, and Playbooks
Analytics rules can integrate with automated response workflows.
In Microsoft Sentinel, automated responses are commonly implemented using playbooks. A playbook is built on Azure Logic Apps and can automate response actions when certain conditions are met.
Example playbook actions include:
- Send an email or Teams notification
- Create a ticket
- Disable a user account
- Block an IP address
- Add an indicator
- Isolate a device
- Post incident details to a SOC channel
- Enrich an incident with external threat intelligence
However, it is important to distinguish analytics rules from automation.
Analytics Rules vs Automation Rules vs Playbooks
Analytics rules detect suspicious activity.
Automation rules control what happens to incidents or alerts based on conditions.
Playbooks perform automated actions using Logic Apps.
For SC-200, this distinction is critical.
| Concept | Primary Purpose | Example |
|---|---|---|
| Analytics rule | Detect suspicious activity and generate alerts/incidents | Run a KQL query to detect repeated failed sign-ins |
| Automation rule | Apply logic to incidents/alerts and trigger workflow actions | Automatically assign high-severity incidents to Tier 2 |
| Playbook | Execute automated response actions using Azure Logic Apps | Disable a user, notify Teams, or create a ServiceNow ticket |
Do not confuse detection logic with response automation. Analytics rules find the problem. Automation rules and playbooks help manage or respond to the problem.
Continuous Improvement
Analytics rules are not a one-time configuration. They require continuous review and tuning.
The threat landscape changes constantly. New attack techniques appear, existing techniques evolve, and attacker behavior changes over time. Microsoft updates built-in detections and templates, while security teams are responsible for tuning rules for their own environment.
Continuous improvement includes:
- Reviewing rule effectiveness
- Tuning noisy detections
- Adjusting thresholds
- Adding entity mapping
- Mapping rules to MITRE ATT&CK
- Converting hunting queries into analytics rules
- Disabling rules that are not useful
- Reviewing false positives
- Adding automation carefully
- Validating detection coverage after incidents
For real SOC work, this is where detection engineering overlaps with incident response.
Microsoft Security Operations Context
How Analytics Rules Fit Into a SOC Workflow
In a real SOC, analytics rules help move security monitoring from manual searching to proactive detection.
A typical workflow may look like this:
- Data is ingested into Microsoft Sentinel through connectors.
- Analytics rules evaluate the data.
- A rule detects suspicious activity.
- Sentinel generates an alert.
- Alerts are grouped into an incident.
- The analyst reviews the incident.
- The analyst investigates related entities.
- The analyst determines scope and impact.
- The SOC responds manually or through automation.
- Findings are documented.
- Detection logic is tuned or improved.
Analytics rules are part of the detection layer, but they directly affect investigation and response quality.
Analyst Triage Workflow
When an incident is created from an analytics rule, an analyst should usually review:
- Incident title and severity
- Rule that generated the alert
- Alert details
- Affected entities
- Timeline of activity
- Related users and devices
- Source and destination IP addresses
- Related Microsoft Defender alerts
- MITRE ATT&CK tactics and techniques
- Automation history
- Supporting evidence
The analyst’s job is to determine whether the incident is a true positive, false positive, benign positive, or something that requires escalation.
Determining Scope and Impact
Analytics rules often identify the first signal, but investigation determines the real impact.
For example, a rule may detect repeated failed sign-ins. The analyst still needs to determine:
- Which account was targeted?
- Was there a successful sign-in afterward?
- Was MFA satisfied?
- Was the sign-in from an unusual location?
- Was the account privileged?
- Did the account access sensitive resources?
- Are there related endpoint, email, or cloud alerts?
- Is this part of a larger campaign?
This is why incidents, alerts, entities, and evidence all matter together.
Containment and Response
Analytics rules may trigger automated response, but analysts must be careful with high-impact actions.
Safe automation examples:
- Notify the SOC
- Create a ticket
- Add enrichment data
- Assign an incident
- Add tags
- Run a low-risk lookup
Higher-risk automation examples:
- Disable a user
- Isolate a device
- Block an IP address tenant-wide
- Remove email messages
- Revoke sessions
- Modify firewall rules
For production environments, automated response should be tested, documented, and approved through proper change control.
Exam-Relevant Takeaways
For the SC-200 exam, remember these points:
- Microsoft Sentinel analytics rules are used to detect threats and generate alerts or incidents.
- Scheduled query rules use KQL and run on a schedule.
- Microsoft security incident creation rules create Sentinel incidents from Microsoft security alerts.
- Fusion rules use machine learning to correlate multiple alerts into higher-confidence incidents.
- Fusion is especially relevant for multi-stage attacks.
- Machine learning behavior analytics rules detect unusual activity based on deviations from normal behavior.
- Near real-time analytics rules are used when faster detection is required.
- Alerts are detection results.
- Incidents are investigation containers that may include one or more alerts.
- Playbooks use Azure Logic Apps to automate response actions.
- Automation rules are not the same as analytics rules.
- Analytics rules should be tuned to reduce false positives.
- Sentinel depends on connected data sources. A rule cannot detect activity from data that is not being ingested.
- KQL is central to custom scheduled query analytics rules.
- Thresholds and time windows are common in analytics rule scenarios.
- Entity mapping helps Sentinel connect alerts to users, devices, IP addresses, files, and other investigation objects.
Tool / Feature Decision Guide
| Scenario | Best Microsoft Security Tool or Feature | Why |
|---|---|---|
| You need to detect suspicious activity using custom KQL logic | Scheduled query analytics rule | It runs a KQL query on a defined schedule and can generate alerts |
| You need Sentinel incidents from Microsoft Defender XDR alerts | Microsoft security incident creation rule | It creates Sentinel incidents from Microsoft security alerts |
| You need to detect a multi-stage attack across different signals | Fusion rule | Fusion correlates lower-confidence alerts into higher-confidence incidents |
| You need to detect abnormal user or device behavior | Machine learning behavior analytics rule | It identifies deviations from normal behavior patterns |
| You need very fast detection after ingestion | Near real-time analytics rule | NRT rules are designed for rapid detection |
| You need to automatically notify the SOC when an incident is created | Playbook or automation rule | Automation can trigger notifications or workflow actions |
| You need to disable a user or isolate a device after an incident | Playbook | Playbooks use Logic Apps to perform response actions |
| You need to group related alerts for investigation | Incident | Incidents act as investigation containers |
| You need to review the detection result from a rule | Alert | Alerts are generated when rule conditions are met |
| You need to tune detection logic to reduce noise | Analytics rule configuration | Thresholds, suppression, severity, and query logic can be adjusted |
| You need to investigate affected users, devices, IPs, or files | Entities in the incident | Entities provide investigation context |
| You need to improve detection after a real incident | Update or create analytics rules | Lessons learned can become improved detection logic |
KQL Notes
The lesson focuses on KQL as the query language used by scheduled query analytics rules.
KQL is used in Sentinel to search and analyze log data. In analytics rules, KQL can define the suspicious pattern Sentinel should look for.
What KQL Does in Analytics Rules
KQL helps answer questions such as:
- Which events match suspicious behavior?
- How often did an event occur?
- Which user, device, or IP address was involved?
- Did activity exceed a threshold?
- Did activity happen within a specific time window?
- Should the result generate an alert?
Simple Example: Failed Sign-In Threshold Detection
The following is a simple example to reinforce the concept of a scheduled query rule. The exact table name may vary depending on the connected data source.
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != 0
| summarize FailedSignIns = count() by UserPrincipalName, IPAddress
| where FailedSignIns >= 10
Query Breakdown
| KQL Line | Purpose |
|---|---|
SigninLogs | Queries Microsoft Entra sign-in log data |
where TimeGenerated > ago(1h) | Limits the query to the last hour |
where ResultType != 0 | Filters for failed sign-ins |
summarize FailedSignIns = count() by UserPrincipalName, IPAddress | Counts failures by user and IP address |
where FailedSignIns >= 10 | Triggers only when the threshold is met |
How This Helps in a SOC
This type of query could support an analytics rule that detects possible password spraying, brute-force attempts, or account targeting.
The analyst would then investigate:
- The user account
- The source IP address
- Whether there was a successful sign-in afterward
- MFA status
- Conditional Access results
- Related Defender XDR alerts
- Whether other users were targeted
SC-200 Exam Angle
For the exam, you should understand that KQL is commonly used when the scenario asks for custom detection logic in Sentinel.
Look for phrases like:
- “Run a query every hour”
- “Generate an alert when a threshold is exceeded”
- “Detect a specific pattern in log data”
- “Create a custom detection”
- “Use KQL to identify suspicious activity”
Those clues usually point to a scheduled query analytics rule.
Common Exam Traps
Confusing Analytics Rules with Automation Rules
Analytics rules detect suspicious activity. Automation rules manage incident workflow or trigger automated actions. If the question asks how to detect something, analytics rule is usually the better answer.
Confusing Automation Rules with Playbooks
Automation rules define when automation should occur. Playbooks perform the actual automated actions using Azure Logic Apps.
Confusing Alerts with Incidents
An alert is a detection result. An incident is the investigation container that may include one or more alerts.
Choosing Sentinel When the Data Is Not Connected
Sentinel can only detect what it can see. If the required data source is not connected, an analytics rule cannot detect activity from that source.
Choosing a Scheduled Rule When Near Real-Time Detection Is Required
If the scenario emphasizes rapid detection immediately after ingestion, consider an NRT analytics rule instead of a standard scheduled query rule.
Missing the Fusion Rule Clue
If the question describes a multi-stage attack or the need to correlate multiple low-confidence alerts, Fusion is likely the answer.
Overusing Manual Investigation
If the scenario asks how to standardize or automate response, consider automation rules or playbooks instead of relying only on manual analyst action.
Using Destructive Automation Too Early
For real-world and exam scenarios, be careful with broad automated actions such as disabling users, isolating devices, or blocking IPs. Microsoft often expects appropriate scope, validation, and least-impact response.
Real-World SOC Analyst Notes
Alert Fatigue
Analytics rules can create a lot of noise if they are not tuned. A noisy rule may technically work but still fail operationally because analysts start ignoring it.
Good SOC teams review noisy detections and adjust thresholds, filters, suppression, and entity mapping.
False Positives
Not every alert means compromise. Some activity may be expected for administrators, service accounts, scanners, vulnerability tools, or scheduled jobs.
Useful tuning methods include:
- Watchlists
- Allowlisted IP ranges
- Known service accounts
- Threshold adjustments
- Time-based filters
- Suppression rules
- Better entity mapping
Investigation Quality
A good analytics rule should provide enough context for investigation. If a rule only says “suspicious activity detected” but does not clearly identify the user, device, IP address, or event details, the analyst has more manual work to do.
Entity mapping is important because it improves how Sentinel connects alerts to investigation objects.
Escalation Paths
Analytics rules should align with SOC escalation processes. For example:
- Low severity: Tier 1 triage
- Medium severity: Tier 1 investigation with possible Tier 2 escalation
- High severity: Tier 2 or incident response escalation
- Critical severity: immediate response workflow
Evidence Preservation
Before taking disruptive action, analysts should preserve evidence where possible. That may include alert details, timelines, endpoint data, sign-in logs, email headers, file hashes, IP addresses, and analyst notes.
Automation Safety
Automation can help reduce response time, but it must be implemented carefully. Actions like disabling accounts or isolating endpoints should be tested and approved. Poorly designed automation can cause business disruption.
Tenant-Wide Impact
Sentinel and Defender actions can affect large parts of the tenant. Blocking an IP, disabling a user, or changing incident automation can have broad operational impact.
Cost Considerations
Microsoft Sentinel costs are influenced by data ingestion and retention. More connected data sources may improve detection coverage, but they can also increase cost. SOC teams need to balance visibility, retention, and budget.
Continuous Detection Improvement
After an incident, analysts and detection engineers should ask:
- Did an existing rule detect this?
- Did it detect the activity early enough?
- Was the severity correct?
- Were the right entities mapped?
- Was the alert noisy or useful?
- Should the hunting query become an analytics rule?
- Should automation be added or adjusted?
This is how Sentinel becomes more effective over time.
Quick Reference Summary
- Analytics rules are Sentinel’s detection rules.
- Scheduled query rules use KQL.
- Microsoft security incident creation rules create Sentinel incidents from Microsoft security alerts.
- Fusion rules use machine learning to correlate alerts into multi-stage incidents.
- Machine learning behavior analytics rules detect abnormal behavior.
- NRT rules are used for faster detection after ingestion.
- Alerts are generated by rules.
- Incidents group alerts for investigation.
- Playbooks automate response using Azure Logic Apps.
- Automation rules help manage incident workflow and trigger automation.
- Rule tuning is necessary to reduce false positives.
- Sentinel detection depends on connected data sources.
- KQL is essential for custom Sentinel detections.
- Entity mapping improves incident investigation.
- Fusion is strongly associated with multi-stage attack correlation.
Flashcards
Q: What is the main purpose of Microsoft Sentinel analytics rules?
A: To detect suspicious activity, anomalies, known attack patterns, and indicators of compromise in connected data sources.
Q: Which Sentinel analytics rule type uses KQL?
A: Scheduled query rules.
Q: What does a scheduled query rule do?
A: It runs a KQL query on a defined schedule and can generate alerts when conditions are met.
Q: What is the purpose of Microsoft security incident creation rules?
A: To create Sentinel incidents from alerts generated by Microsoft security products.
Q: What type of analytics rule is best for detecting multi-stage attacks?
A: Fusion rules.
Q: Why are Fusion rules useful?
A: They use machine learning to correlate multiple lower-confidence alerts into higher-confidence incidents.
Q: What type of rule is designed for faster detection after data ingestion?
A: Near real-time analytics rules.
Q: What is the difference between an alert and an incident?
A: An alert is a detection result; an incident is an investigation container that may include one or more alerts.
Q: What Microsoft technology powers Sentinel playbooks?
A: Azure Logic Apps.
Q: What is the difference between an analytics rule and a playbook?
A: An analytics rule detects suspicious activity; a playbook performs automated response actions.
Q: What is the difference between an automation rule and a playbook?
A: An automation rule determines when automation should run; a playbook performs the response workflow.
Q: Why is entity mapping important?
A: It helps connect alerts to users, devices, IP addresses, files, URLs, and other investigation objects.
Q: Why must Sentinel data connectors be configured correctly?
A: Sentinel cannot detect activity from data sources that are not being ingested.
Q: What is a common reason to tune analytics rules?
A: To reduce false positives and alert fatigue.
Q: When should a hunting query become an analytics rule?
A: When the query identifies repeatable suspicious behavior that should be monitored continuously.
Practice Questions
Question 1:
You need to detect when a user has more than 10 failed sign-in attempts from the same IP address within one hour. The detection should run repeatedly and generate an alert when the threshold is met.
A. Create a Microsoft security incident creation rule
B. Create a scheduled query analytics rule using KQL
C. Create a Fusion rule
D. Create a workbook
Correct Answer:
B. Create a scheduled query analytics rule using KQL
Explanation:
Scheduled query rules use KQL to evaluate log data on a defined schedule. This scenario requires custom detection logic with a threshold and time window, which is a strong fit for a scheduled query analytics rule.
Question 2:
A SOC wants Microsoft Sentinel to correlate multiple low-confidence alerts across identity, endpoint, and cloud activity into a higher-confidence incident that may represent a multi-stage attack.
A. Scheduled query rule
B. Fusion rule
C. Watchlist
D. Workbook
Correct Answer:
B. Fusion rule
Explanation:
Fusion rules use machine learning to correlate related alerts and are especially useful for detecting multi-stage attacks.
Question 3:
Microsoft Defender XDR is already generating alerts. You want those alerts to create incidents in Microsoft Sentinel for centralized SOC investigation.
A. Create a Microsoft security incident creation rule
B. Create a near real-time analytics rule
C. Create a watchlist
D. Create a workbook
Correct Answer:
A. Create a Microsoft security incident creation rule
Explanation:
Microsoft security incident creation rules are used to create Sentinel incidents from Microsoft security alerts, including alerts from Microsoft Defender products.
Question 4:
An analytics rule has generated an alert for suspicious activity involving a user account, device, and IP address. What should the analyst review to understand the related objects involved in the incident?
A. Workbooks
B. Entities
C. Azure subscriptions
D. Data connectors only
Correct Answer:
B. Entities
Explanation:
Entities represent related investigation objects such as users, devices, IP addresses, files, URLs, and cloud resources. They help analysts understand scope and relationships during incident investigation.
Question 5:
You need an automated workflow to notify Microsoft Teams and create a ticket whenever a high-severity Sentinel incident is created. What Sentinel feature should perform the workflow actions?
A. Playbook
B. Fusion rule
C. Scheduled query rule
D. Hunting bookmark
Correct Answer:
A. Playbook
Explanation:
Playbooks are built on Azure Logic Apps and are used to perform automated response actions such as sending notifications, creating tickets, or enriching incidents.