Microsoft Sentinel Lab — Building a Cloud SIEM From Scratch
- Shone Pious
- Dec 6
- 5 min read
In this blog:
Azure Security Study Series – SIEM, Analytics, UEBA, and Data Ingestion
In this lab, I built a full Microsoft Sentinel environment from the ground up, connected Azure Activity Logs, enabled analytics rules, added UEBA, configured custom alerts, and integrated Microsoft 365 data connectors. This is one of the most important labs in the series because Sentinel is at the centre of Microsoft’s SIEM + XDR ecosystem.
1️⃣ Creating the Sentinel Workspace
To start, I deployed a dedicated Sentinel workspace:
Azure Portal → Microsoft Sentinel → + Add
Microsoft Sentinel dashboard. Select subscription → Create a new Log Analytics workspace
Name: SentinelLab-WA
Region: Same as the rest of the lab resources
Review + Create
Add Microsoft Sentinel to the workspace
Sentinel is free itself — you only pay for log ingestion. For this lab, ingestion is minimal and stays well within the free tier.
We have to connect our workspace to a new Sentinel instance. Search for Sentinel → +Create → Add Microsoft Sentinel to a workspace, and just select the workspace we created, and tap create:
Here's our Sentinel workspace up and running:
2️⃣ Connecting Azure Activity Logs (Critical Step!)
This is the foundation of Sentinel. Azure Activity Logs are free and provide administrator-level actions across the subscription.
Step 1 — Install the Azure Activity Solution
Sentinel → Content Hub → search Azure Activity → Install.
Step 2 — Configure the Connector
Sentinel → Configuration → Data connectors → Azure Activity → Open connector page. Then launch the Azure Policy Assignment Wizard.
Assign the built-in policy: “Configure Azure Activity logs to stream to a Log Analytics Workspace”
Important ⚠️
I initially missed some parameters because “Only show parameters that need review” was ticked.
UNCHECK this so you can configure:
Effect → DeployIfNotExists
Enable Activity Log streaming → True
Log Analytics Workspace → SentinelLab-WA
After fixing that, the policy finally showed Compliant.
3️⃣ Fixing Diagnostic Settings
Activity logs weren’t flowing in at first:
To resolve this:
Azure Portal → Monitor → Settings → Diagnostic Settings → Select the Azure Activity resource → + Add diagnostic setting
Configure:
Logs: allLogs
Metrics: AllMetrics
Destination: Send to Log Analytics Workspace
After updating this, and regenerating activity in the environment, logs began to appear.
We are now compliant:
4️⃣ Creating Analytics Rules
Analytics rules are the engine that turns raw logs into alerts and incidents.
Enable Built-In Rule Templates
Sentinel → Configuration → Analytics → Rule templates
I enabled templates such as:
✔ Rare subscription-level operations
✔ Suspicious resource deployment
✔ Authentication-based detections
NEXT STEP: Enable 2–3 Rule Templates (Defender Portal Version)
For each:
Create rule
Leave schedule at default
Ensure Incident creation is ON
Save
5️⃣ Creating a Custom Detection Rule (Storage Account Access Keys)
This was one of the most realistic detections in the lab.
Rule Logic (KQL):
AzureActivity
| where OperationNameValue =~ "Microsoft.Storage/storageAccounts/listKeys/action"
| project TimeGenerated, Caller, CallerIpAddress, ResourceGroup, SubscriptionId, CorrelationIdCreating the Scheduled Rule
Sentinel → Analytics → Create → Scheduled query rule
General:
Name: Storage Account Access Keys Retrieved
Tactic: Credential Access
Severity: Medium
Schedule:
Run every 5 min
Lookup 5 min
Entity Mapping:
Account → Caller
IP → CallerIpAddress
New Analytics page:
Triggering the Alert
Storage account → Access keys →
Show keys
Regenerate Key1 or Key2
Within minutes, the incident appeared in Sentinel.
6️⃣ Enabling UEBA (User & Entity Behaviour Analytics)
UEBA enriches Sentinel with identity insights and anomaly detection.
Steps
Defender Portal → SIEM + XDR → Sentinel
Select workspace
Content Hub → Search UEBA → Install
This enables:
IdentityInfo table
Entity behaviour mapping
Anomaly-based analytics
7️⃣ Enabling Entra ID Diagnostic Logs
These logs include sign-ins, service principal activity, and audit changes.
Entra admin center → Monitoring & health → Diagnostic settings →Add diagnostic setting → Send to Log Analytics Workspace
Enable:
✔ SignInLogs
✔ AuditLogs
✔ ServicePrincipalSignInLogs
✔ NonInteractiveUserSignInLogs
🔍 Verify logs are flowing
After ~10 minutes, logs began showing in Monitor and eventually started appearing in Log Analytics too.
Go to Log Analytics workspace → Logs and run:
search*
| where TimeGenerated > ago(20h)I am getting logs, which means the ingestion is working.
Running:
SignInLogs
| Take 50Gives me my last sign-in information which was this morning.
Running:
StorageBlobLogs
| Where TimeGenerated > ago(20h)We can now see the operations that I ran in my workspace last night (I created a storage account, added a container and uploaded a blob file into it).
Examples include:
Blob uploads in my storage account
RBAC role assignments
Portal sign-ins
8️⃣ Connecting Microsoft 365 Logs (Exchange, SharePoint, Teams)
Sentinel → Content Hub → Install Microsoft 365 solution.
Then open the connectors:
Exchange Online
SharePoint Online
Teams
Note from my lab session
I did not have an active M365 tenant with Exchange enabled, so the connector couldn’t ingest live data — but the connection steps were completed and validated and would be as follows:
1. Add the Exchange Online Data Connector
Go to MS Sentinel Workspace → Data connectors → Exchange Online → Open connector page.
2. Review prerequisites
Ensure the account used has the necessary permissions (typically Global Admin or Security Reader) in Exchange Online.
Verify that audit logging is enabled for the tenant.
3. Connect the data source
Configure the connector to stream mailbox and admin activity logs into the Sentinel Workspace.
Logs can include user sign-ins, mail sends, mailbox access, and admin changes.
4. Validation
Normally, after connecting, you can run queries on ExchangeAdminAuitLogs and ExchangeMailboxAuditLogs tables in logs analytics to confirm data ingestion.
5. Troubleshooting note:
In this lab, no logs were generated because a live Exchange tenant was not available, but the connector was successfully configured and ready to receive events.
✔ Final Notes & Troubleshooting Summary
Throughout the lab I learned:
Activity Logs require BOTH policy assignment AND diagnostic settings.
Some logs appear first in Monitor before Log Analytics completes ingestion.
Regenerating access keys, uploading blobs, and RBAC changes are reliable ways to generate events.
Entra ID logs can take 5–10 minutes before ingestion stabilises.
Custom KQL rules are the best way to create reliable, testable detections.
Comments