Skip to article
Security Microsoft Sentinel

Analytic rule

An analytic rule is a Microsoft Sentinel detection rule that turns scheduled, near-real-time, Microsoft security, machine learning, or threat intelligence logic into alerts and incidents.

Source: Microsoft Learn - Create scheduled analytics rules in Microsoft Sentinel Reviewed 2026-05-10

Exam trap
Treating Analytic rule as a label instead of verifying the exact Azure resource, owner, and runtime behavior it controls.
Production check
Can you show which Azure resource owns Analytic rule and which subscription or workspace contains it?
Practice this topic Microsoft Learn
Article details and learning context
Aliases
None listed
Difficulty
intermediate
CLI mappings
3
Last verified
2026-05-10
Learning paths Graph Security concept cluster Analytic rule
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Analytic rule means a detection checkpoint that asks whether incoming security data matches a pattern worth investigating. Teams usually notice it around Log Analytics workspace, Defender portal, and Sentinel incidents queue. It matters because it turns raw security telemetry into a controlled operational response instead of leaving analysts to hunt every signal manually. The habit is to connect the term to the boundary it controls, the owner who changes it, and evidence that proves it worked in production.

Why it matters

Analytic rule matters because it turns raw security telemetry into a controlled operational response instead of leaving analysts to hunt every signal manually. In enterprise environments, the term is rarely isolated; it affects ownership, approvals, monitoring, troubleshooting, and rollback. A weak design can create hidden coupling between clients, operators, security reviewers, and finance teams. A strong design gives people a named checkpoint for what should be configured, what could fail, and what evidence should be saved. Learners should ask which boundary the term changes, which users or services depend on it, and which measurable outcome proves the change helped rather than only moving complexity elsewhere.

Official wording and source

An analytic rule is a Microsoft Sentinel detection rule that turns scheduled, near-real-time, Microsoft security, machine learning, or threat intelligence logic into alerts and incidents. Microsoft Learn places it in Create scheduled analytics rules in Microsoft Sentinel; operators confirm scope, configuration, dependencies, and production impact.

Open Microsoft Learn

Technical context

Technically, Analytic rule sits in Microsoft Sentinel analytics and is configured through Azure control-plane settings, portal workflows, REST APIs, or command-line automation. Important properties include KQL query logic, schedule, lookback window, severity, tactics, entity mappings, incident settings, suppression, and automation rules. It interacts with identity, networking, diagnostics, policy, and release pipelines depending on the workload. Operators should know which resource owns the setting, which data plane it affects, and which output proves the runtime state after a deployment or investigation.

Exam context

Compare with

Alert rule Activity Log alert

Where it is used

Where you see it

  1. You see it on the Microsoft Sentinel Analytics page when scheduled, NRT, Fusion, or template-based detections are enabled, disabled, tuned, or exported. during governed production operations
  2. It appears in incident timelines when a rule turns matching log data into alerts, maps entities, and optionally groups alerts into incidents. during governed production operations
  3. It shows up in SOC tuning sessions when analysts adjust KQL, severity, suppression, lookback windows, tactics, or automation to reduce false positives. during governed production operations

Common situations

  • Use Analytic rule to make Microsoft Sentinel analytics behavior measurable and reviewable.
  • Use Analytic rule during incident response when ownership, configuration, or runtime evidence must be proven.
  • Use Analytic rule in deployment automation so environments do not drift silently.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Identity abuse detection Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Northbridge Credit Union, a regional financial institution, needed Sentinel to detect impossible travel and risky sign-ins without overwhelming analysts during branch expansion.

Goals
  • detect high-risk sign-ins within 15 minutes
  • reduce false-positive identity alerts by 35 percent
  • map users, IP addresses, and hosts into incidents
  • export rule configuration for audit evidence
Approach using Analytic rule

The security team created a scheduled analytic rule using KQL against identity, sign-in, and Defender tables. They tuned the lookback window, mapped user and IP entities, grouped related alerts into one incident, and attached an automation rule that notified the identity response queue. The rule was stored as an ARM template for change control, and CLI checks listed active rules before each monthly review. Analysts documented suppression logic, expected table freshness, and a manual rerun process for suspected missed detections. The change record named the service owner, rollback evidence, review cadence, expected operational signals, and post-deployment verification steps so support teams could validate the rollout without guessing during incidents.

