Microsoft Sentinel: SIEM Setup in the Defender Portal

Microsoft Sentinel is Microsoft's cloud-native SIEM and SOAR platform, and as of 2026 you set it up and operate it inside the Microsoft Defender portal rather than the Azure portal. Setup follows five steps: plan your Log Analytics workspace, connect data sources, choose your data tiers, build analytics rules, and automate response.

If you are moving into cloud security, Sentinel is one of the highest-leverage tools you can learn. It sits at the center of Azure detection engineering, and the skills transfer directly to security operations roles across every cloud.

What Microsoft Sentinel actually does

Sentinel combines two jobs that used to require separate products:

• SIEM: it collects, stores, and queries security logs from cloud and on-premises sources, then runs detection logic against that data.
• SOAR: it orchestrates the response, creating incidents, enriching them, and triggering automated playbooks.

Underneath, Sentinel is built on Azure Monitor Log Analytics. You query it with Kusto Query Language (KQL), which is the single most important technical skill for working in Sentinel. Every scheduled detection you write, every hunting query you run, and every investigation you pivot through is KQL.

What changed in 2026: the Defender portal transition

This is the part that trips up anyone learning from older tutorials. Microsoft has consolidated Sentinel into the unified Microsoft Defender portal alongside Defender XDR. According to Microsoft Learn, starting in July 2026 Microsoft Sentinel is supported in the Defender portal only, and customers still working in the Azure portal are automatically redirected.

Practically, that means:

• Your workspace, tables, and KQL all still exist. The data layer did not change.
• The console you work in moved. Incidents, hunting, analytics rules, and workbooks now live in the Defender portal experience.
• Sentinel alerts and Defender XDR alerts correlate into unified incidents, which reduces the manual stitching analysts used to do.

If you are studying for a Microsoft security certification, learn the Defender portal navigation first. Screenshots in older courses will not match what you see.

Step 1: plan the Log Analytics workspace

Sentinel is enabled on a Log Analytics workspace, and this decision is hard to reverse cleanly. Before you click anything, decide:

• How many workspaces? A single workspace is simpler to query and cheaper to operate. Multiple workspaces make sense when data residency law, tenant boundaries, or strict data-access separation require it.
• Which region? Ingested data lands in the workspace region, which matters for sovereignty requirements.
• Who gets access? Sentinel uses Azure role-based access control. Analysts rarely need write access to rules, and almost nobody needs owner on the workspace.

This is the same least-privilege thinking that applies everywhere in cloud security. If you want to see how the principle generalizes, our guide on AWS IAM security best practices walks through the equivalent reasoning on the AWS side.

Step 2: connect your data sources

Sentinel is only as good as the telemetry you feed it. Data connectors do the ingestion, and they come in a few flavors:

• Service-to-service connectors for Microsoft sources such as Entra ID sign-in and audit logs, Defender XDR, Azure Activity, and Office 365.
• Agent-based collection for servers and virtual machines through the Azure Monitor Agent and data collection rules.
• Syslog and Common Event Format for firewalls, proxies, and network appliances.
• Codeless and API-based connectors for SaaS platforms and third-party security tools.

Start narrow and deliberate. A good first set is Entra ID sign-in logs, Azure Activity, and Defender XDR. Those three cover identity, control-plane changes, and endpoint signal, which is where most real detections begin. Adding every connector on day one inflates cost and buries you in noise.

Identity logs deserve special attention. Most cloud intrusions run through credentials rather than exploits, which is why identity telemetry produces the highest-value detections. Our Azure security fundamentals article covers how Entra ID, Defender for Cloud, and Sentinel fit together.

Step 3: choose your data tiers

Sentinel separates hot analytics data from long-term storage, and understanding the split is how you control cost.

Tier	Best for	Query method	Typical retention posture
Analytics tier	Data you run detections and real-time investigation against	KQL, full analytics rule support	Shorter, cost-driven window
Data lake tier	High-volume, low-signal data kept for hunting, audit, and compliance	KQL and Python-based advanced analytics	Long-term, up to 12 years

The Microsoft Sentinel data lake is onboarded from the Defender portal under System, then Settings, then Microsoft Sentinel, then Data lake. Per Microsoft's data lake documentation, once the data lake is enabled, data in the analytics tier is also available in the data lake tier from that point forward at no extra charge, and the lake is designed for cost-effective retention of large volumes of security data.

The practical rule: put data you write detections against in the analytics tier, and route high-volume forensic data you only need occasionally to the lake. Sentinel billing is driven largely by ingestion volume, so tier design is a security engineering decision with a direct budget consequence. Being able to defend that tradeoff in an interview separates candidates who have operated a SIEM from candidates who have only read about one.

Step 4: build detections with analytics rules

Analytics rules turn logs into incidents. Sentinel offers several rule types, and picking the right one matters.

