What Is Microsoft Sentinel: A SIEM You Actually Operate in Production

Microsoft Sentinel is a cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response) that runs entirely inside Azure. No appliances, no on-prem log collectors you have to patch, no vendor-managed Elasticsearch cluster to babysit. You point data connectors at your sources, write detection rules in KQL, and wire automated responses through Logic Apps. That is the pitch. The reality is more textured, and this note covers both.

What Sentinel Actually Is Under the Hood

Sentinel is, at its core, a Log Analytics workspace with a security product layered on top. Every log you ingest lands in a Log Analytics workspace in a region you control. Sentinel adds the detection engine, incident management UI, workbooks, and the SOAR playbook runner. Remove Sentinel from the subscription and the raw workspace and data stay put.

This architecture matters for two reasons. First, you query your logs with KQL (Kusto Query Language) everywhere: detection rules, workbooks, hunting queries, investigation timelines. One query language for the entire product. Second, your raw tables are always accessible to other Azure services, so Power BI reports, Defender XDR cross-workspace joins, and Azure Data Explorer exports all share the same data without a separate pipeline.

The workspace stores data in well-known table names. SecurityEvent for Windows event logs from the MMA or AMA agent. AzureActivity for control-plane operations. SigninLogs for Entra ID authentications. CommonSecurityLog (CEF format) for most third-party firewalls and network appliances. Getting familiar with the table schema catalog is the actual first week of any Sentinel engagement.

The Connector Layer: Where Most Projects Get Stuck

Sentinel ships with roughly 300 data connectors. Microsoft-first connectors (Entra ID, Defender for Endpoint, Azure Activity, Office 365) are single-click and work reliably. Everything else ranges from "mostly fine" to "read the connector's GitHub issues first."

Common categories:

Microsoft-native connectors: Entra ID sign-in logs, Defender XDR integration, Azure Diagnostics, Office 365 audit logs. These use the Diagnostic Settings API and are generally stable.
Agent-based Windows connectors: Azure Monitor Agent (AMA) with Data Collection Rules (DCRs). The older Microsoft Monitoring Agent (MMA) is deprecated; if you are still running it, migration is not optional.
CEF over Syslog: Palo Alto, Fortinet, Check Point, Cisco ASA. You deploy a Linux syslog forwarder VM, run the onboarding script, and the appliance sends CEF to that VM which forwards to the workspace. The forwarder VM is a single point of failure unless you front it with a load balancer.
Third-party API connectors: Many newer connectors use Azure Functions that poll a vendor API on a schedule and write to a custom log table. Cost and latency vary enormously by vendor.

The thing that catches teams off guard is that not all connector types land data in the same latency window. Diagnostic Settings connectors deliver in roughly 1-5 minutes. Agent-based connectors depend on the agent flush interval. API-polled connectors may have a 5-15 minute lag baked in. That lag matters when you are writing detections that correlate events across sources.

Writing Detection Rules in KQL

Scheduled analytics rules are the backbone of Sentinel detection. A rule runs a KQL query on a cadence you set (as low as 5 minutes), evaluates the result, and opens an incident if results exceed a threshold. Here is a working example that surfaces impossible-travel sign-ins from Entra ID logs:

let lookback = 1h;
let distance_threshold_km = 500;
SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType == 0
| extend City = tostring(LocationDetails.city)
| extend CountryCode = tostring(LocationDetails.countryOrRegion)
| extend Lat = todouble(LocationDetails.geoCoordinates.latitude)
| extend Lon = todouble(LocationDetails.geoCoordinates.longitude)
| project TimeGenerated, UserPrincipalName, IPAddress, City, CountryCode, Lat, Lon, AppDisplayName
| sort by UserPrincipalName asc, TimeGenerated asc
| serialize
| extend PrevTime   = prev(TimeGenerated, 1)
| extend PrevLat    = prev(Lat, 1)
| extend PrevLon    = prev(Lon, 1)
| extend PrevUser   = prev(UserPrincipalName, 1)
| where UserPrincipalName == PrevUser
| extend ElapsedHours = datetime_diff('minute', TimeGenerated, PrevTime) / 60.0
| extend DistanceKm = geo_distance_2points(Lon, Lat, PrevLon, PrevLat) / 1000.0
| where ElapsedHours > 0 and DistanceKm > distance_threshold_km
| extend SpeedKmh = DistanceKm / ElapsedHours
| where SpeedKmh > 800
| project TimeGenerated, UserPrincipalName, IPAddress, City, CountryCode, DistanceKm, SpeedKmh, AppDisplayName

