Sentinel Incident Response
Sentinel is where every signal converges. Learn how to investigate incidents in Sentinel, use entity pages, manage incident workflows, and connect Sentinel response to the wider Defender XDR ecosystem.
Sentinel as the central nervous system
Defender XDR watches Microsoft products. Sentinel watches everything.
Firewall logs, Linux servers, custom applications, third-party SaaS apps, cloud infrastructure β all of this feeds into Sentinel. When an analytics rule fires, Sentinel creates an incident that may combine alerts from multiple data sources into a single investigation.
As a SOC analyst working in Sentinel, you use the incident page to see all related alerts, entities, evidence, and timelines in one place. You use entity pages to deep-dive into specific users, devices, or IP addresses. And you use the investigation graph to trace relationships between entities.
The Sentinel incident page
When you open a Sentinel incident, you see:
| Tab | What It Shows |
|---|---|
| Overview | Incident summary β severity, status, owner, timestamps, classification |
| Alerts | All alerts grouped into this incident, with severity and detection source |
| Entities | Users, devices, IPs, URLs, file hashes involved in the incident |
| Evidence | Raw log data, email messages, files, processes linked to the alerts |
| Comments | Analyst notes, investigation steps, decisions |
| Similar incidents | Past incidents with similar patterns for reference |
Entity pages
Clicking an entity (user, device, IP) opens its entity page β a deep-dive view with:
- Timeline β all activities involving this entity, chronologically
- Related alerts β other alerts and incidents involving the same entity
- UEBA insights β behavioural analytics showing whether the entityβs recent activity is anomalous
- Sentinel Graph connections β relationships to other entities
Scenario: Anika investigates a Sentinel incident
Anika at Sentinel Shield opens a High-severity incident: βSuspicious outbound connection to known C2 IP.β
Investigation using the incident page:
- Alerts tab: Two alerts β (1) Sentinel TI rule matched a C2 IP from the FS-ISAC feed, (2) Defender XDR custom detection for unusual PowerShell network activity
- Entities: One device (ACME-WEB-03), one user (j.smith@acmecorp.com), one IP (198.51.100.42)
- Entity page for ACME-WEB-03: Timeline shows a PowerShell process spawned by w3wp.exe (IIS worker), connected to the C2 IP, then downloaded a second-stage payload
- UEBA insight: j.smith has never run PowerShell on this server before β anomalous
Verdict: Web server compromised via web shell. The IIS process was hijacked to execute PowerShell and establish C2 communication.
Response: Isolate the server, collect investigation package, alert the client, and begin forensic analysis.
The investigation graph
The investigation graph visually maps relationships between entities in an incident. It shows how users, devices, IPs, and files connect β helping you trace the attack chain.
Starting from the incident, you can:
- Expand entities to see their related alerts and activities
- Follow connections β device β user β IP β file β other devices
- Identify the blast radius β how far the attack spread
- Find the entry point β trace backwards from the compromised entity to the initial access
Incident management workflow
| Action | When to Use |
|---|---|
| Assign | Route to the right analyst (Tier 1, Tier 2, or specialist) |
| Change severity | Escalate if investigation reveals broader impact |
| Add tags | Label for tracking: βVIPβ, βComplianceβ, βCampaign-2026-04β |
| Add comments | Document investigation steps, findings, decisions |
| Run playbook | Trigger automated enrichment, notification, or containment |
| Link to other incidents | Connect related incidents across time |
| Close and classify | True Positive, False Positive, or Benign True Positive with determination |
Sentinel + Defender XDR unified experience
Sentinel incidents now appear in the unified Defender XDR incident queue. This means:
- One queue for ALL incidents (Defender + Sentinel)
- Cross-domain investigation (endpoint + identity + email + Sentinel data)
- Unified entity pages combining Defender and Sentinel telemetry
- Automated investigation can span both platforms
Exam tip: unified vs separate incident queues
The exam may reference both the Sentinel incident queue and the Defender XDR unified queue. Key point: Sentinel incidents surface in BOTH places. You can investigate from either portal.
The unified experience in Defender XDR is the recommended approach for most investigations because it combines all signal sources. The Sentinel-specific queue is useful when you need Sentinel-only features like the investigation graph, UEBA, or entity timelines.
Anika investigates a Sentinel incident and discovers that the compromised server (ACME-WEB-03) has connections to 5 other internal servers. How can she quickly visualise the blast radius?
A Sentinel incident contains alerts from a Sentinel analytics rule AND a Defender XDR custom detection. Where is the best place to investigate this cross-domain incident?
π¬ Video coming soon
Next up: Sentinel incidents are managed. Now letβs see how Copilot for Security accelerates your investigations with AI.