Rule type	How it works	Use it when
Scheduled	KQL query runs on an interval against a defined lookback window	Most custom detections, the workhorse rule type
Near-real-time (NRT)	Query runs at one-minute intervals on a two-minute delay, versus the five-minute delay on scheduled rules	Speed matters more than query complexity
Fusion	Correlation engine using machine learning to link anomalous behaviors across attack stages into one incident from two or more alerts	Multistage attack detection you cannot easily express in KQL
ML Behavior Analytics	Microsoft machine learning models detecting anomalous SSH and RDP login behavior based on IP, geolocation, and user history	Credential abuse and lateral movement signals
Microsoft security rules	Promote alerts from connected Microsoft security products into Sentinel incidents	Bringing Defender signal into unified incident handling

Content packs in the Content hub give you hundreds of prebuilt rules. Enable them, then tune them. Untuned rules are the leading cause of alert fatigue in new Sentinel deployments.

Every scheduled rule you write should include:

1. Entity mapping, so Sentinel knows which account, host, or IP the alert concerns. Without it, investigation and correlation break down.
2. MITRE ATT&CK tactic and technique tagging, which also feeds Fusion correlation for emerging threats.
3. Alert grouping logic, so a hundred related events become one workable incident.
4. A documented false-positive expectation, so the next analyst knows what normal looks like.

To monitor whether your rules are actually running, query the built-in _SentinelHealth() and _SentinelAudit() functions rather than the underlying tables directly. Microsoft maintains those functions for backward compatibility when schemas change. A rule that silently stopped firing is worse than no rule at all, because it creates false confidence.

Step 5: automate the response

Automation rules and playbooks are where SOAR shows up. Automation rules handle incident triage logic such as assigning an owner, setting severity, adding tags, or closing known-benign patterns. Playbooks, built on Azure Logic Apps, take action: disabling an account, isolating a device, opening a ticket, or posting to a channel.

Start with enrichment and triage automation before you automate anything destructive. Auto-disabling accounts on a noisy detection is how automation loses organizational trust in week one. Build the human approval step in first, then remove it once the detection has proven itself.

Common mistakes to avoid

• Ingesting everything. Cost climbs and signal drops. Route low-value, high-volume data to the lake tier.
• Enabling every prebuilt rule without tuning. You will drown, and real incidents will be missed in the noise.
• Skipping entity mapping. Correlation and investigation depend on it.
• No rule health monitoring. Detections break quietly when connectors change or schemas shift.
• Learning only the old Azure portal flow. The Defender portal is the operating surface now.

How to build real Sentinel skills

Reading documentation will get you conversant. Only hands-on work gets you hired. A realistic practice path looks like this:

1. Stand up a workspace in a personal or trial tenant and enable Sentinel.
2. Connect Entra ID and Azure Activity logs.
3. Write three scheduled rules from scratch in KQL, with entity mapping and ATT&CK tagging.
4. Generate the activity yourself, confirm the detection fires, then tune out the false positives.
5. Build one automation rule and one enrichment playbook.
6. Document the whole thing as a detection engineering portfolio project.

That last step matters more than most people expect. Documented detection work is the single most persuasive artifact in a cloud security interview, which is why our cloud security resume and LinkedIn guide treats project documentation as a first-class deliverable.

At PrimeSec Academy, Sentinel work is built into the Azure security portion of our 20-week Cloud and AI Platform Security Engineer program, alongside AWS, Google Cloud, and AI platform security. You build detections in a live environment, document them, and defend the work in a capstone rather than watching someone else click through a console.

See exactly what you build and when in the full curriculum, or enroll now to start your cohort.

Frequently asked questions

Is Microsoft Sentinel still available in the Azure portal?

Microsoft has consolidated Sentinel into the Microsoft Defender portal. Starting in July 2026, Sentinel is supported in the Defender portal only, and customers still using the Azure portal are automatically redirected. Your workspace and data are unchanged, but the console you work in has moved.

Do I need to know KQL to use Microsoft Sentinel?

Yes. Kusto Query Language is the query language for Sentinel, and you need it for custom detection rules, threat hunting, and investigation. You can get started with prebuilt content without deep KQL knowledge, but you cannot do detection engineering without it.

What is the difference between the analytics tier and the data lake tier?

The analytics tier holds data you actively run detections and investigations against with full analytics rule support. The data lake tier provides long-term, cost-effective storage for large volumes of security data, with retention available for up to 12 years and support for Python-based advanced analytics.

How much does Microsoft Sentinel cost?

Sentinel billing is driven primarily by how much data you ingest and how you retain it, with commitment-tier and pay-as-you-go options. Because cost scales with volume, data connector selection and tier design are the main levers you control. Check Microsoft's current pricing page for figures, since they change.

Which Sentinel analytics rule type should I use?

Scheduled rules are the default choice for most custom detections. Use near-real-time rules when detection speed matters more than query complexity. Use Fusion and machine learning behavior analytics for multistage attacks and anomaly patterns that are difficult to express directly in KQL.

Is Microsoft Sentinel a good skill for a cloud security career?

Yes. Sentinel is widely deployed in enterprises running Microsoft 365 and Azure, and security operations and detection engineering roles frequently list it. The underlying skills of log pipeline design, detection writing, and incident automation also transfer to other SIEM platforms.