3.1 Portal Layout and Incident Hierarchy
The Portal Layout
The Defender XDR portal at security.microsoft.com is organised around a left-hand navigation menu with major sections: Incidents & alerts, Hunting, Actions & submissions, Threat intelligence, Secure score, Learning hub, and the product-specific sections for Endpoints, Email & collaboration, Cloud apps, and Identity. You do not need to memorise the full navigation — you need to know where the four areas you will use daily are.
Figure 3.1: The four portal areas SOC analysts use most, in order of frequency.
The daily workflow
A typical SOC analyst shift follows this pattern: open the incident queue, triage new incidents by severity, investigate using the incident detail page (which links to evidence, alerts, and entities), pivot to advanced hunting for custom queries when the incident page does not answer your questions, take response actions from the action centre, and document your findings in the incident notes.
Before the unified portal, analysts checked Defender for Endpoint in one console, Defender for Office 365 in another, Entra ID in a third, and Cloud Apps in a fourth. The unified portal consolidates all of these. If you are switching between four different portals to investigate one incident, you are working harder than you need to.
The Incident-Alert-Evidence Hierarchy
Understanding this hierarchy is essential to efficient triage. It determines how you navigate from a high-level incident to the specific evidence you need.
Figure 3.1b: An incident contains alerts from different products. Each alert contains specific evidence. Navigate from incident → alert → evidence to reach the data you need.
Incident — the top-level container. Created by the correlation engine when related alerts are detected. An incident has a severity, status (active/resolved), assignment, and classification. It contains one or more alerts.
Alert — a detection from a specific product. Each alert has a source (which product generated it), a detection type (rule-based, anomaly, ML), and a severity. The alert page shows the timeline of events that triggered it.
Evidence — the specific entities involved. Depending on the alert type: email addresses, URLs, file hashes, user accounts, IP addresses, devices, or processes. Each piece of evidence can be clicked to pivot into its own investigation view.
Start at the incident level. Read the incident title and alerts to understand the scope. Then drill into specific alerts that need investigation. Then examine evidence within those alerts. Working bottom-up (starting with a single alert or entity) misses the broader context that the correlation provides.
Incident page walkthrough
When you open an incident, the page shows:
- Attack story — a visual timeline showing the sequence of alerts and how they connect
- Alerts tab — every alert in the incident with source, severity, and status
- Assets tab — affected users, devices, and mailboxes
- Evidence tab — specific entities (emails, files, IPs) with their verdicts
- Investigation tab — results of automated investigation (if AIR ran)
- Graph tab — visual relationship map between all entities in the incident
The attack story tab is usually the best starting point — it shows you the full chain of events without requiring you to piece it together from individual alerts.
Try it yourself
On the Attack story tab, look for the timeline flow — does it show a clear sequence of events? Can you follow the attack chain?
On the Alerts tab, check the source product column. Multiple products means the correlation engine found a cross-product connection.
On the Evidence tab, click any entity (user, IP, email) — it opens a flyout with context about that entity and links to further investigation.
Check your understanding
1. What is the relationship between incidents, alerts, and evidence?
2. An incident contains 3 alerts from 3 different products. What does this tell you?
3. Which incident page tab should you check first?