Lab Setup: Azure Subscription and Sentinel Workspace

What Sentinel does and why you need it

Microsoft Sentinel is Microsoft's cloud-native SIEM (Security Information and Event Management) platform. It collects security telemetry from across your environment into a centralized Log Analytics workspace where you write KQL queries to investigate incidents, build analytics rules to detect threats, and create hunting queries to find attacks that evade your detection rules.

Understanding how Sentinel relates to Defender XDR clarifies what each component does and why you need both. Defender XDR is the detection and response platform. It processes telemetry from Microsoft products (Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, Entra ID Protection) in real time and generates alerts based on Microsoft's built-in detection models and machine learning. These pre-built detections fire without you writing any rules. When a suspicious inbox forwarding rule is created, Defender XDR generates the alert. When an impossible travel sign-in occurs, Defender XDR correlates it with the subsequent mailbox activity. These detections are good. They catch known attack patterns reliably.

Sentinel does something different. It ingests the same telemetry that Defender XDR processes, plus data from non-Microsoft sources, into a Log Analytics workspace. You write custom analytics rules that detect patterns specific to your organization. You run complex KQL queries that span multiple data sources. You build hunting hypotheses that look for threats Defender XDR's built-in models were not designed to catch. You retain data for months or years for compliance and historical analysis. Defender XDR gives you Microsoft's detections. Sentinel lets you build your own.

Since 2024, Microsoft unified the portals. Sentinel incidents appear in the Defender XDR incident queue at security.microsoft.com, and you investigate Sentinel alerts alongside Defender alerts in the same experience. But the underlying data architecture remains separate: Defender XDR has its own Advanced Hunting tables with 30-day retention, while Sentinel has its Log Analytics tables with configurable retention (90 days default, extendable to years). The custom analytics rules, automation playbooks, and workbooks you build all live in the Sentinel workspace.

The course depends on Sentinel from Module 6 onward. Module 6 teaches KQL against Sentinel tables. Module 7 teaches workspace architecture and cost optimization. Module 8 teaches data connectors and ingestion strategy. Module 10 teaches analytics rules and detection engineering. Every investigation in Modules 12-16 uses Sentinel for cross-product correlation queries spanning identity, email, endpoint, and cloud application telemetry.

Step 1: Create an Azure subscription

If you already have an Azure subscription linked to the same account as your M365 tenant, skip to Step 2. If not, create one.

Navigate to portal.azure.com and sign in with the same account you used for your M365 E5 tenant. Using the same account is critical. It links the Azure subscription to the same Entra ID tenant, which enables M365 data connectors to flow telemetry into Sentinel without cross-tenant configuration. If you use a different account, you create a separate Entra ID tenant, and the data connectors will not see your E5 tenant's telemetry.

If the Azure portal shows existing resources, check for an existing subscription by clicking Subscriptions in the left navigation. If you are prompted to create one, choose the Azure free account option. The free account provides $200 in credits for 30 days and includes 12 months of free services. The $200 credit is far more than sufficient for the course's Sentinel usage.

If the free account is not available because you have used one previously, create a pay-as-you-go subscription. You need a credit card for billing. The cost for a lab-sized Sentinel workspace after the Sentinel free trial ends is $0.20 to $0.90 per day. Module 7 covers cost optimization in detail.

Step 2: Create a Log Analytics workspace

In the Azure portal, search for "Log Analytics workspaces" and select Create. Four configuration values are needed.

Subscription — select the Azure subscription you just created. This determines which billing account pays for ingestion and retention. For a lab, your personal subscription is correct.

Resource group — select Create new and name it something recognizable like "rg-sentinel-lab." A resource group is a logical container for related Azure resources. All your Sentinel resources will live here: the workspace, any automation playbooks you create in later modules, and any associated Logic Apps for SOAR (Security Orchestration, Automation, and Response). Using a dedicated resource group makes cleanup easy. If you ever want to tear down the lab completely, deleting the resource group removes everything inside it in one operation. It also makes cost tracking straightforward: Azure Cost Management can filter by resource group, so you can see exactly what your Sentinel lab costs without it being mixed into other Azure spending.

Name — choose a unique workspace name. This appears in KQL queries, API calls, Azure RBAC assignments, and diagnostic log configurations, so make it short and descriptive. Something like "law-secops-lab" works well. The name must be globally unique across Azure. If your first choice is taken, append a number. Avoid spaces and special characters. You will type this name frequently when configuring data connectors and running queries from the Azure portal side, so make it something you can type quickly.

