Lesson 29 — Microsoft Security Analytics Rules
Not every Microsoft Sentinel incident begins with a KQL query.
Microsoft security products can already generate their own alerts. Sentinel can ingest those alerts and, in the appropriate deployment model, Microsoft security analytics rules can turn them into incidents for investigation.
The important question is: who created the alert, and who is responsible for creating the incident?
What you will learn
Understand how Microsoft security alerts enter Sentinel incidents and why the Defender portal changes the workflow.
Learning objectives
- Explain what Microsoft security analytics rules do.
- Distinguish them from scheduled and NRT rules.
- Understand where ingested security alerts are stored.
- Recognise when Defender XDR creates incidents instead.
- Investigate the originating provider before changing Sentinel detection logic.
The investigation
An incident appears in the SOC queue, but nobody can find the KQL analytics query that supposedly created it.
That is the clue: perhaps Sentinel did not detect the original activity at all. Another Microsoft security product created the alert first.
Two different detection paths
Scheduled rules detect from log data
Scheduled analytics rules query ingested log data using KQL. When the query and rule conditions are satisfied, Sentinel generates an alert and can create an incident.
Microsoft security rules start with an alert
Microsoft security analytics rules work differently. The originating Microsoft security product has already generated the alert.
The rule is used to create a Sentinel incident from that ingested Microsoft security alert in real time.
Examples of originating Microsoft security products
Microsoft documents this rule type for alerts generated by other Microsoft security solutions, including products such as Microsoft Defender XDR and Microsoft Defender for Cloud.
The key idea is not the product name. It is the ownership of the original detection: the source security product detected the activity and generated the alert before Sentinel received it.
The SecurityAlert table
Security alerts from different sources are stored together in the SecurityAlert table in the Log Analytics workspace.
This gives the analyst a useful place to inspect alert evidence and identify where the alert originated.
Provider and product matter
Fields such as ProviderName, ProductName and VendorName can help identify the system responsible for producing the alert.
That matters when troubleshooting why an alert exists or deciding where the underlying detection must be tuned.
Investigate the alert source with KQL
- 1
- 2
- 3
- 4
- 5
- 6
SecurityAlert
| where TimeGenerated > ago(24h)
| project TimeGenerated,
AlertName,
ProviderName,
ProductName,
VendorName
Instead of assuming every incident came from a custom Sentinel query, inspect the alert's provider and product first.
The investigation changes direction
The alert was produced by a connected Microsoft security product. Searching through every custom Sentinel scheduled rule was never going to find the original detection logic.
The next question becomes: where is the originating product's alert logic configured, and is Sentinel merely receiving and operationalising that alert?
Microsoft security rule configuration is limited
This is not the same flexible KQL rule-building experience used for scheduled analytics rules.
Microsoft describes Microsoft security templates as specialised templates that create a rule instance with limited configuration options.
Why that makes sense
The original detection already happened elsewhere.
Sentinel is not rebuilding the source product's detection query. It is determining how those incoming alerts participate in the Sentinel incident workflow.
The Defender portal changes the model
Microsoft security analytics rules are not available when Microsoft Defender XDR incident integration is enabled or when Microsoft Sentinel is onboarded to the Microsoft Defender portal.
In those scenarios, Microsoft Defender XDR creates the incidents instead. Microsoft states that previously defined Microsoft security rules are automatically disabled.
If your Sentinel environment is operating through the Defender portal, do not expect to build this legacy incident-creation path in the same way. The unified Defender correlation and incident model takes over.
Why this matters in 2026
Microsoft's Sentinel architecture is increasingly centred on the Microsoft Defender portal. Microsoft has announced that Sentinel support in the Azure portal ends after 31 March 2027, with customers redirected to the Defender portal.
That makes it important to understand Microsoft security analytics rules historically and operationally, while also understanding that Defender XDR incident correlation is the direction of the unified experience.
Do not tune the wrong system
If an alert originates in another Microsoft security product, editing an unrelated Sentinel scheduled rule will not change that source detection.
Identify the provider first, then investigate the control point that actually generated the alert.
Do not confuse ingestion with detection
Seeing an alert inside Sentinel does not prove Sentinel detected the original behaviour.
Sentinel may be receiving an alert that was already created by another security product.
Follow the evidence backwards
Common mistake — assuming every alert is KQL
KQL is central to many Sentinel detections, but Microsoft security alerts can arrive already formed.
Always identify the detection source before looking for query logic.
Common mistake — duplicating incidents
Building overlapping incident creation paths without understanding Defender XDR integration can create confusing operations.
Know which platform is responsible for correlation and incident creation in your deployment.
Common mistake — ignoring the portal model
Documentation and screenshots from older Sentinel deployments can show controls that are no longer relevant when Sentinel is onboarded to Defender.
Always interpret rule behaviour in the context of the portal and integration model you are actually using.
Common mistake — treating all alerts equally
The SecurityAlert table contains alerts from different sources.
Provider, product, severity, tactics, techniques, entities and other alert properties help establish what produced the signal and how it should be investigated.
Agent Foskett investigation exercise
You cannot find a matching custom Sentinel analytics query. What do you check next?
- Open the incident and identify the alert or alerts it contains.
- Inspect the alert provider and product.
- Query
SecurityAlertif you need additional alert metadata. - Determine whether Sentinel or another Microsoft security product generated the original alert.
- Confirm whether Defender XDR is responsible for incident correlation in the current deployment.
Best practices
- Identify the alert provider before changing detection logic.
- Understand the difference between detecting activity and creating an incident.
- Use
SecurityAlertto investigate alert provenance. - Know whether Defender XDR incident integration is enabled.
- Avoid duplicating incident creation paths.
- Design for the current Defender portal architecture.
Agent Foskett takeaway
The alert appearing in Sentinel does not tell you who detected the activity.
Follow the alert back to its provider. The logs — and the alert metadata — already knew.
Related Agent Foskett learning
Continue learning
Microsoft Security Analytics Rules in Microsoft Sentinel
Microsoft security analytics rules create Microsoft Sentinel incidents from alerts generated by connected Microsoft security products. In Microsoft Defender XDR integrated and Defender portal environments, Defender XDR is responsible for incident creation and correlation instead.
Microsoft Sentinel Lesson 29
This Agent Foskett Microsoft Sentinel Academy lesson explains Microsoft security analytics rules, the SecurityAlert table, alert provenance, Microsoft Defender integration and the difference between source-product detection and Sentinel incident creation.
