Microsoft Sentinel is a cloud-native SIEM and SOAR. If you’re new to it, here’s a grounded introduction that skips the marketing language.
Table of contents
Open Table of contents
What Sentinel Actually Is
Sentinel lives on top of Azure Log Analytics. Every piece of data you ingest goes into a Log Analytics workspace. You query it with KQL. Sentinel adds the analytics rules, incident management, threat intelligence, and automation layer on top.
Understanding that it’s fundamentally a Log Analytics workspace explains a lot: the cost model (you pay per GB ingested and per GB retained), the query interface, and why connecting data sources means configuring data connectors that route logs to your workspace.
First Things to Connect
Don’t try to connect everything on day one. Start with:
- Azure Activity Logs — free, and tells you what’s happening in your Azure environment immediately
- Microsoft Entra ID Sign-in and Audit Logs — the single most useful data source if you’re in an M365 environment
- Microsoft 365 Defender — connects your endpoint, email, and identity signals in one place
- Windows Security Events — via AMA on your key servers, or via WEF (see my other post on that)
Leave everything else until you have a handle on the above.
The Cost Problem
Sentinel’s cost model bites people who don’t plan for it. You pay for:
- Data ingestion: ~£2.50/GB for pay-as-you-go (commitment tiers reduce this significantly)
- Data retention: 90 days free, then ~£0.12/GB/month beyond that
Common expensive mistakes:
- Forwarding verbose diagnostic logs that have no security value
- Retaining everything indefinitely when 90 days covers most investigations
- Enabling all available data connectors without understanding their log volume
Before enabling any data connector, check what tables it writes to and estimate volume. The Usage table in your workspace shows you what’s actually being ingested.
Usage
| where TimeGenerated > ago(7d)
| summarize TotalGB = sum(Quantity) / 1000 by DataType
| sort by TotalGB descThis query will quickly show you which data sources are your biggest cost drivers.
Analytic Rules
Sentinel comes with hundreds of built-in analytics rules (Microsoft Security Research content). Don’t enable all of them on day one.
The process that works:
- Enable rules covering your connected data sources
- Run them in alert mode (not incident) for the first couple of weeks
- Tune the ones generating noise before they become incidents
- Only then switch to incident creation
Tuning matters more than coverage. A well-tuned ruleset of 30 rules is far more useful than 200 rules drowning you in false positives.
KQL Basics Worth Knowing
You’ll spend a lot of time in KQL. The operators you’ll use constantly:
// Filter rows
SecurityEvent
| where EventID == 4625
// Summarise
SecurityEvent
| where EventID == 4625
| summarize FailedLogons = count() by Account, Computer
// Join two tables
SigninLogs
| where ResultType != 0
| join kind=inner (
AuditLogs
| where OperationName == "Add member to role"
) on $left.UserId == $right.InitiatedBy
// Time windows
| where TimeGenerated between (ago(24h) .. now())The KQL quick reference is worth bookmarking.
Automation with Playbooks
Sentinel’s automation runs on Logic Apps. For common response actions:
- Isolate a device in Defender via API
- Post an alert to a Teams channel
- Create a ticket in ServiceNow or Jira
- Enrich an incident with threat intelligence from external sources
Start simple: a playbook that posts new high-severity incidents to a Teams channel is immediately useful and takes 15 minutes to set up.
The Honest Take on Sentinel
It’s genuinely capable tooling, but Microsoft’s documentation ranges from excellent to awful depending on the feature. The community resources (GitHub, Tech Community blogs) are often better than the official docs for specific problems.
The learning curve isn’t the technology — it’s learning what data you actually have, what detections make sense for your environment, and how to tune out the noise. That part takes time regardless of what SIEM you’re using.