Potential outcomes
  • mean detection time fell from 2 hours to 11 minutes
  • false positives dropped 42 percent after entity mapping and exclusions were tuned
  • audit preparation took one hour because the rule export matched the change record
  • identity incidents included enough context for tier-one analysts to triage safely
What to learn

An analytic rule is valuable because it turns security telemetry into a governed, measurable detection workflow.

Scenario 02 Manufacturing ransomware watch Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Pelican Forge, a manufacturing company, wanted earlier warning when ransomware indicators appeared across file servers, VPN logs, and endpoint alerts.

Goals
  • correlate endpoint and network signals in Sentinel
  • create incidents only for meaningful combinations
  • cut overnight analyst paging by 25 percent
  • keep detection logic reviewable by security leadership
Approach using Analytic rule

Engineers built an analytic rule that joined Defender alerts, VPN sign-ins, and file-share audit events. The query looked for suspicious encryption tools followed by unusual remote access and rapid file modifications. Severity was set to high only when at least two signal types matched. The team used rule templates as a starting point, then saved the finished rule with version notes. CLI inventory and Sentinel rule insights supported weekly tuning, while incident grouping prevented multiple alerts from flooding the queue. The change record named the service owner, rollback evidence, review cadence, expected operational signals, and post-deployment verification steps so support teams could validate the rollout without guessing during incidents.

Potential outcomes
  • overnight pages fell 31 percent without disabling critical ransomware coverage
  • the first matched incident identified a compromised contractor account in 18 minutes
  • rule review time dropped by 50 percent because KQL and mappings were documented
  • security leadership approved the detection because alert grouping showed clear evidence
What to learn

Analytic rules work best when the detection logic, entities, schedule, and response path are designed together.

Scenario 03 Healthcare insider-risk signal Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Lakeside Medical Group, a healthcare provider, needed a controlled way to detect unusual access to patient billing exports after a compliance review.

Goals
  • monitor sensitive export activity daily
  • link suspicious events to user and workstation entities
  • avoid exposing patient data in alert descriptions
  • prove compliance tuning during quarterly audit
Approach using Analytic rule

The SOC created a Sentinel analytic rule that queried audit logs for large billing exports outside approved workflows. The rule mapped user, host, and IP entities while redacting sensitive file names from alert details. It used a schedule aligned to billing operations and attached a playbook that opened a compliance review task. The platform team tested the KQL with historical data, exported the rule as JSON, and added runbook steps for manual rerun after data connector delays. The change record named the service owner, rollback evidence, review cadence, expected operational signals, and post-deployment verification steps so support teams could validate the rollout without guessing during incidents.

Potential outcomes
  • suspicious export review time fell from 3 days to 6 hours
  • no patient identifiers were included in alert titles or notification payloads
  • quarterly audit evidence was accepted without extra screenshots
  • two unauthorized export attempts were escalated before files left the environment
What to learn

A well-built analytic rule gives regulated teams detection evidence without leaking the data being protected.

Azure CLI

Azure CLI is useful for Analytic rule because it turns portal state into repeatable evidence. Operators can inventory configuration, compare environments, export settings, and run safe read-only checks before they change production behavior. For some features, az rest is the right path when the service exposes detail through REST APIs faster than a dedicated command group.

Useful for

  • Inventory the Azure resource that owns Analytic rule and confirm subscription, resource group, region, and service instance before making changes.
  • Export or inspect the configuration for Analytic rule so reviewers can compare expected settings with what is actually deployed.
  • Collect diagnostics, metrics, or related resource output when an incident might involve Analytic rule but the portal view is incomplete.
  • Automate environment checks for development, test, and production so Analytic rule does not drift between releases.

Before you run a command

  • Confirm the tenant, subscription, resource group, service name, and environment because many commands succeed against the wrong scope.
  • Use a principal with read-only or narrowly scoped permissions first, then request higher privileges only for the specific change being made.
  • Know whether the command reads configuration, changes routing, exposes data, restarts work, or affects production clients before running it.
  • Choose JSON output when saving evidence so reviewers can diff values, preserve timestamps, and avoid screenshot-only change records.

