Lesson 6 — Your First Analytics Rule
Microsoft Sentinel becomes powerful when useful KQL logic is turned into repeatable detection.
Analytics rules allow Sentinel to run queries on a schedule, identify suspicious activity, create alerts and generate incidents for analysts to investigate.
In this lesson, you will learn what an analytics rule is, how query frequency and lookup period work, why entity mapping matters, and how a detection becomes a Sentinel incident.
What you will learn
This lesson explains how Sentinel turns detection logic into alerts and incidents.
Learning objectives
After completing this lesson, you should understand how a basic Microsoft Sentinel analytics rule works.
- Explain what an analytics rule does.
- Understand how KQL becomes a detection.
- Describe query frequency and lookup period.
- Understand entity mapping and why it matters.
- Explain how alerts become incidents.
The problem this solves
Security analysts can run hunting queries manually, but manual searching does not scale.
Analytics rules allow Sentinel to run detection logic repeatedly, so suspicious activity can generate alerts and incidents without waiting for an analyst to search manually.
What is an analytics rule?
A Microsoft Sentinel analytics rule is detection logic that runs against data in a Log Analytics workspace. When the rule finds matching activity, Sentinel can create alerts and incidents for investigation.
A hunting query asks, "Did this happen?" An analytics rule asks the same question repeatedly and raises a case when the answer matters.
Analytics rule workflow
The rule lifecycle connects KQL, scheduling, detection, alerting and incident response.
Query frequency
Query frequency controls how often the analytics rule runs. For example, a rule might run every 5 minutes, every hour or once per day depending on the detection requirement.
More frequent rules may detect activity faster, but they need to be designed carefully to avoid noise and unnecessary cost.
Lookup period
The lookup period controls how far back the query searches each time it runs. For example, a rule running every hour might look back over the previous hour, two hours or longer.
If the lookup period is too short, you may miss delayed data. If it is too long, you may create duplicate alerts.
Thresholds
A threshold decides when query results should become an alert. Some rules alert when there is at least one result. Other rules may require a count above a certain number.
Thresholds help reduce noise and focus analysts on activity that is more likely to matter.
Severity
Severity tells the analyst how important the rule believes the detection is. A failed sign-in may be low severity, while suspicious privilege escalation may be high severity.
Severity should match the risk of the behaviour, not just the volume of events.
Entity mapping
Entity mapping connects query columns to investigation objects such as accounts, hosts, IP addresses and URLs. This helps Sentinel understand what the detection is about.
- UserPrincipalName can map to an Account entity.
- DeviceName can map to a Host entity.
- IPAddress can map to an IP entity.
- Url can map to a URL entity.
MITRE ATT&CK mapping
Analytics rules can be mapped to tactics and techniques to help describe attacker behaviour. This improves reporting, investigation context and detection coverage analysis.
For example, a suspicious PowerShell rule might map to Execution, while a privilege change rule might map to Privilege Escalation.
Simple example rule idea
Imagine you want to detect multiple failed sign-ins followed by a successful sign-in from the same user. A hunting query may find this manually. An analytics rule can monitor for it repeatedly.
| Rule setting | Example |
|---|---|
| Query frequency | Run every 1 hour. |
| Lookup period | Look back 2 hours. |
| Threshold | Create an alert when matching users are found. |
| Severity | Medium. |
| Entity mapping | Map user, IP address and device where available. |
Incident creation
An analytics rule can create alerts and incidents when matches are found. This is where detection logic becomes an operational SOC workflow.
Without incident creation, the rule may detect activity but not create the investigation case analysts need.
Alert grouping
Alert grouping controls how related alerts are grouped into incidents. Good grouping reduces noise and helps analysts investigate related activity as one case.
Poor grouping can either flood analysts with separate incidents or hide unrelated activity inside one large case.
Testing before enabling
Before enabling a rule in production, test the query manually. Review the results, check for false positives and confirm that the rule returns the entities needed for investigation.
A rule that looks good in theory may create noise if the data is messy or the query is too broad.
Common mistake
A common mistake is building a rule that creates an incident but does not map useful entities.
If the analyst cannot quickly see the affected user, device, IP address or URL, the incident becomes harder to investigate.
Agent Foskett investigation tip
A good analytics rule should not only fire. It should give the analyst enough context to start the investigation quickly.
What to document
Every analytics rule should have a clear purpose. Document what the rule detects, why it matters and what the analyst should check next.
- Detection objective
- Data sources required
- Expected entities
- Known false positives
- Recommended triage steps
Agent Foskett takeaway
A KQL query finds evidence.
An analytics rule turns that evidence into repeatable detection.
A good rule creates an incident that helps the analyst investigate faster.
Related Agent Foskett learning
Microsoft Sentinel Academy progress
Your First Microsoft Sentinel Analytics Rule
Microsoft Sentinel analytics rules turn KQL queries into scheduled detections, alerts and incidents using query frequency, lookup period, thresholds, severity, entity mapping and alert grouping.
Microsoft Sentinel Lesson 6
This Agent Foskett Microsoft Sentinel Academy lesson explains scheduled analytics rules, KQL detection logic, incident creation, entity mapping, MITRE ATT&CK mapping and SOC investigation workflows.
