This chapter covers the Microsoft Defender XDR Security Graph and its role in incident investigation. The Security Graph is a core component that powers incident creation, automated correlation, and threat hunting across the Microsoft 365 Defender ecosystem. For the SC-200 exam, approximately 15-20% of questions in the 'Defender XDR' domain test your understanding of how the Security Graph ingests signals, correlates alerts, and enables investigations. Mastering this topic is essential for answering scenario-based questions about incident management, advanced hunting, and entity behavior analytics.
Jump to a section
Imagine a detective solving a complex crime. The detective has a physical case board where they pin evidence: photos, witness statements, phone records, and forensic reports. Each piece of evidence is a data point—an alert, a log, a signal. But alone, each is incomplete. The detective draws red strings between clues to show connections: the suspect's phone pinged near the victim's house, the same credit card was used at a store near the scene, and a witness saw a car matching the suspect's model. This web of connections is the Security Graph. Microsoft Defender XDR's Security Graph is like that case board but automated and real-time. It ingests signals from across the Microsoft 365 ecosystem—endpoint detections from Defender for Endpoint, email threats from Defender for Office 365, identity anomalies from Microsoft Entra ID Protection, and cloud app activities from Defender for Cloud Apps. It then normalizes these signals into a unified schema and builds an entity-relationship graph that links users, devices, IP addresses, applications, and alerts. When a new alert fires, the graph instantly checks: Has this user been seen on any other device? Has this IP been associated with phishing? Is this process known to be malicious elsewhere? The graph synthesizes these connections to produce an incident—the equivalent of the detective's final theory—with a full narrative of the attack chain. The analyst can then walk the graph, pivoting from one entity to another, exactly as the detective follows red strings from clue to clue. The Security Graph is not just a log aggregator; it is a relationship engine that surfaces hidden connections, reduces alert fatigue by correlating related alerts into one incident, and accelerates threat hunting through precomputed links.
What is the Security Graph?
The Security Graph is a distributed, real-time graph database that underpins Microsoft Defender XDR. It ingests security signals from across Microsoft 365 Defender products—Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, and Microsoft Entra ID Protection—and correlates them into a unified entity-relationship model. The graph stores entities (users, devices, IP addresses, applications, mailboxes, etc.) and relationships (logons, email sends, process executions, network connections, etc.). When an alert is generated, the graph uses precomputed relationships to determine if it is part of a larger attack campaign. If so, it merges the alert into an existing incident or creates a new incident with all related alerts grouped together. This correlation reduces alert noise and provides a single pane of glass for investigation.
How the Security Graph Works Internally
At a technical level, the Security Graph is built on Azure Cosmos DB and Azure Stream Analytics. Signals from each Defender product are sent to a common ingestion pipeline. Each signal is normalized into a common schema that defines entities and their attributes. For example, a Defender for Endpoint alert contains the affected device, the user logged on, the process that triggered the alert, and the file hash. The graph stores this as nodes: Device(deviceId), User(userId), Process(processId), File(fileHash). Relationships are stored as edges: Device.hasUser(User), Process.executedOn(Device), Process.createdFile(File).
The graph engine runs a set of correlation rules continuously. These rules are written in a proprietary rule language and are updated by Microsoft's threat intelligence team. When a new alert arrives, the engine queries the graph to find related entities. For instance, if a new alert involves a device that was previously associated with a user who received a phishing email, the graph will find that relationship and link the new alert to the earlier email alert. The correlation is based on entity identifiers (e.g., deviceId, userId, IP address) and time windows (typically 24 hours for incident correlation, but can be extended for advanced hunting).
Key Components, Values, Defaults, and Timers
Incident correlation window: By default, alerts are considered for correlation if they occur within 7 days of each other. This is configurable via Microsoft 365 Defender settings (up to 30 days).
Entity store retention: Entity data in the Security Graph is retained for 30 days for incident correlation and up to 180 days for advanced hunting (depending on license).
Alert enrichment: The graph enriches alerts with entity context—e.g., device risk score (0-100, with 100 being highest risk), user risk level (low, medium, high), and IP geolocation.
Incident creation: The graph creates an incident when it correlates two or more alerts from different sources (e.g., an email alert and an endpoint alert) or when a single alert has high severity and is associated with a known attack pattern.
Automated investigation: The Security Graph triggers automated investigation playbooks based on incident severity and entity risk. Default playbooks include isolation of devices, disabling user accounts, and blocking IPs.
Configuration and Verification Commands
While the Security Graph is primarily a backend service, analysts interact with it through the Microsoft 365 Defender portal. Key actions include:
Viewing incidents: https://security.microsoft.com/incidents
Advanced hunting: Use Kusto Query Language (KQL) in the Advanced Hunting section to query the graph directly. Example:
let timeRange = 7d;
DeviceEvents
| where Timestamp > ago(timeRange)
| where ActionType == "ProcessCreate"
| project Timestamp, DeviceName, FileName, InitiatingProcessFileNameUsing the IdentityInfo table to get user details: IdentityInfo | where AccountUpn == "user@contoso.com"
Checking incident correlation: In an incident, the "Alerts" tab shows all correlated alerts; the "Attack story" tab visualizes the graph relationships.
Interaction with Related Technologies
The Security Graph integrates deeply with: - Microsoft Sentinel: Incidents can be forwarded to Sentinel via the Microsoft 365 Defender connector. Sentinel can then run its own analytics and correlate with non-Microsoft data. - Microsoft Defender for Cloud: Alerts from cloud workloads (VMs, containers) are ingested into the Security Graph if the workload is onboarded to Defender for Cloud with the appropriate plan. - Microsoft Purview: Data loss prevention (DLP) alerts can be correlated with other signals, e.g., a user who triggered a DLP policy and also received a phishing email. - Microsoft Entra ID Protection: Identity risk events (e.g., impossible travel) are correlated with endpoint and email alerts to detect credential theft attacks.
Step-by-Step: How an Alert Becomes an Incident
Signal Ingestion: A Defender for Endpoint sensor detects a suspicious PowerShell execution on a device. It sends an alert to the Security Graph.
Normalization: The alert is parsed into entities: Device(deviceId), User(userId), Process(powershell.exe), File(script.ps1). Relationships: Device.hasUser(User), Process.executedOn(Device).
Graph Query: The graph engine queries for existing entities with these IDs. It finds that the same user recently received a phishing email (from Defender for Office 365) with a malicious attachment.
Correlation: The graph links the new alert to the existing email alert. It checks the time window (both within 7 days) and applies the correlation rule "Email attachment leads to process execution."
Incident Creation: A new incident is created (or an existing one is updated) containing both alerts. The incident severity is set to the highest alert severity (e.g., High).
Enrichment: The graph enriches the incident with entity risk scores. The device has a risk score of 80 (high), and the user has a risk level of medium. The incident now has a full attack story.
Automated Response: If configured, an automated investigation runs, isolating the device and disabling the user account.
Advanced Hunting and the Security Graph
The Security Graph can be queried directly via Advanced Hunting using KQL. The schema includes tables like:
- AlertInfo: Alert metadata.
- AlertEvidence: Entities associated with alerts (e.g., file hashes, IPs, process IDs).
- IdentityInfo: User and device identity data.
- EmailEvents: Email delivery events.
- DeviceEvents: Process creation, network connections, etc.
Example: Find all incidents where a user received a phishing email and later executed a malicious file:
let phishingEmails = EmailEvents
| where EmailDirection == "Inbound"
| where ThreatTypes contains "Phish"
| project RecipientObjectId, NetworkMessageId;
let maliciousProcesses = DeviceEvents
| where ActionType == "ProcessCreate"
| where FileName in~ ("powershell.exe", "cmd.exe")
| project DeviceName, AccountUpn, ProcessCommandLine;
phishingEmails
| join maliciousProcesses on $left.RecipientObjectId == $right.AccountUpn
| project RecipientObjectId, NetworkMessageId, DeviceName, ProcessCommandLinePerformance and Scale
The Security Graph is designed to handle billions of signals per day across millions of devices. It uses a distributed architecture with multiple regions. Latency from signal ingestion to incident creation is typically under 5 minutes. However, during peak loads, correlation may take up to 15 minutes. The graph's entity store is optimized for fast lookups by entity ID. Relationship queries are precomputed using materialized views to avoid deep traversals at query time.
Security Graph vs. Traditional SIEM
Unlike a traditional SIEM, which stores logs in a flat table and requires the analyst to manually correlate, the Security Graph precomputes relationships. This means that when an analyst opens an incident, all related alerts are already grouped. The graph also supports entity-centric investigation: clicking on a user shows all alerts involving that user across all products. This is a key differentiator that the SC-200 exam loves to test. The exam expects you to know that the Security Graph is what enables "cross-product correlation" and "automated incident creation."
Signal Ingestion from Sensors
Each Microsoft Defender product (Endpoint, Office 365, Identity, Cloud Apps, Entra ID Protection) has sensors that collect telemetry. For example, Defender for Endpoint sensors collect process creation, network connections, file creation, registry changes, and more. These sensors send raw events to the cloud service via HTTPS (port 443) using a JSON-based protocol. The ingestion pipeline validates the schema, deduplicates events, and enriches them with basic context (e.g., device OS, user SID). This step is critical because any data loss here means the graph will have incomplete relationships.
Normalization into Entity Schema
The raw telemetry is transformed into a unified schema that defines entities and relationships. For instance, a process creation event is broken into: a Device entity (deviceId), a User entity (userId), a Process entity (processId), and a File entity (fileHash). Relationships are stored as edges: Device.hasUser(User), Process.executedOn(Device), Process.createdFile(File). The normalization step maps field names from different products to a common ontology. For example, 'ComputerName' from Defender for Endpoint becomes 'DeviceName' in the graph.
Graph Query for Existing Entities
Once normalized, the graph engine queries its entity store to see if any of the entities already exist. It uses the entity IDs (e.g., deviceId, userId, IP address) as keys. If the device already exists, it retrieves its current risk score and any existing relationships. If the user exists, it fetches recent alerts involving that user. This query is optimized via hash indexes and typically completes in under 50 milliseconds. The graph also checks for any pending investigations or automated responses associated with those entities.
Correlation Rule Evaluation
The graph engine runs a set of correlation rules against the new alert and the existing graph. Rules are written in a proprietary language and are updated by Microsoft. Examples: 'If a user receives a phishing email and within 24 hours that user's device executes a malicious file, correlate.' Another: 'If a device contacts a known C2 IP and later a user on that device logs into a cloud app with an anomalous location, correlate.' Each rule has a time window (default 7 days for incident correlation). If a rule matches, the new alert is linked to existing alerts.
Incident Creation or Update
If the correlation rule matches, the graph either creates a new incident or updates an existing one. If the new alert is related to an existing incident (same attack campaign), it is added to that incident. Otherwise, a new incident is created. The incident severity is set to the highest severity among its alerts. The incident also gets a title and description generated from the attack story. The incident is then visible in the Microsoft 365 Defender portal under 'Incidents & alerts > Incidents'.
Enrichment and Automated Response
After incident creation, the graph enriches the incident with additional context. This includes device risk score (from Defender for Endpoint), user risk level (from Entra ID Protection), IP geolocation, and any known indicators of compromise (IOCs) from threat intelligence. If automated investigation and response (AIR) is enabled, the graph triggers playbooks based on incident severity and entity risk. For example, a high-severity incident on a device with risk score > 70 may trigger device isolation. The analyst can then review and approve or reject these actions.
Enterprise Scenario 1: Phishing to Credential Theft
A large enterprise with 50,000 users and 30,000 devices uses Microsoft 365 E5 licenses. A user receives a phishing email that bypasses Exchange Online Protection. The user clicks the link and enters credentials on a fake login page. The attacker then uses those credentials to log into the corporate VPN from a foreign IP. Defender for Office 365 detects the phishing email (but it was delivered to inbox due to policy). Defender for Endpoint on the user's device detects a suspicious process spawned from the browser. Defender for Identity detects the anomalous VPN logon from an unusual location. The Security Graph correlates these three alerts into a single incident because they all involve the same user and occur within 4 hours. The incident is automatically assigned a severity of High. The automated investigation playbook disables the user's account and resets their password. The SOC analyst reviews the incident, sees the full attack chain on the Attack story tab, and confirms the response. Without the graph, the SOC would have to manually correlate three separate alerts across three consoles, wasting precious time.
Enterprise Scenario 2: Ransomware Detection
A hospital network with 10,000 devices uses Defender for Endpoint and Defender for Cloud Apps. A user downloads a malicious macro-enabled document from a SharePoint site. The macro executes PowerShell to download ransomware. Defender for Endpoint alerts on the PowerShell execution and the file encryption activity. Defender for Cloud Apps alerts on the anomalous download from SharePoint. The Security Graph correlates these alerts because they involve the same user and device. The incident shows that the device is now encrypting files. The automated response isolates the device from the network (blocking SMB and RDP) and blocks the file hash across all endpoints. The incident is escalated to the SOC. The graph also checks if the same user accessed other devices—if so, those devices are also investigated. This prevents lateral movement.
Common Misconfiguration Issues
One common issue is not enabling the Microsoft 365 Defender connector in Sentinel, which prevents incident forwarding. Another is misconfiguring the correlation time window—setting it too short (e.g., 1 day) can miss multi-stage attacks that span a weekend. Performance-wise, the graph handles load well, but if a tenant has extremely high alert volume (e.g., >100,000 alerts/day), correlation may take longer. The recommended best practice is to tune alert generation rules to reduce noise before they reach the graph. Also, ensure that all required licenses are assigned: the Security Graph requires a Microsoft 365 E5 or E5 Security license per user. Without it, some products (like Defender for Identity) may not feed signals into the graph.
What SC-200 Tests on This Topic
Exam objective 1.1: 'Analyze threat intelligence and manage incidents in Microsoft 365 Defender.' Specifically, you must understand how the Security Graph correlates alerts into incidents. The exam expects you to know:
That the Security Graph is a graph database that stores entities and relationships.
That it ingests signals from Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, and Microsoft Entra ID Protection.
That it uses correlation rules to merge alerts into incidents.
That incidents are enriched with entity risk scores.
That you can query the graph via Advanced Hunting using KQL.
Most Common Wrong Answers
'The Security Graph is a SIEM.' Wrong. It is a correlation engine and graph database, not a full SIEM. A SIEM (like Sentinel) ingests logs and provides analytics; the Security Graph focuses on real-time correlation and incident creation.
'Incidents are created for every alert.' Wrong. Incidents are created only when correlation rules match, or for high-severity alerts that are part of a known attack pattern. Many alerts are stored as individual alerts unless correlated.
'The Security Graph stores all logs for 90 days.' Wrong. The entity store retains data for 30 days for incident correlation and up to 180 days for advanced hunting. Raw logs are stored in the product-specific backends (e.g., Defender for Endpoint advanced hunting tables) for 30 days (or 180 days with additional licensing).
'Correlation is based on IP addresses only.' Wrong. Correlation uses multiple entity types: user, device, file hash, IP, mailbox, and more. It is not limited to IP.
Specific Numbers and Terms on the Exam
Default correlation time window: 7 days (configurable up to 30 days).
Entity store retention: 30 days for incident correlation.
Products that feed the graph: Exactly five—Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, Microsoft Entra ID Protection.
The term 'Attack story' appears in the exam as the visualization of the graph relationships in an incident.
'Advanced Hunting' is the KQL-based query interface to the graph.
Edge Cases and Exceptions
If a user is not licensed for a product (e.g., no Defender for Identity license), signals from that product for that user are not ingested. The graph will have incomplete relationships.
The graph does not correlate alerts from non-Microsoft sources unless they are forwarded via the Microsoft 365 Defender API or the Sentinel connector.
Alerts from Defender for Cloud are only ingested if the cloud workload is onboarded to Defender for Cloud with the appropriate plan (e.g., Defender for Servers).
How to Eliminate Wrong Answers
When you see a question about incident creation, ask: 'Did the scenario describe multiple alerts from different products involving the same entities within a time window?' If yes, the answer likely involves the Security Graph correlating them. If the question asks about querying the graph, the answer is 'Advanced Hunting' (not 'Hunting' or 'Threat Analytics'). If the question asks about enrichment, look for 'risk score' or 'entity context'. Eliminate answers that mention 'SIEM' or 'log storage' as primary functions of the graph.
The Security Graph correlates alerts from five Microsoft 365 Defender products into incidents using entity relationships.
Default correlation time window is 7 days; configurable up to 30 days.
Entity store retention is 30 days for incident correlation; advanced hunting tables retain data for 30 days (180 days with add-on).
The Security Graph is not a SIEM; Microsoft Sentinel is the SIEM.
Incidents are created only when correlation rules match or for high-severity alerts with known attack patterns.
Advanced Hunting with KQL is the primary way to query the Security Graph directly.
The Attack story tab in an incident visualizes the graph relationships.
These come up on the exam all the time. Here's how to tell them apart.
Security Graph (Defender XDR)
Graph database; stores entities and relationships.
Real-time correlation using precomputed rules.
Ingests only Microsoft 365 Defender product signals.
Incidents are created automatically by correlation.
Maximum entity store retention: 30 days.
Microsoft Sentinel (SIEM)
Log analytics workspace; stores raw logs.
Custom analytics using KQL queries and scheduled rules.
Ingests logs from any source (on-prem, cloud, third-party).
Incidents can be created from analytics rules or imported.
Log retention configurable from 30 days to 2 years.
Mistake
The Security Graph is a SIEM.
Correct
The Security Graph is a graph database and correlation engine, not a SIEM. It does not store raw logs long-term or provide custom analytics. Microsoft Sentinel is the SIEM. The Security Graph focuses on real-time correlation and incident creation across Microsoft 365 Defender products.
Mistake
All alerts automatically become incidents.
Correct
Only alerts that are correlated with other alerts via correlation rules, or high-severity alerts matching known attack patterns, become incidents. Many low-severity or isolated alerts remain as individual alerts in the Alerts queue.
Mistake
The Security Graph only correlates alerts from the same product.
Correct
The primary value of the Security Graph is cross-product correlation. It correlates alerts from Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, and Microsoft Entra ID Protection.
Mistake
Correlation is based solely on IP addresses.
Correct
Correlation uses multiple entity types: user, device, file hash, IP, mailbox, process, and more. IP is just one possible entity. The graph uses whatever entities are present in the alerts.
Mistake
The Security Graph stores data for 90 days.
Correct
Entity store retention is 30 days for incident correlation. Advanced hunting tables retain data for 30 days (or 180 days with additional licensing). The 90-day figure is not accurate for the Security Graph.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The Security Graph is a graph database that ingests security signals from Microsoft 365 Defender products (Endpoint, Office 365, Identity, Cloud Apps, Entra ID Protection), normalizes them into entities and relationships, and uses correlation rules to group related alerts into incidents. It enables cross-product correlation and entity-centric investigation. For the SC-200 exam, know that it is the backbone of incident creation and that you can query it via Advanced Hunting.
The Security Graph uses precomputed correlation rules that examine entities (user, device, IP, file hash, etc.) across alerts. When a new alert arrives, the graph queries its entity store for related entities within a configurable time window (default 7 days). If a rule matches, the alerts are merged into a single incident. For example, a phishing email and a subsequent process execution on the same user's device within 24 hours would be correlated.
An alert is a single security signal from one product (e.g., 'Malware detected on device X'). An incident is a collection of related alerts that together tell the story of an attack. The Security Graph creates incidents by correlating alerts that share common entities (user, device, IP) within a time window. Incidents provide a unified view of the attack chain, reducing alert fatigue.
No, the correlation rules are built and maintained by Microsoft. You cannot create or modify them. However, you can configure the correlation time window (up to 30 days) and set up automated investigation and response playbooks. For custom correlation, you would use Microsoft Sentinel with analytics rules.
Typically under 5 minutes from signal ingestion to incident creation. During peak loads, it may take up to 15 minutes. This latency is due to the time needed for normalization, graph query, correlation rule evaluation, and enrichment. The SC-200 exam may ask about this latency as a performance consideration.
Key tables include AlertInfo (alert metadata), AlertEvidence (entities linked to alerts), IdentityInfo (user and device details), EmailEvents (email delivery), DeviceEvents (process creation, network connections), and DeviceFileEvents (file operations). Use join operations to correlate across tables. For example, join AlertEvidence with DeviceEvents to see processes associated with an alert.
Not directly. The Security Graph only ingests signals from Microsoft 365 Defender products. However, you can forward incidents from Defender XDR to Sentinel via the Microsoft 365 Defender connector. Sentinel can then correlate those incidents with other data sources. The graph itself does not ingest Sentinel alerts.
You've just covered Defender XDR Security Graph and Investigations — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?