Azure Sentinel (Microsoft Sentinel)
Microsoft Sentinel is Azure’s cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation and Response) platform — a single service that collects security data from across your entire estate, detects threats using AI and analytics, investigates incidents, and automates responses.
What Sentinel Actually Is — SIEM + SOAR Combined
SIEM (Security Information and Event Management) → Collects logs from everything → Correlates events across sources → Detects threats using rules + AI → Surfaces alerts and incidentsSOAR (Security Orchestration, Automation and Response) → Automates response to detected threats → Runs playbooks (Logic Apps) automatically → Integrates with ticketing, ITSM, and remediation tools → Reduces mean time to respond (MTTR)Sentinel = both in one service, built on Log Analytics
The Four Pillars
Pillar 1 — Collect
Data flows into Sentinel through data connectors — pre-built integrations that normalise log formats and write to Log Analytics tables:
Azure native connectors (free ingestion):
- Microsoft Defender for Cloud
- Entra ID sign-in and audit logs
- Azure Activity logs (ARM operations)
- Azure Firewall logs
- NSG flow logs
- Key Vault audit logs
- Azure Kubernetes Service (AKS/ARO)
Microsoft 365 connectors:
- Microsoft 365 Defender (XDR)
- Office 365 (Exchange, SharePoint, Teams)
- Microsoft Defender for Endpoint
- Microsoft Defender for Identity
- Microsoft Defender for Cloud Apps
Third-party connectors:
- Palo Alto, Fortinet, Check Point firewalls
- Cisco ASA, Umbrella, Meraki
- Okta, CrowdStrike, SentinelOne
- AWS CloudTrail, S3 access logs
- GCP audit logs
On-premises via agents:
Windows VMs → Log Analytics Agent → SecurityEvent tableLinux VMs → Syslog → Syslog tableNetwork devices → CEF → AMA agent → CommonSecurityLog table
Pillar 2 — Detect
Sentinel detects threats through five types of analytics rules:
Scheduled rules — KQL queries on a timer
// Detect impossible travel — same user, two countries, <1 hour apartlet threshold_minutes = 60;SigninLogs| where TimeGenerated > ago(1d)| where ResultType == 0 // successful sign-in| project TimeGenerated, UserPrincipalName, Location, IPAddress, Latitude = toreal(LocationDetails.geoCoordinates.latitude), Longitude = toreal(LocationDetails.geoCoordinates.longitude)| sort by UserPrincipalName, TimeGenerated asc| extend PrevLocation = prev(Location, 1), PrevTime = prev(TimeGenerated, 1), PrevUser = prev(UserPrincipalName, 1)| where UserPrincipalName == PrevUser| extend TimeDiff = datetime_diff('minute', TimeGenerated, PrevTime)| where TimeDiff < threshold_minutes| where Location != PrevLocation| project UserPrincipalName, Location, PrevLocation, TimeDiff, IPAddress, TimeGenerated
Near Real-Time (NRT) rules — sub-1-minute detection
// Detect Azure Firewall blocking connections to known malicious IPsAzureDiagnostics| where Category == "AzureFirewallNetworkRule"| where msg_s has "Deny"| parse msg_s with * "from " SourceIP ":" SourcePort " to " DestIP ":" DestPort ". Action: " Action| join kind=inner ( ThreatIntelligenceIndicator | where Active == true | project NetworkIP, ThreatType, ConfidenceScore) on $left.DestIP == $right.NetworkIP| project TimeGenerated, SourceIP, DestIP, ThreatType, ConfidenceScore
Microsoft Security rules — auto-create incidents from Defender alerts
These automatically promote Defender for Cloud, Defender for Endpoint, and Defender for Identity alerts into Sentinel incidents with no KQL needed.
Fusion rules — ML-based multi-stage attack detection
Fusion uses machine learning to correlate low-severity signals across multiple products that individually look benign but together indicate an attack:
Signal 1: Entra ID — suspicious sign-in from anonymising proxySignal 2: Office 365 — mass email forwarding rule createdSignal 3: Azure — new service principal with owner roleIndividual signals: low severity, easy to missFusion correlation: HIGH severity — likely BEC (Business Email Compromise) attack
Anomaly rules — baseline + deviation detection
Sentinel builds behavioural baselines and alerts on deviations:
- Unusual volume of data downloaded by a user
- Login at an unusual time of day for this account
- Process execution pattern not seen before on this host
Pillar 3 — Investigate
Incidents
Every triggered analytics rule creates an alert. Sentinel groups related alerts into incidents — the unit of work for a SOC analyst:
Incident: Possible BEC attack — john.smith@contoso.com Severity: High Status: New Assigned: SOC Analyst 2 Alerts: ├── Impossible travel detected (Entra ID) ├── Mass forwarding rule created (Office 365) └── New privileged service principal (Azure Activity) Entities: ├── User: john.smith@contoso.com ├── IP: 185.220.101.45 (Tor exit node) └── Host: LAPTOP-JSmith MITRE ATT&CK: ├── T1078 — Valid accounts ├── T1114 — Email collection └── T1098 — Account manipulation
Investigation graph
A visual relationship map automatically built from incident entities — shows how a user, IP, host, and mailbox are connected without manual correlation:
185.220.101.45 (Tor IP) ↓ signed in asjohn.smith@contoso.com (user) ↓ createdForward-all-mail rule (Office 365) ↓ same session createdsp-finance-automation (service principal) ↓ grantedOwner role on subscription
Entity pages
Every entity (user, IP, host, app) gets a timeline page showing all activity across all data sources — 90 days of context assembled automatically:
User: john.smith@contoso.com Last 90 days: ├── Sign-ins: 847 (normal pattern: Mon-Fri 8am-6pm EST) ├── Anomalous sign-ins: 3 (Tor, Russia, Ukraine) ├── Files accessed: 12,847 ├── Emails sent: 2,341 ├── Azure resource operations: 156 └── Risk score: 94/100 (UEBA)
Pillar 4 — Respond (SOAR)
Playbooks are Azure Logic Apps triggered automatically when an incident is created or updated. They automate the first-response actions that would otherwise require a human:
Playbook 1 — Block compromised user automatically
Trigger: Sentinel incident created Condition: Severity == High AND Entity type == UserActions: 1. Get user details from Entra ID 2. Disable user account in Entra ID 3. Revoke all active sessions (MFA re-auth required) 4. Send Teams message to SOC channel: "User john.smith auto-disabled — incident #1234" 5. Create ServiceNow ticket with incident details 6. Add comment to Sentinel incident: "User account disabled at 14:32 UTC by playbook"
Playbook 2 — Isolate compromised VM
Trigger: Sentinel incident created Condition: Severity == High AND Entity type == HostActions: 1. Get VM resource ID from entity 2. Apply isolation NSG (deny all inbound + outbound except Bastion) az network nsg rule create --name ISOLATE --priority 100 --access Deny --direction Inbound --source-address-prefix * 3. Take VM disk snapshot (forensic preservation) 4. Tag VM: {"Status": "Isolated", "IncidentId": "1234"} 5. Notify SOC team via email + Teams 6. Create Jira ticket for IR team
Playbook 3 — Enrich IP with threat intelligence
Trigger: Sentinel alert contains IP entityActions: 1. Query VirusTotal API for IP reputation 2. Query Shodan for open ports and services 3. Query AbuseIPDB for abuse reports 4. Add enrichment comment to incident: "IP 185.220.101.45: VirusTotal: 47/92 vendors flagged malicious AbuseIPDB: 847 reports, 100% confidence malicious Shodan: Tor exit node — AS16276 OVH" 5. If malicious score > 80: → Add IP to Azure Firewall deny list automatically
KQL — The Query Language of Sentinel
Everything in Sentinel is queried with KQL (Kusto Query Language):
// Find all failed logins followed by success from same IP// (credential stuffing pattern)let failed_logins = SigninLogs | where TimeGenerated > ago(1h) | where ResultType != 0 // failed | summarize FailCount = count() by IPAddress, UserPrincipalName | where FailCount > 10;let successful_logins = SigninLogs | where TimeGenerated > ago(1h) | where ResultType == 0 // success | project IPAddress, UserPrincipalName, SuccessTime = TimeGenerated;successful_logins| join kind=inner failed_logins on IPAddress| project IPAddress, UserPrincipalName, FailCount, SuccessTime| order by FailCount desc
// Detect Azure privilege escalation — new owner role assignmentAzureActivity| where TimeGenerated > ago(1d)| where OperationNameValue == "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE"| where ActivityStatusValue == "Success"| extend RoleDefinitionId = tostring( parse_json(Properties).requestbody.properties.roleDefinitionId)| where RoleDefinitionId contains "8e3af657-a8ff-443c-a75c-2fe8c4bcb635" // Owner| project TimeGenerated, Caller, ResourceGroup, SubscriptionId, RoleDefinitionId
// Hunt for lateral movement via PsExec or WMISecurityEvent| where TimeGenerated > ago(7d)| where EventID in (4688, 4624) // process create + logon| where ProcessName has_any ("psexec", "wmic", "winrm") or CommandLine has_any ("\\\\", "invoke-wmimethod", "wmiexec")| summarize count() by Computer, Account, ProcessName, CommandLine| order by count_ desc
MITRE ATT&CK Integration
Sentinel maps every analytics rule to MITRE ATT&CK tactics and techniques — giving you a visual coverage matrix:
| Tactic | Example Technique | Sentinel Detection |
|---|---|---|
| Initial Access | T1078 Valid Accounts | Impossible travel rule |
| Persistence | T1098 Account Manipulation | New owner role assignment |
| Privilege Escalation | T1134 Token Impersonation | Service principal abuse |
| Defence Evasion | T1562 Impair Defences | Diagnostic setting deleted |
| Credential Access | T1110 Brute Force | Failed login threshold |
| Lateral Movement | T1021 Remote Services | PsExec / WMI detection |
| Exfiltration | T1048 Exfil over Alt Protocol | Large blob download |
| Impact | T1486 Data Encrypted | Ransomware file extension |
Sentinel in Hub and Spoke Context
In an enterprise hub and spoke topology, Sentinel sits at the subscription/tenant level — above the network, collecting from everything:
Microsoft Sentinel (Log Analytics Workspace) ↑ │ data connectors ┌────┴──────────────────────────────────┐ │ │Hub VNet Spoke VNets Azure Firewall logs AKS/ARO audit logs VPN Gateway logs VM security events Bastion session logs NSG flow logs DNS resolver logs App Gateway WAF logs │On-premises (via MMA/AMA agent) Windows Security Events Linux Syslog Network device CEF
Sentinel vs Defender for Cloud
| Microsoft Sentinel | Defender for Cloud | |
|---|---|---|
| Type | SIEM + SOAR | CSPM + CWPP |
| Focus | Threat detection + response | Posture management + workload protection |
| Scope | Cross-tenant, multi-cloud | Azure resources + connected clouds |
| Data | All log sources | Azure resource configuration + telemetry |
| Output | Incidents + playbooks | Recommendations + alerts |
| Use together | Defender feeds alerts into Sentinel | Sentinel adds SOAR response to Defender alerts |
They are designed to work together — Defender for Cloud detects threats at the resource level and feeds high-fidelity alerts into Sentinel, which correlates them with signals from every other source and automates the response.
Pricing Model
Sentinel pricing has two components:
Log Analytics ingestion — pay per GB ingested:
- Pay-as-you-go: ~$2.76/GB
- Commitment tiers: 100 GB/day → 500 GB/day → lower per-GB rate
Sentinel capacity reservation — flat daily rate above the free Log Analytics tier:
- First 10 GB/day per workspace: free
- Above 10 GB/day: ~$100–$400/day depending on tier
Free data sources — no ingestion charge for:
- Microsoft Defender alerts
- Entra ID audit + sign-in logs (Basic SKU)
- Azure Activity logs
- Office 365 management activity
Key Takeaway
Microsoft Sentinel is the security brain of your Azure estate — it ingests logs from every corner of your infrastructure (Azure, Microsoft 365, on-premises, third-party), correlates signals using AI and KQL-based rules, groups related alerts into actionable incidents mapped to MITRE ATT&CK, and automates first-response actions through Logic App playbooks. In a hub and spoke network, it sits above the topology collecting from every layer — firewall, gateway, Bastion, ARO, VMs, and on-premises — giving your SOC a single pane of glass across the entire estate.
