Microsoft Sentinel is Azure’s cloud-native SIEM and SOAR solution. The marketing says it uses AI and machine learning to detect threats at scale. In reality, it’s a powerful platform that requires significant tuning to be useful. Out of the box, you’ll drown in false positives and miss real threats if you don’t configure it properly.
I’ve deployed Sentinel for multiple organizations. The difference between a useful security operations center and an expensive log aggregator comes down to how you configure connectors, tune analytics rules, build hunting queries, and automate responses. Here’s what actually matters.
Architecture and Data Ingestion
Sentinel sits on top of Log Analytics. Everything flows into Log Analytics tables, and Sentinel queries those tables using KQL (Kusto Query Language). Understanding this architecture is critical because it affects costs, performance, and what you can detect.
The basic flow:
Data Sources → Data Connectors → Log Analytics Workspace → Sentinel Analytics → Incidents → AutomationYour Log Analytics workspace design matters. Single workspace versus multiple workspaces is a common debate. Single workspace is simpler to manage and query across. Multiple workspaces give you data residency control and can reduce costs if you have large volumes of low-value logs.
For most organizations, start with a single workspace in your management subscription. Scale to multiple workspaces only when you have specific requirements for data residency or need to isolate environments completely.
Data Connectors That Matter
Sentinel has hundreds of data connectors. You don’t need all of them. Focus on the sources that provide high-value security telemetry.
Azure Active Directory: Essential. Captures sign-ins, audit logs, risky users, identity protection events. This is your identity security foundation.
// Enable AAD connector and configure these logsSigninLogsAuditLogsAADRiskyUsersAADUserRiskEventsAADRiskyServicePrincipalsIngest all of these. Identity is the perimeter in cloud environments. You need complete visibility into authentication events.
Azure Activity: Every control plane operation in Azure. Who created what, when, from where. Critical for detecting privilege escalation and unauthorized changes.
AzureActivity| where OperationNameValue contains "write" or OperationNameValue contains "delete"| where ActivityStatusValue == "Success"| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, ResourceId| order by TimeGenerated descOffice 365: If you’re using Microsoft 365, ingest Exchange, SharePoint, and Teams logs. Email compromise and data exfiltration often show up here first.
Azure Firewall: Network traffic logs. Destination IPs, ports, protocols. Helps identify command and control traffic, lateral movement, data exfiltration.
Windows Security Events: For Azure VMs and on-premises servers. Security Event ID 4624 (successful logon), 4625 (failed logon), 4672 (admin logon) are essential for detecting compromised credentials and lateral movement.
SecurityEvent| where EventID in (4624, 4625, 4672, 4768, 4769)| where TimeGenerated > ago(24h)| summarize count() by Account, EventID, Computer| where count_ > 10Linux Syslog: SSH authentication attempts, sudo usage, system events. Critical if you’re running Linux workloads.
Third-party firewalls, proxies, EDR solutions: If you have Palo Alto, Zscaler, CrowdStrike, or other security tools, ingest their logs. Sentinel works best when it has comprehensive visibility.
The common mistake is enabling every available connector. This explodes your data ingestion costs without improving detection. Be selective. Choose connectors that provide actionable security telemetry.
Data Ingestion Costs
Sentinel pricing has two components: data ingestion into Log Analytics and Sentinel analysis on top of that data. As of 2026, it’s roughly $3 per GB for Log Analytics ingestion plus $2.50 per GB for Sentinel analysis. That’s $5.50 per GB total.
If you’re ingesting 100 GB per day, that’s $16,500 per month. Costs add up fast.
Optimize ingestion:
Use Log Analytics commitment tiers: If you’re consistently ingesting over 100 GB per day, commitment tiers reduce per-GB costs significantly.
Filter unnecessary data: Transform data at ingestion to drop fields you don’t need. Security logs are verbose. You often don’t need every field.
// Data Collection Rule transformation to drop verbose fieldsSecurityEvent| where EventID in (4624, 4625, 4672, 4768, 4769)| project TimeGenerated, Computer, Account, EventID, IpAddress, LogonType// Drop other fields to reduce ingestion volumeArchive cold data: Move older data to cheaper archive storage. Keep 90 days hot, archive the rest. You can still query archived data when needed, just slower and more expensive per query.
Basic logs: For high-volume, low-value logs like firewall connection logs, use Basic logs tables. Cheaper ingestion, but limited query capabilities. Good for compliance retention requirements.
Monitor your ingestion daily:
Usage| where TimeGenerated > ago(24h)| where IsBillable == true| summarize TotalGB = sum(Quantity) / 1000 by DataType| order by TotalGB descThis shows which data types are consuming the most ingestion. If something spikes unexpectedly, investigate before your bill explodes.
Analytics Rules: Detection That Doesn’t Suck
Analytics rules are how Sentinel detects threats. Sentinel includes hundreds of built-in rules based on Microsoft’s threat intelligence. Most need tuning to work in your environment without generating excessive false positives.
Rule types:
Scheduled: Run queries on a schedule (every 5 minutes, hourly, daily). Most common type.
Microsoft Security: Ingests alerts from other Microsoft security products (Defender for Endpoint, Defender for Cloud Apps, etc.).
Fusion: Machine learning correlation across multiple data sources. Works well but is a black box.
Anomaly: Behavioral analytics to detect unusual activity. High false positive rate initially, improves over time as it learns your environment.
Start with Microsoft’s built-in templates and customize them. Don’t try to write everything from scratch.
Example: Detecting failed sign-in attempts followed by successful sign-in (credential spray attack):
let FailedThreshold = 5;let TimeWindow = 10m;SigninLogs| where TimeGenerated > ago(1h)| where ResultType != "0" // Failed sign-in| summarize FailedAttempts = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, TimeWindow)| where FailedAttempts >= FailedThreshold| join kind=inner ( SigninLogs | where TimeGenerated > ago(1h) | where ResultType == "0" // Successful sign-in | project SuccessTime = TimeGenerated, UserPrincipalName, IPAddress) on UserPrincipalName, IPAddress| where SuccessTime > TimeGenerated| project UserPrincipalName, IPAddress, FailedAttempts, TimeGenerated, SuccessTime| extend AccountCustomEntity = UserPrincipalName, IPCustomEntity = IPAddressThis detects a pattern where someone tries multiple failed authentications, then succeeds. Classic password spray or credential stuffing attack. The query enriches results with entity mappings so Sentinel can build the incident graph automatically.
Tuning rules:
Adjust thresholds: Default thresholds often don’t match your environment. Five failed logins might be normal for your users, or it might indicate an attack. Baseline your environment first.
Add exclusions: Known good IPs, service accounts, scheduled jobs. Exclude these from detections to reduce noise.
Time windows: Shorter windows reduce false positives but might miss attacks that occur over longer periods. Balance detection speed against accuracy.
Entity mapping: Always map results to entities (users, IPs, hosts, files). This enables Sentinel’s investigation graph and UEBA features.
Rule management at scale requires automation:
# Deploy custom analytics rule$rule = @{ displayName = "Suspicious Failed Login Pattern" description = "Detects multiple failed logins followed by success" severity = "Medium" enabled = $true query = $kqlQuery queryFrequency = "PT5M" queryPeriod = "PT1H" triggerOperator = "GreaterThan" triggerThreshold = 0 tactics = @("CredentialAccess") techniques = @("T1110")}
New-AzSentinelAlertRule @rule -ResourceGroupName "rg-sentinel" -WorkspaceName "law-sentinel"Store rule definitions in Git. Deploy through pipelines. Treat detection rules like application code.
Threat Hunting with KQL
Analytics rules handle known bad patterns. Threat hunting finds the unknown threats. This requires understanding KQL and knowing what malicious activity looks like in logs.
Essential hunting queries:
Rare processes executed on servers:
SecurityEvent| where EventID == 4688 // Process creation| where TimeGenerated > ago(7d)| where Computer contains "server"| summarize ProcessCount = count() by NewProcessName, Computer| where ProcessCount < 3 // Rare processes| order by ProcessCount ascAttackers often run uncommon tools on servers during post-exploitation. This surfaces processes that rarely execute, which could indicate compromise.
Anomalous sign-in locations:
let UserBaselineLocations = SigninLogs| where TimeGenerated > ago(30d)| summarize Countries = make_set(LocationDetails.countryOrRegion) by UserPrincipalName;SigninLogs| where TimeGenerated > ago(1d)| where ResultType == "0"| join kind=leftanti UserBaselineLocations on UserPrincipalName| project TimeGenerated, UserPrincipalName, LocationDetails, IPAddress, AppDisplayNameDetects users signing in from countries they’ve never accessed before. Strong indicator of compromised credentials.
Privilege escalation attempts:
AzureActivity| where OperationNameValue contains "roleAssignments/write"| where ActivityStatusValue == "Success"| extend RoleAssigned = tostring(Properties.requestbody)| where RoleAssigned contains "Owner" or RoleAssigned contains "Contributor"| project TimeGenerated, Caller, ResourceGroup, RoleAssignedTracks who’s assigning privileged roles in Azure. Privilege escalation is a key phase of most attacks.
Data exfiltration to unusual destinations:
AzureDiagnostics| where Category == "AzureFirewallApplicationRule"| where TimeGenerated > ago(24h)| where DestinationIp !startswith "10." and DestinationIp !startswith "172." and DestinationIp !startswith "192.168."| summarize TotalBytes = sum(BytesSent) by SourceIp, DestinationIp, DestinationPort| where TotalBytes > 1000000000 // 1 GB| order by TotalBytes descLarge data transfers to external destinations. Potential data exfiltration. Tune the byte threshold based on your normal traffic patterns.
Lateral movement via RDP:
SecurityEvent| where EventID == 4624| where LogonType == 10 // RDP| where TimeGenerated > ago(24h)| summarize RDPSessions = count() by Account, Computer, IpAddress| where RDPSessions > 5| order by RDPSessions descAttackers move laterally through environments using RDP. Unusual patterns of RDP connections across multiple hosts suggest compromise.
Build a hunting query library. Document what each query detects and what legitimate scenarios might trigger it. Share queries with your team. Hunting is most effective when it’s collaborative.
Workbooks for Visibility
Workbooks are custom dashboards in Sentinel. They visualize security data and help spot trends that individual incidents miss.
Essential workbooks:
User and Entity Behavior Analytics (UEBA) overview: Shows anomalous user activity, risky users, unusual locations. Built-in template works well.
Azure Activity: Visualizes control plane operations. Who’s creating resources, deleting resource groups, modifying RBAC. Helps detect unauthorized changes.
Identity and Access: Sign-in patterns, failed authentication trends, conditional access policy hits. Critical for monitoring identity security.
Network Traffic: Firewall blocks, allowed connections, top talkers, geographic distribution. Network security visibility.
Custom workbook example for tracking administrative activity:
AzureActivity| where TimeGenerated > ago(7d)| where OperationNameValue contains "write" or OperationNameValue contains "delete"| summarize Operations = count() by Caller, bin(TimeGenerated, 1h)| render timechartVisualizes administrative activity over time. Spikes indicate unusual administrative actions that warrant investigation.
Workbooks are also useful for executive reporting. Security metrics, incident trends, mean time to detect, mean time to respond. Translates technical security data into business metrics.
Automation and SOAR
The “SOAR” part of SIEM/SOAR is automation. Sentinel’s automation comes from Azure Logic Apps and playbooks.
Common automation scenarios:
Isolate compromised host: When Sentinel detects malware on a VM, automatically isolate it from the network to prevent lateral movement.
Block malicious IP: Firewall detects outbound traffic to known C2 infrastructure, automatically add that IP to block list.
Disable compromised user: UEBA detects impossible travel, automatically disable the user account and revoke sessions.
Enrich incidents: When incident is created, automatically query threat intelligence feeds, add context to the incident.
Notify teams: Send alerts to Teams or Slack for high-severity incidents. Include incident details, affected entities, recommended actions.
Example playbook for blocking malicious IPs in Azure Firewall:
{ "definition": { "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#", "actions": { "Parse_Alert": { "type": "ParseJson", "inputs": { "content": "@triggerBody()?['object']?['properties']", "schema": {} } }, "Extract_IP": { "type": "InitializeVariable", "inputs": { "variables": [{ "name": "MaliciousIP", "type": "string", "value": "@body('Parse_Alert')?['additionalData']?['IPAddress']" }] } }, "Update_Firewall_Rule": { "type": "Http", "inputs": { "method": "PUT", "uri": "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{rgName}/providers/Microsoft.Network/azureFirewalls/{firewallName}/networkRuleCollections/{ruleCollectionName}?api-version=2023-05-01", "authentication": { "type": "ManagedServiceIdentity" }, "body": { "properties": { "action": { "type": "Deny" }, "rules": [{ "name": "Block-@{variables('MaliciousIP')}", "sourceAddresses": ["*"], "destinationAddresses": ["@{variables('MaliciousIP')}"], "destinationPorts": ["*"], "protocols": ["Any"] }] } } } } }, "triggers": { "Microsoft_Sentinel_incident": { "type": "ApiConnectionWebhook", "inputs": { "host": { "connection": { "name": "@parameters('$connections')['azuresentinel']['connectionId']" } } } } } }}This playbook triggers on Sentinel incidents, extracts the malicious IP from the incident, and adds a deny rule to Azure Firewall. Fully automated response in seconds.
Start with simple automations. Notification and enrichment playbooks first. Gradually add more complex response actions as you build confidence in your detections. Aggressive automated response with high false positive rates creates operational problems.
Incident Management
Incidents are the output of your analytics rules. An incident groups related alerts and provides context for investigation.
Incident lifecycle:
- New: Incident created by analytics rule
- Active: Analyst assigned, investigation in progress
- Closed: Investigation complete, incident resolved
Proper incident management requires process, not just technology:
Triage process: Define SLAs for incident triage based on severity. High severity incidents should be reviewed within 15 minutes. Medium within 4 hours. Low within 24 hours.
Assignment rules: Automatically assign incidents to the right team based on incident type. Azure-related incidents to cloud team, identity incidents to IAM team, etc.
Investigation playbooks: Document investigation steps for common incident types. What logs to check, what entities to examine, what questions to answer.
Escalation paths: Clear escalation for incidents that require additional expertise or executive notification.
Metrics tracking: Mean time to detect, mean time to respond, false positive rate, incident closure rate. Track these to measure SOC effectiveness.
Sentinel’s investigation graph is powerful for understanding incident scope:
SecurityIncident| where IncidentNumber == "12345"| join kind=inner ( SecurityAlert | where SystemAlertId in (toscalar( SecurityIncident | where IncidentNumber == "12345" | summarize make_list(SystemAlertId) ))) on SystemAlertId| project TimeGenerated, AlertName, Entities, ThreatDescriptionShows all alerts and entities related to an incident. Helps analysts understand the full attack chain, not just isolated alerts.
UEBA Configuration
User and Entity Behavior Analytics builds baseline behavior for users, devices, and other entities. Detects anomalies that deviate from established patterns.
UEBA requires time to learn your environment. Initial two weeks have high false positives as it establishes baselines. After that, it gets significantly better at detecting genuine anomalies.
Enable UEBA for:
Users: Anomalous sign-in patterns, unusual resource access, abnormal Azure activity Hosts: Unusual process execution, abnormal network connections IP addresses: Reputation scoring, connection pattern analysis
UEBA insights feed into your analytics rules and hunting queries:
BehaviorAnalytics| where TimeGenerated > ago(24h)| where InvestigationPriority > 5 // High priority anomalies| project TimeGenerated, UserPrincipalName, ActivityType, ActivityInsights, InvestigationPriority| order by InvestigationPriority descSurfaces high-priority behavioral anomalies. These are often genuine threats that pattern-based detections miss.
Threat Intelligence Integration
Sentinel integrates with threat intelligence feeds. Microsoft’s feeds are included. You can add third-party feeds (TAXII, custom feeds).
TI matching happens automatically. When logs contain IPs, domains, URLs, or file hashes that match threat intelligence indicators, Sentinel flags them.
Custom threat intelligence:
ThreatIntelligenceIndicator| where TimeGenerated > ago(30d)| where Active == true| where ConfidenceScore > 80| project IndicatorId, ThreatType, SourceSystem, NetworkSourceIP, NetworkDestinationIP, DomainNameQuery your threat intelligence to understand what indicators are loaded. Helps tune detections and understand coverage gaps.
Import custom indicators via API:
$indicators = @( @{ pattern = "[ipv4-addr:value = '192.0.2.1']" patternType = "ipv4-addr" threatTypes = @("malicious-activity") confidence = 90 description = "Known C2 server from incident 12345" })
foreach ($indicator in $indicators) { New-AzSentinelThreatIntelligenceIndicator -ResourceGroupName "rg-sentinel" -WorkspaceName "law-sentinel" -Indicator $indicator}Add IOCs from your investigations back into threat intelligence. Improves future detections.
Performance Optimization
Sentinel performance matters. Slow queries delay detections. Inefficient queries waste money.
Query optimization techniques:
Filter early: Apply time and data type filters first, before any processing.
// Bad - Processes all data then filtersSecurityEvent| summarize count() by EventID| where TimeGenerated > ago(24h)
// Good - Filters firstSecurityEvent| where TimeGenerated > ago(24h)| summarize count() by EventIDUse summarize instead of distinct: Summarize is more efficient for large datasets.
Limit result sets: Don’t return millions of rows. Use top, take, or sample operators.
Materialize expensive operations: If you reuse a subquery, materialize it.
let ExpensiveQuery = materialize( SecurityEvent | where TimeGenerated > ago(7d) | where EventID == 4624 | summarize LoginCount = count() by Account);ExpensiveQuery| where LoginCount > 100Use externaldata sparingly: Loading external data during query execution is slow. Ingest reference data into tables instead.
Monitor query performance:
LAQueryLogs| where TimeGenerated > ago(24h)| summarize AvgDuration = avg(DurationMs), MaxDuration = max(DurationMs) by QueryText| where AvgDuration > 10000 // Queries taking over 10 seconds| order by AvgDuration descIdentifies slow queries that need optimization.
Integration with Other Security Tools
Sentinel works best as part of a security ecosystem, not in isolation.
Microsoft Defender for Endpoint: Endpoint detection and response. Bidirectional integration with Sentinel. EDR alerts flow into Sentinel, Sentinel can trigger EDR actions.
Microsoft Defender for Cloud: Cloud security posture management. Sends security recommendations and alerts to Sentinel.
Microsoft Defender for Cloud Apps: Cloud access security broker. Shadow IT detection, data loss prevention, OAuth app risks all feed into Sentinel.
Third-party SIEM: Some organizations run hybrid deployments. Forward Sentinel incidents to Splunk or QRadar for centralized management.
Ticketing systems: ServiceNow, Jira integration for incident management. Create tickets automatically for medium/high severity incidents.
Communication platforms: Teams, Slack notifications for real-time alerting.
Integration architecture:
Sentinel Incidents → Logic App → ServiceNow API → Create Ticket → Teams Connector → Post to Channel → Custom API → Internal SOAR PlatformBuild integrations that match your operational workflows. Force-fitting workflows to tool capabilities creates friction and reduces effectiveness.
The Reality of Running Sentinel
Sentinel is powerful but requires continuous tuning. Your initial deployment will generate too many false positives. That’s normal. Plan for a 3-6 month tuning period.
Staffing matters. You need people who understand security, know KQL, and can develop automation. Plan for at least one dedicated resource, more if you’re running 24/7 SOC operations.
Costs scale with data volume. Monitor your ingestion constantly. Optimize aggressively. A poorly managed Sentinel deployment can cost $50k+ monthly.
The upside is comprehensive visibility and automated response capabilities that traditional SIEMs can’t match. Cloud-native architecture scales effortlessly. Integration with Azure and Microsoft 365 is seamless.
Start small. Get the fundamentals right. Tune your detections. Build automation gradually. Measure everything. Sentinel becomes more valuable over time as your detection library matures and automation improves.
Done right, Sentinel transforms security operations from reactive firefighting to proactive threat hunting. But it requires investment, expertise, and ongoing attention. There’s no autopilot mode.
Build it properly and you’ll have a security operations capability that actually detects threats before they become breaches.