Microsoft Sentinel Deployment Guide: Workspace Design, Data Connectors, and Detection Rules
Microsoft Sentinel's growth from a niche Azure-native SIEM to a market-leading enterprise platform happened faster than most analysts predicted. The drivers are straightforward: Microsoft 365 E5 licensing includes significant free ingestion, the Microsoft 365 Defender connector provides native integration with the endpoint, identity, email, and cloud app security products that many enterprises already run, and the consumption-based pricing model scales better than per-GB-per-day licensed competitors at high volumes.
But Sentinel's ease of initial deployment conceals significant complexity in getting it right. A default deployment with all data connectors enabled and no ingestion filtering will ingest enormous volumes of low-value log data at non-trivial cost. The analytics rule library requires curation: the full content hub contains thousands of rules, many of which produce excessive false positives without tuning. This guide covers every major decision point in a Sentinel deployment.
Workspace Design Decisions
Microsoft Sentinel is deployed on top of an Azure Log Analytics workspace. The workspace design decision, specifically whether to use a single workspace or multiple workspaces, affects cost, performance, data sovereignty, and cross-workspace query capability. Making the right architecture decision at the start is far easier than migrating workspaces later.
Single workspace architecture: The default and recommended architecture for most organizations. All data from all regions, business units, and data sources flows into a single Log Analytics workspace with a single Sentinel deployment. Benefits: simplified management (one rule set, one playbook library, one cost center), better cross-data-source correlation (KQL queries can join across all tables without cross-workspace syntax), and lower operational overhead. Limitations: data sovereignty requirements that prohibit certain data from leaving a jurisdiction may force a regional workspace split, and very high-value environments where strict data access segregation between SOC teams is required may need workspace separation.
Multi-workspace architecture:
Multiple Log Analytics workspaces, each with its own Sentinel deployment, connected via Sentinel's workspace manager (in preview as of early 2026) or cross-workspace KQL queries using the workspace() function. Use cases: organizations with GDPR or data residency requirements (EU data must stay in the EU, so a separate EU workspace is required), large MSPs managing multiple customer Sentinel instances (each customer gets their own workspace), and organizations with strict SOC-level data access controls between business units.
Retention and cost tiering: Log Analytics workspaces support two data tiers: Analytics Logs (hot tier, fully queryable, $2.30-2.76/GB ingestion, 90-day interactive retention included) and Basic Logs (cheaper ingestion at $0.50/GB, 8-day interactive retention, limited KQL operators, requires an explicit query to retrieve older data). For high-volume, low-value tables (raw verbose firewall logs, Windows Security Event logs for non-critical event IDs), configuring tables to use the Basic Logs tier reduces ingestion cost by 70-80% while retaining the data for compliance.
Archive tier (cold storage) extends retention at $0.02/GB/month for data beyond the hot retention period, accessible via asynchronous search jobs rather than real-time KQL queries. For organizations with 1-year or 7-year compliance retention requirements, the archive tier makes long retention economically viable.
Commitment Tiers: Sentinel and Log Analytics both support Commitment Tier pricing: committing to a minimum daily ingestion volume in exchange for a per-GB discount of 30-65% compared to Pay-As-You-Go. The 100 GB/day Commitment Tier is the first threshold (commonly the right entry point for enterprises with over 5,000 users). Sentinel's Commitment Tier pricing mirrors the Log Analytics tier structure. Calculate expected ingestion volume from all data connectors before purchasing a Commitment Tier; use the Azure Cost Management + Billing workspace insights to project costs based on current ingestion rates.
Data Connector Priority Order and Configuration
Microsoft Sentinel's content hub contains over 200 data connectors, but ingestion priority matters enormously for both security coverage and cost management. The following priority ordering reflects security value and is designed to produce the highest coverage for the lowest incremental cost in a Microsoft-heavy environment.
Priority 1: Microsoft 365 Defender connector This single connector provides the most security coverage per integration effort of any Sentinel connector. It ingests:
- Microsoft Defender for Endpoint: DeviceEvents, DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceLogonEvents (rich endpoint telemetry)
- Microsoft Defender for Office 365: EmailEvents, EmailAttachmentInfo, EmailUrlInfo, AlertEvidence
- Microsoft Defender for Identity: IdentityDirectoryEvents, IdentityLogonEvents
- Microsoft Defender for Cloud Apps (MDCA): CloudAppEvents, alerts from MDCA policies
Configuration note: when enabling the Microsoft 365 Defender connector, choose whether to make Sentinel or the Defender portal the primary incident management interface. Bi-directional sync keeps incidents in sync across both portals, but analyst workflow should be consistent.
Priority 2: Azure Active Directory Enable SigninLogs (interactive user sign-ins), AADNonInteractiveUserSignInLogs (service principal and silent sign-ins), AuditLogs (directory changes: user creation, group membership, application consent), and AADServicePrincipalSignInLogs. Identity telemetry from Azure AD is the foundational data source for account compromise detection, impossible travel rules, and privilege escalation detection.
Priority 3: Azure Activity Azure Activity logs capture all control-plane operations in your Azure subscription: resource creation and deletion, role assignments, policy changes, and diagnostic setting modifications. This data is essential for detecting unauthorized Azure resource provisioning (cryptomining, data exfiltration infrastructure) and privilege escalation in the Azure RBAC model. Azure Activity is very low volume (typically under 1 GB/day for most organizations) and nearly always worth enabling.
Priority 4: Microsoft Defender for Cloud Defender for Cloud security alerts cover Azure resource security misconfigurations, network threat detection (Azure DDoS, suspicious network traffic), and container/Kubernetes threats. This connector is low volume (alerts only, not raw telemetry) and provides broad Azure posture visibility.
Priority 5: Office 365 The OfficeActivity table captures Exchange Online (email delivery, forwarding rules, mailbox access), SharePoint Online (file operations, sharing, external access), and Teams (message events, external invitations). Exchange forwarding rule creation (used in business email compromise) and SharePoint mass download events (data exfiltration) are high-priority detection scenarios from this source.
Priority 6: Primary EDR and network security tools After the Microsoft ecosystem is connected, prioritize your primary endpoint security product (CrowdStrike, SentinelOne, Trend Micro) and primary network security tool (next-generation firewall, proxy/SWG). These are typically the highest-volume non-Microsoft sources and require ingestion volume planning to manage cost.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Analytics Rules: Types, Deployment, and Tuning
Sentinel's analytics rules are the detection engine. Without deployed and tuned rules, the SIEM is a log archive with no alerting capability. The content hub provides a large library, but deploying it without selection and tuning creates alert fatigue.
Rule type selection:
Enable Microsoft Security rules first for all connected Microsoft Defender products. These rules automatically import high-fidelity Microsoft-generated alerts without any KQL authoring. A new Sentinel deployment connected to Microsoft 365 Defender can have hundreds of meaningful alerts within 24 hours of enabling Microsoft Security rules, with no custom development.
For Scheduled and NRT rules, deploy from the content hub solutions rather than individual rules. Solutions (for example, the Microsoft Entra ID solution, the Microsoft 365 Defender solution, the Windows Security Events solution) bundle related data connectors, analytics rules, workbooks, and playbooks into coherent packages. Deploying a solution activates a curated set of rules appropriate for that data source.
Tuning newly deployed rules:
Every newly deployed rule should be monitored for false positive rate for its first 7-14 days in production before being used to drive analyst triage workload. Use the following process:
- Deploy rules at Informational severity with incident creation disabled. Rules run and generate alerts visible in the Alerts blade but do not create analyst-facing incidents.
- Review the alert output daily for 7 days. Identify recurring false positive patterns.
- Build exclusions using entity-based watchlists: create a Sentinel watchlist for legitimate scanner IPs, authorized admin accounts, and known-good automation service accounts. Reference the watchlist in the rule KQL:
| where AccountName !in (_GetWatchlist("ExclusionList") | project AccountName). - After 7 days with acceptable false positive rates, raise severity and enable incident creation.
Alert grouping for incident quality:
Configuring alert grouping correctly is critical for analyst triage efficiency. Without grouping, a brute force detection rule that fires 200 times against the same account from the same IP creates 200 separate incidents. Configure alert grouping to group alerts from the same rule into a single incident when they share the same Account entity, IP entity, or both within a 5-hour window. The grouping configuration is in the analytics rule's "Incident Settings" tab.
Automation Playbooks with Logic Apps
Sentinel's SOAR capability is built on Azure Logic Apps. Playbooks are Logic Apps that are triggered by Sentinel alerts or incidents and execute automated response actions. The automation capability ranges from simple notification to full autonomous response, depending on the playbook's design and the pre-authorizations granted.
Common playbook patterns:
Alert enrichment: When a new Sentinel alert fires, automatically query external enrichment sources (VirusTotal for IP/domain/file hash reputation, Shodan for IP information, Azure AD for account risk score) and post the enrichment results as a comment on the Sentinel incident. This reduces analyst lookup time and provides immediate context without requiring analyst action. Trigger: Sentinel incident created. Actions: HTTP request to enrichment API, update Sentinel incident with comment.
Automated entity blocking: When a high-confidence alert fires (specific detection rules that indicate compromise with low false positive rates), automatically add the source IP to a network security group deny rule, disable the Azure AD account, or add the file hash to the EDR block list. This requires pre-authorization and must be limited to specific rules where automated blocking is appropriate. Trigger: specific analytics rule alert. Actions: Azure AD Graph API to revoke user sessions and block sign-in, Azure NSG API to add deny rule.
Analyst notification and triage routing: Post new incidents to a Microsoft Teams channel with entity context, severity, and a direct link to the Sentinel incident. Route incidents to different Teams channels or PagerDuty services based on severity or entity type. Trigger: Sentinel incident created. Actions: Teams connector send message, conditional branching by severity.
Managed connector authentication: Logic Apps playbooks authenticate to Azure services (Azure AD, Azure NSG, Azure Storage) via managed identity, which is the recommended authentication method as it eliminates credential management. For external services (VirusTotal, Shodan, Jira, ServiceNow), Logic Apps uses HTTP connector with API key authentication or OAuth 2.0 depending on the service.
Playbook deployment from the content hub: The Sentinel content hub includes pre-built playbooks for common scenarios. The SOC-Common-Playbooks solution contains foundational playbooks for incident notification, entity enrichment, and analyst routing that most organizations should deploy as the automation baseline. Review the Logic Apps designer to understand each playbook's logic before deploying, and adjust connector authentication and notification targets for your environment.
MITRE ATT&CK Coverage Mapping and Gap Identification
The MITRE ATT&CK framework provides a structured language for describing attacker techniques and the security controls that detect them. Sentinel's built-in MITRE ATT&CK coverage map (accessible from Threat Management in the Sentinel portal) shows which techniques are covered by your active analytics rules.
Reading the coverage map:
The coverage map displays ATT&CK tactics (columns) and techniques (rows in each column). Each technique shows color-coded coverage based on whether active Sentinel rules cover it, and which rule type (Simulated, Active, Fusion, Machine Learning). A technique with no color has no active detection coverage. The map can be filtered to show only the techniques relevant to your environment and threat model.
Prioritizing coverage gaps:
Not all coverage gaps are equal priority. Prioritize gap-filling based on three factors:
-
Threat relevance: which techniques are commonly used by threat actors targeting your industry? Cross-reference with CISA advisories and your threat intelligence feeds. Focus first on techniques used by actors that actively target organizations like yours.
-
Data availability: some technique detections require data sources you do not have. Lateral movement detection via SMB authentication (EventID 4648, 4624 Type 3) requires Windows Security Event logs from every endpoint. If you only have cloud identity logs, lateral movement detection is structurally limited.
-
Business risk: techniques that enable data exfiltration, ransomware deployment, or persistent administrative access are higher priority than low-impact techniques regardless of your threat model.
Coverage gap remediation options:
For techniques with coverage gaps, options in priority order:
- Deploy content hub rules for the specific technique if available (search the content hub for the ATT&CK technique ID, e.g., T1078)
- Deploy community rules from the Sentinel GitHub repository (Azure/Azure-Sentinel/Detections)
- Write custom KQL rules targeting the specific technique in your environment
- Accept the gap with documented rationale if the data source required is not available or the technique is not relevant to your threat model
Tracking coverage over time:
Export the coverage map state monthly (via the Sentinel API or the coverage map export feature) and compare month-over-month to verify that coverage is improving as new rules are deployed. Set a quarterly goal for expanding coverage into the highest-priority gap areas. A detection engineering program without a coverage tracking mechanism is flying blind.
Workbook Deployment for SOC Dashboards
Sentinel workbooks (built on Azure Monitor Workbooks) are interactive dashboards that visualize data from Log Analytics tables. They provide SOC management dashboards, investigation starting points, and compliance reporting views that are not available from the standard Sentinel incident and alert views.
High-priority workbooks to deploy from the content hub:
Sentinel Overview workbook: Provides a high-level dashboard of incident counts by severity, analytics rule firing frequency, data connector health status, and workspace ingestion volume by table. This is the SOC manager's daily status view and the first workbook to deploy.
Microsoft Entra ID Workbook / Azure AD Sign-in and Audit workbook: Visualizes sign-in patterns, failed authentication rates, Conditional Access policy failures, and privileged role assignment changes. This workbook surfaces identity-related anomalies that may not yet have triggered alert rules.
Microsoft 365 Defender Workbook: Aggregates Defender alert counts, endpoint vulnerability scores, email threat summaries, and identity risk metrics from the M365 Defender connector tables. Useful for SOC tier-1 briefings.
Data Collection Health Monitor: Shows the ingestion rate, data latency, and last-event timestamp for every connected data source. The most operationally critical workbook for detecting data connector failures: a firewall connector that stopped sending data 4 hours ago means 4 hours of blind spot in network detection. Set a process to review this workbook daily.
Zero Trust Dashboard workbook: Maps your Sentinel environment's controls against the NIST Zero Trust maturity model dimensions. Useful for security posture reporting to leadership.
Custom workbook development:
For organization-specific dashboards, the Workbook designer supports full KQL query composition with charts, tables, and parameter-driven filtering. Common custom workbook requests: executive-facing incident summary with SLA compliance metrics, compliance reporting workbooks (PCI, HIPAA, SOC 2 control status), and threat-specific investigation workbooks that guide analysts through a structured investigation workflow for specific detection types (for example, a business email compromise investigation workbook that pre-populates relevant queries for the OfficeActivity, EmailEvents, and AuditLogs tables).
The bottom line
Microsoft Sentinel's value proposition is strongest for organizations already invested in Microsoft security products, where the Microsoft 365 Defender connector delivers dense telemetry coverage at zero incremental ingestion cost and the integrated analytics rule library provides rapid time-to-detection. The deployment decisions that matter most are workspace architecture (get multi-workspace right before you need to migrate), ingestion filtering via Basic Logs and DCR event filtering (cost control is operational survival), and analytics rule tuning cadence (deploy slowly, validate false positive rates, and build watchlist-based exclusions before your analysts lose trust in the alert stream). A well-deployed Sentinel instance takes 3-6 months of active engineering attention to reach production maturity; plan accordingly.
Frequently asked questions
How much does Microsoft Sentinel cost and how do I control costs?
Sentinel pricing has two components: Log Analytics ingestion costs ($2.30-2.76 per GB at Pay-As-You-Go, dropping significantly with Commitment Tiers at 100 GB/day, 200 GB/day, and higher) and Sentinel workspace costs (a surcharge on top of Log Analytics, approximately $2.46 per GB at PAYG). Commitment Tiers provide 30-65% savings at volume compared to PAYG pricing. The most effective cost controls are: enabling Basic Logs for high-volume, low-query-frequency tables (raw security events from verbose sources) at $0.50/GB versus $2.30/GB for Analytics Logs; using Data Collection Rules (DCR) to filter events before ingestion (for example, filtering Windows Security Event logs to only high-value Event IDs before they enter the workspace); configuring the Microsoft 365 Defender connector to use the Defender portal as the primary home rather than duplicating alerts in both platforms; and setting explicit retention periods for each table rather than using the workspace default.
What data connectors should I enable first in a new Sentinel deployment?
Enable connectors in this priority order based on security value and coverage density: Microsoft 365 Defender (covers all M365 Defender products including MDE, MDO, MDI, and MDCA in a single connector with bi-directional alert sync), Azure Active Directory (SigninLogs, AuditLogs, AADNonInteractiveUserSignInLogs for identity threat detection), Microsoft Defender for Cloud (alerts from Azure resource security posture monitoring), Azure Activity (subscription-level administrative operations), and Office 365 (OfficeActivity table for Exchange, SharePoint, and Teams activity). After the Microsoft ecosystem is connected, prioritize your primary endpoint EDR (CrowdStrike, SentinelOne via CEF or their native connectors), your firewall or network security appliance (Palo Alto, Fortinet, or Check Point via CEF/Syslog), and your identity provider if non-Microsoft (Okta via the Okta connector).
What is the difference between Sentinel analytics rules and Microsoft Security rules?
Microsoft Security rules are a special analytics rule type that automatically generate Sentinel alerts from alerts produced by connected Microsoft security products (Microsoft Defender for Endpoint, Microsoft Defender for Office 365, Microsoft Defender for Identity, Microsoft Defender for Cloud Apps). They require no KQL authoring; you simply configure which product's alerts to import and at what severity threshold. Scheduled rules are KQL-based rules you write or deploy from the content hub that run on a configurable interval against Sentinel's Log Analytics tables. NRT (Near-Real-Time) rules are a subset of scheduled rules with under 5-minute latency. ML Behavioral Analytics rules use Microsoft's machine learning models to detect anomalous behavior patterns (anomalous sign-in, unusual process execution) without requiring custom KQL. Fusion rules are Microsoft-managed multi-stage attack detection rules that cannot be authored by customers. For a new Sentinel deployment, enable Microsoft Security rules first (immediate coverage for all connected Microsoft products) before investing engineering time in scheduled KQL rule authoring.
How do I connect non-Microsoft tools to Sentinel?
Three integration patterns handle non-Microsoft data sources. First, use native connectors from the Sentinel content hub if one exists for your product: CrowdStrike Falcon, Okta, Palo Alto Networks, Cisco, and dozens of other vendors have official Sentinel connectors that handle authentication and data normalization automatically. Second, use the CEF (Common Event Format) over Syslog connector for security products that support CEF output: configure the source product to send CEF-formatted Syslog to a Linux log forwarder running the Azure Monitor Agent, which forwards to Sentinel. Third, use the custom data connector or the Logs Ingestion API (DCR-based ingestion) for data sources without native or CEF connectors, sending JSON-formatted log data directly to a Log Analytics workspace via REST API. The Azure Monitor Agent (AMA) has replaced the legacy Log Analytics Agent (MMA) as the preferred collection agent for all new deployments.
What is the Fusion detection engine and how does it work?
Fusion is Microsoft's machine learning-based correlation engine in Sentinel that detects multi-stage attacks by correlating signals across multiple data sources simultaneously. Where individual analytics rules look for a single anomaly in a single data source, Fusion looks for combinations of low-fidelity signals that together indicate a sophisticated attack sequence. For example, Fusion might correlate an anomalous Azure AD sign-in from an unfamiliar location, followed by an unusual Azure resource deployment, followed by a mass email forwarding rule change in Exchange Online, and surface a single high-confidence Fusion alert for "Possible Credential Compromise followed by Data Exfiltration." Fusion currently correlates across 40+ signal types and is updated regularly by Microsoft's security research team. It requires no configuration and generates alerts automatically when the correlation model fires. Fusion alerts cannot be tuned by customers, which is a limitation for environments with unusual legitimate behavior patterns.
How do I validate that my Sentinel deployment has adequate MITRE ATT&CK coverage?
Sentinel includes a built-in MITRE ATT&CK coverage map accessible from the Threat Management section of the Sentinel portal. The coverage map shows which ATT&CK techniques are covered by your currently enabled analytics rules, with color coding by rule type (simulated, active, etc.). To assess gaps: enable all available Microsoft Sentinel analytics rules from the content hub (solutions from the Content Hub), then view the coverage map to identify uncovered or lightly covered techniques in your priority tactic areas (Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, and Lateral Movement are typically the highest priority). Cross-reference gaps against your environment's attack surface: if you do not run Linux endpoints, Linux-specific technique gaps are lower priority. The Microsoft Sentinel GitHub repository contains community-contributed detection rules that can fill coverage gaps not addressed by content hub rules.
Should I use Microsoft Sentinel or a third-party SIEM if I am already Microsoft-heavy?
For organizations with Microsoft 365 E3 or E5 licensing and significant Azure usage, Sentinel offers two advantages that are difficult to replicate with a third-party SIEM: the Microsoft 365 Defender connector provides unified alert management and bi-directional sync with Defender products through a native integration that third-party SIEMs must replicate via API, and Microsoft 365 E5 customers receive 5 MB/user/day of free Sentinel ingestion, which covers most of the Microsoft 365 Defender telemetry at zero incremental cost. The weaker case for Sentinel is when the organization has significant non-Microsoft infrastructure: on-premises Windows estates with high event volumes, Linux servers, multi-cloud workloads, or a heavy investment in a competing SIEM with existing detection rules and analyst workflow. In those cases, the migration cost and detection content conversion effort may outweigh the licensing advantage. Organizations with both Splunk and Microsoft investments increasingly run both platforms: Sentinel for Microsoft telemetry at low cost and Splunk for everything else.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.