Region — select the same region as your M365 tenant. For UK learners, UK South. For US learners, East US or West US 2. Matching regions matters for two reasons. First, data connector ingestion is faster when the source tenant and the workspace are in the same region. Second, cross-region data transfer adds a small but unnecessary cost to every GB ingested. In production, region selection has compliance implications (data residency regulations dictate where log data can be stored). For a lab, the performance and cost considerations are sufficient.

Select Review + Create, then Create. Deployment takes 30-60 seconds. You now have a Log Analytics workspace. This is the data store where all your security telemetry will be collected. Sentinel is not enabled yet. The workspace provides the storage and query engine. Sentinel adds the security intelligence layer: analytics rules, threat hunting, workbooks, data connectors, automation playbooks, and the SOC experience.

Step 3: Enable Microsoft Sentinel

In the Azure portal, search for "Microsoft Sentinel" and select Create. Select the workspace you just created and select Add. Deployment takes one to two minutes.

When deployment completes, you are automatically enrolled in the 31-day free trial. The trial provides up to 10 GB per day of data ingestion and analysis at no cost. For a lab tenant, this is more than sufficient. Your M365 environment generates megabytes per day, not gigabytes. The 31 days count from the moment you enable Sentinel, whether you are actively using the workspace or not. If you are not starting the course immediately after setup, be aware that trial days are counting even while the workspace sits idle.

After the trial, Sentinel switches to pay-as-you-go pricing. The simplified pricing model (default for workspaces created after July 2023) combines Log Analytics ingestion and Sentinel analysis into a single per-GB charge of approximately $4.30. For a lab tenant ingesting 100 MB per day, that is roughly $0.43 per day or $13 per month. Production environments with multiple data connectors and committed ingestion tiers cost significantly more, but your lab stays minimal.

Set up a budget alert immediately. In the Azure portal, search for "Cost Management," select Budgets, and create a monthly budget of $15 with an alert at 80% ($12). This gives you a warning if ingestion exceeds expectations. For initial setup, connect nothing. Section 0.6 covers which connectors to enable first and why. The most common cost surprise with Sentinel labs is enabling too many data connectors at once without understanding the ingestion volume each generates.

Troubleshooting common issues

Permissions error when enabling Sentinel. You need Contributor on the Azure subscription and Microsoft Sentinel Contributor on the resource group. If you created the subscription yourself, you have Owner permissions and no action is needed. If you are using an employer-managed subscription, request the appropriate role assignments from your Azure administrator.

Workspace not appearing in the Sentinel setup list. This happens when the workspace was created in a different subscription or a different Entra ID tenant. Verify you are signed into the Azure portal with the same account you used to create the workspace. Check the subscription filter at the top of the portal.

Step 4: Verify workspace configuration

Navigate to Microsoft Sentinel, select your workspace, and click Overview. The dashboard should load with zero incidents, zero analytics rules, and zero data connectors. This is expected.

Select Logs. The Log Analytics query editor should load with available tables in the left panel. You will not see security-specific tables like SigninLogs or SecurityAlert yet. Those appear after you connect data sources. You should see system tables like Heartbeat and Usage. Run a test query: type Usage | take 10 and select Run. If you see results, the workspace is functional. If you see a permissions error, verify your account has Microsoft Sentinel Contributor or Reader on the resource group.

Check data retention. Navigate to your Log Analytics workspace (the underlying workspace, not Sentinel), select Usage and estimated costs, then Data Retention. The default is 90 days. For a lab, 90 days is sufficient. Module 7 covers retention architecture for production environments.

What you have now

You have a complete lab environment: an M365 E5 tenant with security features enabled, an Azure subscription with billing configured, a Log Analytics workspace, and Microsoft Sentinel providing analytics, detection, and hunting capabilities. The environment is empty. No data flowing, no rules configured, no connectors enabled.

The unified portal experience means you access Sentinel through the Defender XDR portal at security.microsoft.com for daily investigation work. The Azure portal at portal.azure.com is where you manage workspace settings, retention, pricing, and infrastructure. Both portals access the same underlying workspace and data. You will use security.microsoft.com far more frequently than portal.azure.com once the workspace is configured.

Every module from Module 1 onward builds this environment incrementally. Module 8 connects data sources. Module 10 deploys detection rules. Module 11 creates hunting queries. By Module 16, your workspace will contain detection rules you wrote, investigation queries you refined, and hunting hypotheses you tested. The progression is intentional: you do not connect all data sources on day one because you need to understand what each connector provides before you can evaluate its cost-to-value ratio. You do not deploy detection rules until you understand the telemetry those rules query. Each configuration decision in the course is taught as a decision, not a step in a checklist.