This query runs fine in the Sentinel logs blade before you promote it to a rule. The geo_distance_2points function is built into KQL. The serialize + prev() pattern is how you do row-over-row comparisons without a self-join. We tune the distance_threshold_km and SpeedKmh cutoffs per customer based on their actual geography and user base.

Rules also support MITRE ATT&CK tactic and technique tagging, entity mapping (which fields map to Account, Host, IP, URL), and alert grouping logic. Entity mapping is worth spending time on because it drives the Entity Behavior Analytics (UEBA) features and the investigation graph.

SOAR: Playbooks and Where They Are Practical

Sentinel playbooks are Azure Logic Apps triggered by analytics rule alerts or incidents. Common automated responses we deploy in production:

Enrich an IP alert with threat intelligence from Microsoft Defender Threat Intelligence or a third-party TI feed, then add a comment to the incident with the verdict.
Revoke Entra ID refresh tokens for an account flagged for impossible travel or credential-stuffing behavior.
Post a structured incident card to a Teams channel or Slack so the SOC sees it without logging into the Sentinel portal.
Create a ServiceNow or Jira ticket from a high-severity incident and populate the standard fields automatically.

The Logic Apps runtime handles the trigger plumbing. The risk is that Logic Apps have their own pricing, their own failure modes, and their own connection credential lifecycle. A playbook that authenticates via a managed identity is easier to maintain than one relying on a user-assigned service account that someone will eventually deactivate.

For response actions that need more than Logic Apps can express cleanly, the pattern we use is: Logic App calls an Azure Function, function contains the real business logic in Python or TypeScript, Logic App just handles the Sentinel event binding and the output notification.

Pricing: The Variable That Changes the Conversation

Sentinel bills on two dimensions: data ingestion and data retention beyond 90 days.

The ingestion model has two paths. Pay-as-you-go is roughly $2.46 per GB ingested (rates as of mid-2026; check the Azure pricing calculator for current figures). Commitment tiers start at 100 GB/day and discount the per-GB rate by 15-65% depending on the tier.

The first thing any new customer gets wrong is not understanding which tables count toward billable ingestion. Several tables are free: SecurityAlert, ThreatIntelligenceIndicator, SecurityIncident, and a handful of others. High-volume noisy tables like AzureDiagnostics and verbose Windows Security Event IDs (4663, 4688) can inflate costs fast. A 1,000-seat Microsoft 365 E5 environment typically lands between 20-80 GB/day in Sentinel depending on how many verbose sources are enabled. We almost always run a two-week trial ingestion in a separate workspace with Data Collection Rule filtering before sizing a commitment tier.

Auxiliary Logs is a newer ingestion tier at roughly $0.15/GB with limited KQL function support and 30-day retention. Useful for high-volume, low-priority logs you want to keep for compliance without paying full analytics rates.

When Sentinel Makes Sense and When It Does Not

Sentinel fits well when your estate is already Azure-heavy or Microsoft 365-heavy. The native connector quality for those sources is genuinely good. It also fits when your team knows KQL or is willing to invest in learning it; the query language is not hard to pick up but it is not optional.

It makes less sense when your primary alert sources are all on-prem with no Azure footprint, when your budget does not support even the 100 GB/day commitment tier, or when your team needs a product with a managed detection service wrapped around it out of the box. In those cases, cheaper ingestion options or a managed SIEM vendor might be the right first step.

We have also seen orgs run Sentinel alongside a dedicated data lake (Fabric or Synapse) where long-retention forensic logs live at cold-storage prices, with Sentinel holding only the hot 30-90 days. That hybrid pattern cuts retention costs meaningfully at scale.

The detection engineering work we do at KeMeT Tech sits squarely on top of platforms like Sentinel: rule authoring, KQL tuning, connector troubleshooting, SOAR playbook design, and ongoing false-positive reduction. The tool is capable. The gap is almost always in how it is configured and maintained, not in the product itself.

Next Steps

If you are sizing a Sentinel deployment, evaluating whether it fits your environment, or inheriting one that has never had a proper detection review, reach out to us at /contact and we can scope a structured assessment.