Before Lab 4.6 — From Query to Detection
Before Lab 4.6 — From Query to Detection
A KQL query finds data. An analytics rule detects patterns. An incident triggers response. This section covers the transition from manual investigation to automated detection.
Analytics rules: automated detection
An analytics rule is a KQL query that runs automatically on a schedule. When the query matches data, it creates an incident that analysts can investigate.
Analytics rule properties
| Property | Description | Example |
|---|---|---|
| Name | Human-readable rule name | "Direct access to internal backend" |
| Description | What the rule detects | "Detects external IP accessing the internal backend API" |
| Severity | High, Medium, Low, Information | High |
| Tactics | MITRE ATT&CK tactic | Initial Access, Lateral Movement |
| Techniques | MITRE ATT&CK technique | T1021.004 (Remote Services), T1190 (Exploit Public-Facing Application) |
| Query | KQL query that detects the pattern | See query below |
| Schedule | How often the query runs | Every 5 minutes |
| Trigger threshold | Number of matches to create an incident | 1 or more |
| Time window | How far back the query looks | Last 5 minutes |
Example: Direct internal backend access rule
AzureDiagnostics
| where ResourceType == "WEBSITES"
| where Category == "AppServiceHTTPLogs"
| where urlPath has_any ("/internal", "/internal/data", "/internal/health")
| where clientIp !starts_with "10."
| where clientIp !starts_with "172."
| where clientIp !starts_with "192.168."
| summarize count() by clientIp, urlPath, TimeGenerated
| where count_ >= 1This rule detects HTTP requests to internal backend paths (/internal/*) from external IP addresses. Internal IP ranges (10.x, 172.16-31.x, 192.168.x) are excluded because they represent legitimate internal access.
Rule tuning
Not every match is a real threat. Rules need tuning to reduce false positives:
| Tuning Action | Effect |
|---|---|
| Increase threshold | Fewer incidents, but may miss low-volume attacks |
| Narrow time window | More precise detection, may miss slow attacks |
| Add exclusions | Reduces false positives from known good sources |
| Add exclusions for known IPs | Reduces false positives from CI/CD systems, monitoring tools |
| Change severity | Adjusts incident priority |
Incidents: structured security events
When an analytics rule matches data, Sentinel creates an incident. An incident is a structured record that contains:
| Field | Description |
|---|---|
| Title | Auto-generated summary of the detection |
| Severity | High, Medium, Low, Information |
| Status | New, In Progress, Closed |
| Owner | Assigned analyst |
| Timeline | All related log entries that triggered the rule |
| MITRE mapping | Tactics and techniques associated with the incident |
| Related incidents | Other incidents triggered by the same analytics rule |
Incident lifecycle
Incident investigation workflow
A structured incident investigation ensures thorough analysis:
- Receive alert — Notification from Sentinel analytics rule
- Review title and severity — Understand what was detected and its priority
- Review timeline — See all related log entries in the incident
- Identify source IP — Where did the request come from?
- Identify target endpoint — What was accessed?
- Correlate with other data — Check AppTraces for context
- Determine next actions — Block IP, revoke credentials, isolate system?
Tip: Modern Sentinel and Defender include AI-powered tools — Entity Analyzer for entity enrichment, Security Copilot for threat analysis, and dedicated agents for phishing triage, conditional access optimization, and incident summarization. In a real SOC, analysts use these tools alongside the manual investigation process.
Creating an analytics rule from a KQL query
Any KQL query that detects a security-relevant pattern can be converted into an analytics rule:
Manual KQL query → Validate against data → Convert to analytics rule → Schedule automaticallyThe conversion process:
- Write the query — Test it in the KQL playground to ensure it returns the expected data
- Validate — Run the query over a longer time period to check for false positives
- Convert — Click "New analytics rule" in the KQL query blade
- Configure — Set name, severity, tactics, techniques, schedule
- Test — Run the rule manually to verify it creates incidents correctly
- Activate — Enable the rule for automatic scheduling
Detection engineering: connecting to Day 2 concepts
The detection rules you create in this lab connect directly to the network security controls from Day 2:
| Day 2 Control | Day 4 Detection |
|---|---|
| Internal backend on private network | "Direct access to internal backend" analytics rule |
| NSG rules | "Unusual outbound connections" hunting query |
| Private endpoints | "Private endpoint removed" Activity Log alert |
| Network segmentation | "Cross-subnet traffic" KQL investigation |
This reinforces the principle: controls and detections should be aligned. If you implement a network control, you should also have a detection rule that fires if that control is bypassed.
Advanced detection: Fusion rules
Analytics rules detect specific patterns. Fusion rules detect complex multi-stage attacks by correlating signals across multiple products (Azure AD, Defender, Sentinel) using machine learning.
- Fusion combines low-fidelity alerts into high-confidence incidents
- It reduces false positives by requiring multiple correlated signals
- The Advanced Multistage Attack Detection rule is enabled by default in Sentinel
- You cannot customize the Fusion logic — it uses hidden ML algorithms
Fusion rules complement your custom analytics rules: use analytics rules for known patterns, and let Fusion catch complex attacks that span multiple products.
Advanced detection: multi-stage exfiltration analytics
The query you ran in Lab 4.5 (Query 11) demonstrates cross-table correlation — joining data from multiple tables to identify a complete attack chain: reconnaissance, credential theft, and data access. This is where KQL hunting becomes a production-grade analytics rule.
A single-table rule detects an individual event. A multi-table rule detects a pattern — the sequence of events that an attacker must perform. The key difference:
| Rule type | What it detects | Example |
|---|---|---|
| Single-table | An individual event | "A failed Key Vault access" |
| Cross-table | A chain of events | "An unknown IP accessed the API, retrieved secrets, then accessed data via dependencies" |
Converting a hunting query to an analytics rule follows the same process as simpler queries (validate → tune → convert → schedule), with two additional considerations: multi-join queries take longer to evaluate (consider breaking into two rules if needed), and multi-stage attacks unfold over minutes to hours, so use a lookback window that captures the full chain.
Reference: The full exfiltration query from Lab 4.5 is available in the lab PDF. In production, you would add entity mappings (ClientIp → IP, SecretNames → Account) and configure severity based on a risk score derived from the stages observed.
Lab 4.6 objectives
Lab 4.6 goals
After this lab: automated response
Once you have analytics rules firing incidents, the next step is automated response — letting Sentinel respond without human intervention. This is where playbooks (SOAR) come in. A playbook can automatically block an IP address, disable a compromised user account, or send a Teams message to the security team when an incident is created.
Key questions before starting
- What is the difference between a manual KQL query and an analytics rule?
- Why do analytics rules have a schedule instead of running continuously?
- How does the MITRE ATT&CK framework help with incident investigation?
- If an analytics rule creates too many false positive incidents, what should you do?
Lab File
Download Lab 4.6 — Analytics Rule and Incident PDF