1.3.2. Microsoft Sentinel
💡 First Principle: Attacks don't respect vendor boundaries. The firewall, the Linux web server, the AWS account, and the HR system all hold pieces of the story. A SIEM's job is to bring those pieces into one queryable store, keep them as long as investigations and compliance require, and let you write detections and automation for your environment specifically. Microsoft Sentinel does this as a cloud-native service, so there are no servers to size or patch.
Sentinel is built on Azure Monitor's Log Analytics workspace, where ingested data lands in tables you query with KQL. Around that store sit the SIEM and SOAR capabilities you'll configure in Phase 2:
- Data connectors, packaged in Content hub solutions, bring in Microsoft, third-party, and custom data. Many use the Azure Monitor Agent with data collection rules; others are service-to-service or API-based.
- Analytics rules turn KQL queries into alerts and incidents on a schedule or in near real time.
- Automation rules and playbooks triage incidents and orchestrate responses, with playbooks built on Azure Logic Apps.
- Workbooks visualize data for dashboards and reporting.
- Hunting and notebooks support proactive investigation.
The current syllabus calls Sentinel a "SIEM and platform," and that second word matters. Sentinel now includes a data lake tier for low-cost, long-term storage, KQL jobs and summary rules for working with that data efficiently, the Sentinel graph for entity relationships, and an MCP server that exposes security data and tools to AI agents. These platform features are new enough that older study materials skip them; this guide covers them in Phases 2 and 4.
⚠️ Exam Trap: Storage choices are capability choices. Tables in the analytics tier support real-time analytics rules and hunting; tables in the data lake tier are cheap and long-lived but do not support real-time analytics rules. If a scenario needs a detection on a data source, that source must land in the analytics tier.
Reflection Question: Your organization's VPN appliance and on-premises Linux servers hold logs that matter to an investigation, but no Defender product sees them. Which half of the platform must ingest them, and what does that make possible that Defender XDR alone cannot?
