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.

Microsoft Sentinel Analytics Rules – SC-200 Study Guide

Watch this lesson