What the output tells you

  • Resource identifiers and names prove whether the command inspected the intended Analytic rule boundary rather than a similar object in another environment.
  • Status, provisioning, or enabled flags show whether the setting exists, is active, and is ready for dependent services to use.
  • Related identity, network, diagnostic, or backend values explain why the feature works for one workload but fails for another.
  • Missing or unexpected values are investigation leads; they should trigger a configuration review before teams blame application code.

Mapped commands

Sentinel commands

discovery 
az sentinel incident list --resource-group <resource-group> --workspace-name <workspace-name> --output table
az sentinel incidentdiscoverSecurity
read-only Microsoft Learn 
az sentinel alert-rule list --resource-group <resource-group> --workspace-name <workspace-name> --output table
az sentinel alert-rulediscoverSecurity
read-only Microsoft Learn

Architecture context

Analytic rule belongs to Microsoft Sentinel analytics. It should be treated as a production control with identity, network, diagnostic, cost, and rollback implications.

Security
Security for Analytic rule focuses on false positives, missing entity mappings, overly broad queries, exposed investigation data, and delayed incident creation. The practical risk is that a small configuration decision can expose data, weaken identity boundaries, or hide who changed production behavior. Teams should apply least privilege, protect secrets, prefer managed identities where supported, and avoid logging sensitive payloads or credentials. Reviewers should verify network exposure, role assignments, policy exceptions, and diagnostic destinations before rollout. Security evidence should include the resource scope, authorized principals, protected endpoints, and any compensating controls needed when the feature crosses tenant, subscription, application, or partner boundaries.
Cost
Cost for Analytic rule is shaped by Log Analytics ingestion, query frequency, retention, investigation workload, automation runs, and incident noise. Some terms do not create a separate charge, but they influence the services, capacity, logging, storage, or engineering time that appear on the bill. FinOps reviews should connect the setting to request volume, retention, compute size, gateway tier, query scans, or operational rework. Teams should avoid enabling expensive behavior by default, keep ownership visible, and measure whether the benefit justifies the spend. The best cost posture records who pays, what metric is watched, and when cleanup or resizing should happen.
Reliability
Reliability for Analytic rule depends on data connector health, query schedule, lookback overlap, alert grouping, incident creation, and suppression behavior. The concept should be tested under normal operation, planned maintenance, and failure conditions, not only configured once in the portal. Teams need a rollback path, known owner, monitoring signal, and proof that dependent resources still behave correctly after changes. For production systems, include timeout behavior, retry expectations, regional or zone impact, and what happens when identity, network, or upstream services fail. Good reliability practice turns the term into an observable control with documented failure symptoms and recovery steps. This keeps review evidence useful during governed production operations.
Performance
Performance for Analytic rule depends on KQL efficiency, query window size, table volume, entity mapping, and schedule frequency. The term may affect runtime latency directly, or indirectly through routing, query shape, indexing, policy execution, data movement, or troubleshooting speed. Teams should measure before and after changes with realistic traffic, data sizes, and failure conditions. Watch for bottlenecks hidden behind gateway layers, query windows, analyzers, backends, or compute pools. Performance evidence should include the user-visible metric, the Azure-side metric, and any tradeoff against security, reliability, or cost so the improvement is not just a local optimization. This keeps review evidence useful during governed production operations.
Operations
Operations teams manage Analytic rule through rule insights, manual reruns, ARM export, template versioning, incident queues, and SOC runbooks. The goal is to make the current state inspectable without relying on memory or screenshots. Runbooks should show how to list the resource, confirm important settings, compare expected and actual output, and capture evidence after a change. Operators should document owners, approval paths, environment differences, and rollback triggers. During incidents, they should determine whether the term is the failed component, a routing or policy boundary, or simply a clue pointing to another Azure service or application dependency. This keeps review evidence useful during governed production operations.

Common mistakes

  • Treating Analytic rule as a label instead of verifying the exact Azure resource, owner, and runtime behavior it controls.
  • Changing production settings from the portal without exporting the before state, rollback value, and approval evidence.
  • Assuming development behavior matches production when identity, networking, tier, region, policy, or data volume is different.
  • Troubleshooting only the application layer before checking Azure configuration, diagnostics, metrics, and dependent service health.