SC-500 Part 7: Defender XDR, Microsoft Purview, and Zero Trust Architecture

Part 7 of 8 — this domain spans multiple SC-500 skill areas including unified SecOps operations, data security, and architectural security strategy. Expect questions that mix Defender XDR workload knowledge with Purview policy configuration and Zero Trust control mapping.

Microsoft Defender XDR

Microsoft Defender XDR (Extended Detection and Response) is the unified SecOps platform that correlates signals from Microsoft's entire security product portfolio into a single incident queue. Rather than each product generating isolated alerts, XDR runs a cross-workload correlation engine that identifies when alerts from different sources belong to the same attack chain, deduplicates redundant signals, and assembles them into a single incident with a shared MITRE ATT&CK mapping.

The five primary signal sources are:

Defender for Endpoint (MDE) — device-level signals: process executions, file writes, network connections, registry changes, memory injections
Defender for Identity (MDI) — Active Directory DS signals: authentication events, Kerberos ticket operations, LDAP queries, domain controller activity
Defender for Office 365 (MDO) — email and collaboration signals: malicious attachments, phishing links, spoofed senders, compromised mailbox activity
Defender for Cloud Apps (MDCA) — SaaS application signals: impossible travel, mass download, OAuth abuse, shadow IT activity
Defender for Cloud — Azure resource signals: suspicious API calls, VM behavior anomalies, container escape attempts, misconfiguration exploits

Unified Incident Model

When Defender XDR receives alerts from its component workloads, the correlation engine applies several steps before surfacing an incident to analysts:

Entity extraction — each alert contributes entities: user accounts, device names, IP addresses, URLs, file hashes, mailboxes. These become the shared nodes in the incident graph.
Deduplication — alerts that reference the same entity within a configurable time window and attack chain are merged so analysts see one coherent story rather than dozens of overlapping alerts.
MITRE ATT&CK tagging — each alert maps to one or more ATT&CK tactics (Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, Impact). The incident header shows the full set of tactics observed across all contributing alerts.
Automated severity assignment — incident severity (Informational / Low / Medium / High) derives from the highest contributing alert severity, adjusted by the number of entities and tactics involved.
Automatic investigation trigger — for high-severity incidents on enrolled devices, the Automated Investigation and Response (AIR) engine fires immediately without analyst action.

Defender for Endpoint (MDE)

MDE provides endpoint detection and response (EDR) across Windows, macOS, Linux, iOS, and Android. Onboarding methods vary by platform and management tool:

Microsoft Intune / MEM — preferred for cloud-managed devices; a configuration profile deploys the onboarding package automatically
Group Policy — for domain-joined devices without Intune; the onboarding script is deployed as a GPO startup script
System Center Configuration Manager (SCCM/ConfigMgr) — for large on-premises estates; the package is deployed as a software deployment
Local script — for single-device onboarding or testing; run WindowsDefenderATPOnboardingScript.cmd as administrator
VDI onboarding script — for non-persistent virtual desktop infrastructure where the device identity changes each session
Azure Arc — for servers already onboarded to Azure Arc; Defender for Servers Plan 2 automatically extends MDE

EDR in block mode is a critical configuration option for environments where a non-Microsoft antivirus solution handles real-time protection. When enabled, MDE acts as a secondary defense layer that can block malicious artifacts detected post-breach even when it is not the primary AV. Without block mode, MDE in passive mode only detects and alerts — it does not block.

Attack Surface Reduction (ASR) rules are Defender for Endpoint policies that block specific high-risk behaviors at the kernel level, before code even executes. Key rules for exam purposes:

Block Office applications from creating child processes — prevents Word/Excel from spawning cmd.exe or PowerShell (spear-phishing macro defense)
Block credential stealing from the Windows local security authority subsystem — blocks LSASS memory access by tools like Mimikatz
Block process creations originating from PSExec and WMI commands — blocks common lateral movement execution methods
Block untrusted and unsigned processes that run from USB — removable media malware defense
Use advanced protection against ransomware — adds behavioral heuristics for ransomware-like encryption activity

ASR rules operate in three modes: Audit (log only), Warn (block with user notification), and Block. Exam scenarios typically ask when to use Audit mode first — the answer is always before enforcing Block in production to avoid disrupting legitimate processes.

Threat and Vulnerability Management (TVM) is the built-in risk-based vulnerability prioritization engine. It continuously scans enrolled devices for software vulnerabilities and misconfigurations and produces an Exposure Score (device-level) and a Microsoft Secure Score for Devices (org-level). TVM provides one-click remediation recommendations that open Intune or ConfigMgr deployment tasks directly.

Live Response is a remote shell capability inside MDE that allows an analyst to connect to an enrolled device while an incident is active. From Live Response an analyst can: run scripts, upload/download files, collect memory dumps, query running processes, and terminate malicious processes — all without physically accessing the device. Requires the Live Response advanced feature to be enabled in MDE settings, and the analyst must have the Live Response (advanced) permission.

Defender for Identity (MDI)

MDI monitors Active Directory Domain Services by deploying a lightweight sensor on each domain controller. The sensor reads Windows Security Event log events (4624, 4625, 4768, 4769, 4776, 4662, and others) and network traffic mirrored to the DC's NIC. It does not require a dedicated server — the sensor runs in-process on the DC itself.

Key lateral movement attack detections:

Pass-the-Hash (PtH) — attacker captures an NTLM hash from one machine and uses it to authenticate to another without knowing the plaintext password. MDI detects this by observing NTLM authentication events where the source account authenticates to a remote host immediately after a credential access indicator on the originating host.
Pass-the-Ticket (PtT) — attacker steals a Kerberos service ticket (TGT or TGS) from memory and uses it on a different machine. MDI correlates Kerberos ticket usage across DCs and flags tickets used from IP addresses that don't match the original requesting host.
Golden Ticket — attacker with domain admin access (or via KRBTGT hash theft) forges Kerberos TGTs with arbitrary lifetimes and group memberships. MDI detects Golden Tickets by observing tickets with unusual lifetimes, non-existent accounts, or tickets that bypass normal KDC validation paths.
Skeleton Key — malware patched into the DC's LSASS that accepts a universal password alongside legitimate passwords. MDI detects the LSASS modification.
DCSync — attacker with DS-Replication-Get-Changes-All permission requests AD replication from a DC to dump all credential hashes. MDI flags replication requests from non-DC machines.

The Suspicious Activities Timeline in MDI shows all security alerts for a specific user or device entity in chronological order, making it easy to trace an attacker's progression from initial compromise through lateral movement to domain dominance.

LAPS integration: MDI can read Local Administrator Password Solution (LAPS) managed passwords from AD, helping analysts obtain the current local admin credential for a compromised device during incident response — without requiring a separate LAPS management tool.

Defender for Cloud Apps (MDCA)

MDCA (formerly Microsoft Cloud App Security) provides visibility into and control over cloud application usage across your organization. Its capabilities span four primary areas:

Shadow IT Discovery uses traffic logs from firewalls, web proxies, and network devices (or a direct connection through Defender for Endpoint's network signal) to identify all cloud apps in use — not just sanctioned ones. Each discovered app receives a Cloud App Catalog risk score (1–10) based on factors like SOC 2 certification, data residency, GDPR compliance, and encryption practices. Admins can tag apps as Sanctioned or Unsanctioned; unsanctioned apps can be blocked automatically through integration with compatible firewall/proxy vendors.

Session control uses a reverse proxy architecture (Conditional Access App Control) to interpose MDCA between the user's browser and cloud apps. When a Conditional Access policy routes a session through MDCA, the platform can:

Monitor all user activity (file downloads, uploads, form submissions) within the session
Block specific activities (e.g., allow access to SharePoint Online but block download to unmanaged devices)
Apply real-time DLP policies (block upload of files containing credit card numbers)
Apply watermarks to downloaded documents
Require step-up authentication before risky actions

Session controls require the app to be configured as a Conditional Access App Control app in MDCA and the CA policy to select "Use Conditional Access App Control" as its session control.

API connectors provide deep integration with specific SaaS apps via their admin APIs (Office 365, Salesforce, Box, AWS, GitHub, etc.). Through API connectors, MDCA can pull activity logs, manage permissions, govern OAuth apps, and enforce policies — even outside of a live browser session.

Anomaly detection policies are machine learning-based behavioral policies that baseline normal user activity and alert on deviations. Key built-in policies:

Impossible travel — user authenticates from New York, then 20 minutes later from London. The travel time is physically impossible.
Mass download by a single user — user downloads an abnormally large number of files in a short period
Activity from anonymous IP address — activity originating from Tor exit nodes or known VPN anonymizers
Ransomware activity — mass file deletion, rename, or overwrite matching ransomware behavioral patterns

OAuth app governance allows admins to review and revoke third-party apps that users have granted permission to access organizational data. An app governance policy can automatically disable apps that request high-permission scopes (Mail.ReadWrite, Files.ReadWrite.All) from non-verified publishers, or apps that have not been used in 90 days.

Defender for Office 365 (MDO)

MDO adds threat protection layers on top of Exchange Online Protection (EOP). It comes in two plans: Plan 1 (Safe Links, Safe Attachments, anti-phishing) and Plan 2 (Plan 1 + Attack Simulator, Threat Explorer, automated investigation).

Safe Links rewrites URLs in email messages at delivery time. When a user clicks the link, Safe Links detonates the destination URL in real time in a sandboxed browser, checks it against the Microsoft URL reputation database, and either allows the navigation or blocks it with a warning page. Safe Links also applies to Teams messages and Office documents when the policy scope includes those workloads.

Safe Attachments routes email attachments through a sandboxed detonation environment before delivery. The attachment is opened in an isolated VM; behavior is monitored for 30 seconds to several minutes. If suspicious behavior is detected (process spawning, registry writes, network beaconing), the attachment is quarantined and a clean copy (or no attachment) is delivered. Dynamic Delivery mode delivers the email body immediately with a placeholder while the attachment is scanned, avoiding delivery delays for benign files.

Anti-phishing policies provide two layers of protection:

Impersonation protection — MDO learns which users (e.g., C-suite) and domains (your organization's registered domains) are high-value impersonation targets. When an incoming message uses a display name or domain that closely resembles a protected user or domain but comes from a different sending address, it is flagged or quarantined.
Spoof intelligence — EOP and MDO analyze DMARC, DKIM, and SPF records to determine whether the sending domain is authorized to send on behalf of the apparent From: address. The spoof intelligence insight shows all external senders spoofing internal domains, allowing admins to allow-list legitimate bulk mail services and block true spoofers.

Attack simulation training (Plan 2) allows security teams to send simulated phishing emails to real users to measure susceptibility. Simulations use real-world phishing techniques (credential harvest, link in attachment, drive-by URL). Users who click are automatically enrolled in targeted training modules. Simulation results feed into the organization's threat exposure reporting.

XDR Advanced Hunting

Advanced Hunting in Defender XDR is a KQL-based query interface that spans all workload telemetry in a unified schema. The key tables for cross-workload investigation:

Table	Workload	Key columns	Common use cases
`DeviceEvents`	MDE	DeviceName, ActionType, InitiatingProcessFileName, RemoteIP	Process execution, file creation, network connection events on endpoints
`DeviceProcessEvents`	MDE	ProcessCommandLine, InitiatingProcessParentFileName, AccountName	Detect malicious child processes, suspicious command lines, PowerShell abuse
`IdentityLogonEvents`	MDI	AccountUpn, LogonType, Protocol, IPAddress, FailureReason	Failed logon patterns, NTLM vs Kerberos, lateral movement via PtH/PtT
`IdentityDirectoryEvents`	MDI	ActionType, TargetAccountUpn, AdditionalFields	Account modifications, group membership changes, LDAP reconnaissance
`CloudAppEvents`	MDCA	AccountId, Application, ActivityType, IPAddress, CountryCode	SaaS activity, OAuth consent, mass file operations, impossible travel
`EmailEvents`	MDO	SenderMailFromAddress, RecipientEmailAddress, ThreatTypes, DeliveryAction	Phishing campaigns, malware delivery, BEC detection
`EmailAttachmentInfo`	MDO	FileName, SHA256, ThreatTypes, DetectionMethods	Hunt for specific malicious file hashes across all received mail
`AlertEvidence`	XDR (all)	AlertId, EntityType, EvidenceRole, RemoteIP, AccountName	Find all entities involved in a specific alert or incident

A cross-workload query example — find devices that received a phishing email and also had a suspicious process execution within 2 hours:

let PhishRecipients = EmailEvents
    | where ThreatTypes has "Phish"
    | where Timestamp > ago(7d)
    | project RecipientEmailAddress, Timestamp, NetworkMessageId;
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("powershell", "cmd", "wscript", "mshta")
| join kind=inner PhishRecipients on $left.AccountUpn == $right.RecipientEmailAddress
| where Timestamp between (Timestamp .. (Timestamp + 2h))
| project DeviceName, AccountUpn, ProcessCommandLine, Timestamp

Incident Investigation Graph

Each Defender XDR incident has an Attack Story tab that renders a visual graph of all entities and the relationships between them. Entity types include:

Device — hostname, OS, MDE enrollment status, current risk level
User — UPN, Azure AD risk level, MDI profile, role memberships
Mailbox — email address, forwarding rules, inbox rules, recent suspicious emails
IP address — geolocation, threat intelligence reputation, associated devices and accounts
URL — Safe Links verdict, detonation result, associated emails and clicks
File hash — SHA-256, prevalence across the organization, VirusTotal verdict, associated devices and processes
Cloud app — app name, risk score, associated user activities

Evidence collection in XDR allows analysts to mark specific entities as "evidence" for an incident, tag them with custom labels (e.g., "confirmed malicious", "needs review"), and export the entity list for ticketing systems or legal proceedings.

Automatic Investigation and Response (AIR)

AIR is the automation engine built into Defender XDR that runs when a high-severity alert fires on a device enrolled in MDE. The investigation lifecycle:

Trigger — a high-severity alert fires (e.g., malware detected, credential dumping behavior)
Entity collection — AIR automatically collects forensic artifacts from the affected device: process trees, network connections, registry keys, file system changes, memory artifacts
Analysis — the collected data is analyzed against threat intelligence and behavioral models to determine the scope of compromise
Pending actions — AIR generates remediation actions (quarantine file, isolate device, disable user account) and places them in a Pending actions queue
Approval — by default, pending actions require analyst approval. When the automation level is set to Full automation, AIR can approve and execute its own actions without human intervention
Remediation — approved actions execute on the device(s) and results are logged in the investigation timeline

The automation level is configured per device group in MDE settings. Production device groups typically use Semi — require approval for core folders remediation while less critical groups can use full automation.

Defender Workloads Comparison

Workload	What it monitors	Key detections	Deployment
Defender for Endpoint (MDE)	Windows, macOS, Linux, iOS, Android devices — process, file, network, registry telemetry	Malware execution, credential dumping, ransomware, fileless attacks, ASR rule violations, vulnerability exploitation	Intune, GPO, SCCM, local script, VDI script, Arc
Defender for Identity (MDI)	Active Directory DS — authentication events, Kerberos tickets, LDAP queries, DC replication traffic	Pass-the-Hash, Pass-the-Ticket, Golden Ticket, DCSync, Skeleton Key, LDAP recon, privilege escalation	Sensor on each DC (in-process); optionally on AD FS servers
Defender for Office 365 (MDO)	Exchange Online, SharePoint Online, Teams, OneDrive — email flow, attachments, links, sharing events	Phishing, malware attachments, BEC (business email compromise), spoofing, malicious URLs, account takeover via email	Enabled per Microsoft 365 subscription; policies configured in Defender portal
Defender for Cloud Apps (MDCA)	SaaS applications — OAuth, session activity, file operations, API activity, shadow IT traffic	Impossible travel, mass download, OAuth abuse, ransomware in cloud files, admin activity anomalies, shadow IT risk	App connectors (API), log upload for shadow IT, or MDE network signal for discovery
Defender for Cloud	Azure subscriptions, VMs, containers, databases, App Service, storage — ARM activity and resource behavior	Suspicious ARM API calls, crypto mining, container escape, exposed management ports, SQL injection attempts, storage enumeration	Enabled per subscription; Defender plans enabled per resource type (Servers, Containers, Databases, etc.)

Defender XDR Architecture

Defender XDR correlates signals from five workloads into a unified incident queue and advanced hunting workspace.

Microsoft Purview — Security Relevance

Microsoft Purview is the data governance and compliance platform that SC-500 candidates need to understand from a security perspective — specifically how it prevents data exfiltration, enforces classification-based access, and supports incident response through audit logs and eDiscovery.

Information Protection — Sensitivity Labels

Sensitivity labels are metadata tags applied to documents, emails, meetings, and containers (SharePoint sites, Teams, M365 Groups). They are the mechanism by which Purview Information Protection enforces data handling policies. A label can apply:

Encryption — using Azure Information Protection (AIP), the label applies an RMS template that restricts who can open, edit, copy, print, or forward the content. Encryption persists with the file regardless of where it is moved (email, USB, cloud storage).
Content marking — headers, footers, and watermarks embedded in the document body
Auto-labeling — based on sensitive information type (SIT) detection in the content, the label is applied automatically at client level (Word, Outlook) or service level (SharePoint, Exchange, Teams in transit)
Container protection — labels applied to M365 Groups and SharePoint sites enforce external sharing settings, unmanaged device access restrictions, and Teams privacy settings

Label application methods:

Manual — user selects the label from the sensitivity bar in Office apps or Outlook
Recommended — client displays a recommendation when content matches a condition; user can accept or dismiss
Automatic (client-side) — label is applied automatically in the Office app based on SIT detection in the document; user sees a notification
Automatic (service-side) — the Purview auto-labeling policy scans content at rest in SharePoint/OneDrive and in transit through Exchange, applying labels server-side without requiring the Office client
Mandatory labeling — label policy setting that requires users to apply a label before saving or sending; no default label is applied automatically

Label inheritance applies when a labeled document is embedded in another document or when email replies chain to a labeled message. The resulting item inherits the highest-sensitivity label present in the chain.

Sensitivity Label Scopes and Encryption Options

Label scope	Applies to	Encryption options	Notes
Files & Emails	Office docs, PDFs, email messages	None, Assign permissions now (fixed ACL), Let users assign permissions (Do Not Forward / Encrypt-Only)	Encryption persists outside M365
Meetings & Calendar items	Teams meetings, calendar invitations	End-to-end encryption for Teams Premium meetings	Requires Teams Premium license for E2EE
Groups & Sites	SharePoint sites, M365 Groups, Teams	No direct file encryption; controls sharing settings and unmanaged device access	Enforced at container level, not per-file
Schematized data assets	Azure SQL, Azure Synapse, SQL Server, data assets in Purview Data Map	Label applied as metadata; no content encryption at column level via label alone	Used for data estate classification

Data Loss Prevention (DLP)

DLP policies prevent the sharing or exfiltration of sensitive data by inspecting content and enforcing actions when policy conditions are met. A DLP policy has three structural components:

Locations — where the policy applies: Exchange Online (email), SharePoint Online (files), OneDrive for Business, Teams chat and channel messages, Endpoint devices (MDE-enrolled), Microsoft 365 Defender (for MDCA-managed apps), On-premises repositories (via Purview scanner)
Conditions — what triggers the rule: content contains a specific SIT with a minimum confidence level and instance count, content is shared externally vs. internally, sender/recipient domain, sensitivity label on the item, file extension or size
Actions — what happens when conditions are met: restrict access, block sharing, block send, generate alert, notify user (policy tip), generate incident report, add to audit log

DLP Locations and Available Actions

Location	Available actions	Policy tips
Exchange Online	Block send, Restrict recipients, Encrypt, Quarantine, Generate alert, Add header/disclaimer	Yes (Outlook, OWA)
SharePoint Online / OneDrive	Restrict access (block external sharing), Generate alert, Apply label	Yes (web UI)
Teams chat & channel messages	Block message, Notify sender, Generate alert	Yes (Teams client)
Endpoint (MDE-enrolled devices)	Block copy to clipboard/USB/network share/printer, Block upload to cloud, Allow with override, Audit only	Yes (Windows notification)
Microsoft 365 Defender (MDCA)	Block file activity in cloud apps, Alert, Apply governance (quarantine file)	Limited (session-based)
On-premises (Purview scanner)	Apply label, Generate alert, Block access (NTFS ACL modification)	No

Policy tips are real-time notifications shown to users when their action would trigger a DLP rule — they can explain why the action is blocked and, if the policy allows it, provide an option to override with a business justification. Override events are logged and can trigger alerts for review.

Data Classification — SITs and Trainable Classifiers

Sensitive Information Types (SITs) are pattern-based detectors used by DLP, auto-labeling, and Insider Risk Management policies to identify sensitive content. Microsoft provides over 300 built-in SITs covering:

Financial data — credit card numbers (Luhn check), IBAN, ABA routing numbers, SWIFT codes
Identity data — Social Security Numbers, passport numbers, driver's licenses (country-specific)
Health data — ICD codes, drug names, medical terms combined with identifiers
Credentials — generic passwords, Azure SAS tokens, AWS keys, connection strings

A SIT definition has three components: a primary pattern (regex or dictionary), optional corroborating evidence (supporting keywords within a proximity of 300 characters — e.g., the word "card" near a credit card number pattern increases confidence), and a confidence level (Low / Medium / High). Custom SITs can combine regex, keyword lists, and functions (e.g., Luhn check).

Trainable classifiers are ML models trained on examples of content categories rather than patterns. Microsoft provides pre-trained classifiers for source code, resumes, financial statements, HR documents, customer complaints, and more. Custom trainable classifiers require a minimum of 50 positive and 50 negative seed samples, followed by a testing phase with at least 200 additional items before the classifier can be used in policies.

Microsoft Purview Audit

Purview Audit captures user and admin activity across M365 services and stores it in a tamper-resistant audit log. Two tiers:

Audit (Standard) — included with M365 E3/Business Premium. Retains audit records for 90 days (as of 2023; previously 180 days for some events). Covers most M365 workload events: SharePoint file access, Exchange mailbox activity, Teams messages, Azure AD sign-ins, admin changes.
Audit (Premium) — requires M365 E5 or E5 Compliance add-on. Retention extended to 1 year by default, with an optional add-on for 10-year retention (requires additional license). Includes intelligent insights (MailItemsAccessed, Send, SearchQueryInitiatedExchange, SearchQueryInitiatedSharePoint) — these high-value events are critical for BEC investigation because they show exactly which emails an attacker read and which search terms they used.

Audit log search is available via: the Purview portal UI, the Search-UnifiedAuditLog PowerShell cmdlet (Exchange Online module), and the Management Activity API. The API is used for SIEM integration to pull audit events in near real time.

Exam tip: If a scenario asks how to determine which emails a compromised mailbox account accessed during an attack, the answer requires Audit Premium and the MailItemsAccessed event. Standard audit does not capture this event.

Insider Risk Management

Insider Risk Management (IRM) detects potentially risky user activity that could indicate data theft, policy violations, or sabotage — particularly around employee departure or privilege escalation events. IRM uses a privacy-by-design model: user identities are pseudonymized in the analytics view until a case is escalated by a reviewer with appropriate permissions.

Key components:

Policy templates — Data theft by departing users, Data leaks (general), Data leaks by priority users, Security policy violations, Offensive language in email
Policy indicators — specific activity signals that contribute to risk scoring: bulk file download from SharePoint, copy to USB/cloud storage, printing sensitive files, risky browser activity, endpoint DLP violations, HR connector events (termination date from Workday/SuccessFactors)
Risk scoring — cumulative risk score based on indicator frequency, sensitivity of data touched, and trigger events (e.g., receiving a resignation notice from HR connector). Users above the threshold surface in the risk dashboard.
Case management — reviewers with the Insider Risk Management Analyst role can open cases, view the user's activity timeline, add notes, request eDiscovery content collection, and escalate to HR or legal
Privacy controls — pseudonymization is enforced by role. The Insider Risk Management Viewer role cannot de-anonymize. De-anonymization requires the Insider Risk Management Investigator role and is audit-logged.

Communication Compliance

Communication Compliance monitors email, Teams messages, and Viva Engage posts for policy violations: harassment, discriminatory language, regulatory violations (e.g., financial advisor discussions of specific securities), or confidential information sharing. Key exam points:

Policies are scoped to specific supervised users (not the entire organization by default, to manage review volume)
Policy conditions can combine: keyword/phrase match, SIT detection, trainable classifiers, direction (inbound/outbound/internal), and attachment type
Matched communications go into a review queue; reviewers classify each item as Compliant, Non-compliant, Questionable, or Resolved
Reviewers cannot see their own communications — the policy excludes the reviewing user

eDiscovery — Holds and Collections

Microsoft Purview eDiscovery (Premium) supports legal hold and content collection workflows critical for incident response and litigation. The workflow:

Case creation — an eDiscovery case contains all holds, searches, and exports for a matter
Custodian management — add custodians (users whose content is in scope); the system identifies all data sources associated with each custodian (mailbox, OneDrive, Teams chat)
Hold — placing a custodian's data on hold preserves it from deletion even if the user deletes it or retention policies would otherwise remove it. Holds are non-destructive and transparent to the user.
Collection — a search within the case to identify relevant content; draft collection shows estimated results before committing
Review set — collected content is copied into a review set for analysis: deduplication, near-duplicate detection, email threading, conversation reconstruction
Export — content exported in PST, native format, or PDF for legal review

For incident response, eDiscovery holds are used to preserve mailbox content and SharePoint files belonging to compromised accounts while the investigation is active, preventing auto-deletion policies from destroying evidence.

Zero Trust Architecture

Zero Trust is a security model built on three core principles:

Verify explicitly — always authenticate and authorize based on all available data points: identity, location, device health, service or workload, data classification, and anomalies. Never rely on network location alone.
Use least privilege access — limit user access with just-in-time and just-enough-access policies, risk-based adaptive policies, and data protection to secure data and maintain productivity.
Assume breach — minimize blast radius, segment access, encrypt all sessions end-to-end, use analytics to gain visibility, and drive threat detection and defense improvement.

Zero Trust is not a single product — it is an architectural posture that maps controls across six technology pillars. Microsoft's Zero Trust framework defines these pillars and the controls that implement each:

Identity Pillar

All access decisions start with a verified identity. Controls:

Multi-factor authentication (MFA) — Microsoft Authenticator, FIDO2 hardware keys, certificate-based authentication. MFA remains the single most effective control against credential-based attacks.
Conditional Access — policy engine that evaluates identity, device compliance, location, app sensitivity, and real-time risk signals before granting access. The decision is: Allow, Block, Grant with controls, or Session with controls.
Privileged Identity Management (PIM) — just-in-time elevation of privileged roles (Global Admin, Security Admin) with time limits, MFA re-authentication, approval workflows, and justification requirements.
Microsoft Entra ID Protection — risk-based signals (leaked credentials, atypical travel, anonymous IP, malware-linked IP) surfaced as user risk and sign-in risk. CA policies can block or require MFA re-authentication when risk levels exceed thresholds.
SSPR (Self-Service Password Reset) — reduces helpdesk load and eliminates insecure out-of-band password reset procedures that attackers exploit via social engineering.

Endpoint Pillar

Devices must prove compliance before accessing corporate resources. Controls:

Defender for Endpoint — provides device health signals (MDE risk level: None / Low / Medium / High) that feed into Conditional Access via the device compliance framework
Intune compliance policies — define what a "compliant" device means: BitLocker enabled, OS version minimum, antivirus on, screen lock required, jailbreak/root detection for mobile. Non-compliant devices are blocked from accessing resources by Conditional Access.
Microsoft Entra hybrid join / Entra join — device identity in Entra ID allows CA to enforce the "Require device to be marked as compliant" or "Require Hybrid Azure AD joined device" grant controls
Endpoint DLP — prevents sensitive data from leaving compliant managed devices via USB, clipboard, print, or cloud upload

Application Pillar

Applications are accessed only through verified sessions with appropriate controls. Controls:

App Conditional Access — CA policies scoped to specific cloud apps (Exchange Online, SharePoint, Salesforce) enforce different controls based on app sensitivity
Session controls via MDCA — Conditional Access App Control routes sessions through MDCA reverse proxy for real-time monitoring and enforcement (block download, watermark, require step-up auth)
Microsoft Entra Application Proxy — publishes on-premises web applications through Entra ID without opening inbound firewall ports; users authenticate with Entra ID credentials and MFA before reaching the on-prem app
OAuth app governance — MDCA reviews and governs third-party apps with OAuth delegated permissions to M365 data

Network Pillar

Networks are segmented; no implicit trust based on being "inside" the corporate perimeter. Controls:

Microsegmentation with NSGs — Network Security Groups apply at the subnet and NIC level in Azure VNets. Zero Trust NSG design places each workload tier in its own subnet with NSG rules that only allow necessary traffic flows — no blanket "allow all internal" rules.
Private Endpoints — Azure services (Storage, Key Vault, SQL, etc.) accessed via private IP addresses inside the VNet rather than public endpoints, eliminating exposure on the public internet
Azure Firewall — centralized, stateful, layer 7 firewall with FQDN filtering, threat intelligence-based filtering, and TLS inspection for east-west and north-south traffic
Microsoft Entra Private Access (ZTNA) — Zero Trust Network Access solution that replaces VPN for on-premises resource access. Users authenticate with Entra ID + MFA and get per-application access to on-premises resources through the Global Secure Access client, without network-level access to the entire LAN segment.
Microsoft Entra Internet Access — Secure Web Gateway in the Global Secure Access architecture that applies CA policies to internet-bound traffic, including protection against malicious sites and data exfiltration controls

Infrastructure Pillar

Cloud and on-premises infrastructure components are hardened and continuously monitored. Controls:

Azure Policy — governance guardrails that enforce configuration standards (e.g., "Storage accounts must use HTTPS only", "VMs must use managed disks") with deny effects that prevent non-compliant resource deployment
Defender for Cloud — continuous posture assessment against MCSB (Microsoft Cloud Security Benchmark), NIST, CIS, and PCI-DSS; generates recommendations with remediation steps; calculates Secure Score
Just-in-Time VM access (JIT) — Defender for Cloud blocks management ports (RDP/SSH — TCP 3389/22) on VMs by default via NSG rules. When an admin needs access, they request JIT access for a specific time window; Defender for Cloud temporarily opens the port for the requesting IP only, then automatically closes it.
Azure Secure Score — aggregated health score for Azure subscriptions based on implemented vs. available security controls. Each recommendation has a point value; remediating recommendations increases the score.
Container security — Defender for Containers provides runtime threat detection for AKS and Arc-enabled Kubernetes clusters, plus image vulnerability scanning in container registries

Data Pillar

Data is protected based on its classification, regardless of where it resides. Controls:

Purview Information Protection — sensitivity labels with encryption travel with the data; even if a file is exfiltrated, it cannot be opened by unauthorized recipients
Encryption at rest — all Azure storage services (Blob, Files, SQL, Cosmos DB) encrypt data at rest using AES-256 with Microsoft-managed keys by default. Customer-managed keys (CMK) in Azure Key Vault provide additional control — if the key is revoked, the data becomes inaccessible.
Encryption in transit — TLS 1.2+ enforced for all Azure service endpoints; Storage accounts can be configured to deny HTTP (unencrypted) access
RBAC on data — Azure RBAC roles (Storage Blob Data Reader, Storage Blob Data Contributor) and Purview data catalog roles control who can access data assets at the Azure control plane and data plane levels
DLP policies — Endpoint DLP and Exchange/SharePoint DLP prevent sensitive data from leaving controlled environments

Zero Trust Pillars Architecture

Zero Trust six pillars with mapped Azure and Microsoft security controls, and maturity stages from Traditional through Optimal.

Zero Trust Maturity Model

Pillar	Traditional	Advanced	Optimal
Identity	Password-only, static group memberships	MFA enforced for admin accounts; some CA policies	Phishing-resistant MFA (FIDO2/CBA); PIM for all privileged roles; risk-based CA; continuous access evaluation
Endpoints	No device compliance checks; unmanaged devices allowed	Intune enrolled; basic compliance (OS version, AV); MDM for corporate devices	All devices Intune-managed; MDE integrated; device risk blocks access; Endpoint DLP active
Applications	All internal apps accessible on network; no session controls	Some apps behind App Proxy; basic CA scoped to specific apps	All apps proxied or SaaS; full CA coverage; MDCA session controls on sensitive apps; OAuth governance enforced
Network	Flat network; VPN grants full LAN access; no east-west filtering	NSGs on subnets; Private Endpoints for key services; VPN with split tunneling	Full microsegmentation; Azure Firewall for all flows; ZTNA replaces VPN; internet traffic through Entra Internet Access
Infrastructure	Manual patching; RDP/SSH open to internet; no posture management	Defender for Cloud deployed; JIT enabled for VMs; Azure Policy in audit mode	Azure Policy deny effects; JIT mandatory; no public management ports; workload identity for infra access; Defender for Containers active
Data	No classification; encryption only for some workloads; broad ACLs	Sensitivity labels deployed; DLP policies in audit/warn mode; CMK for critical data stores	All sensitive data classified and encrypted; DLP blocking enforced; data access governed by Purview; least-privilege data RBAC

Microsoft Defender Threat Intelligence (MDTI)

MDTI is Microsoft's threat intelligence platform that aggregates data from the Microsoft global sensor network — trillions of signals per day from Windows Defender telemetry, Bing crawling, Azure network flows, and Microsoft's dedicated threat intelligence research teams (MSTIC, DART). It provides:

Threat actor profiles — named threat groups (Midnight Blizzard, Volt Typhoon, Storm-XXXX designations) with TTPs, targeted industries, known infrastructure, and historical campaign data mapped to MITRE ATT&CK
Indicators of Compromise (IoCs) — IP addresses, domains, URLs, file hashes, and email addresses associated with known malicious activity, enriched with context (first/last seen dates, associated campaigns, affected countries)
Vulnerability intelligence — CVE details enriched with exploitation evidence ("has been exploited in the wild"), affected Microsoft and third-party products, and links to relevant threat actor activity that uses the vulnerability
Infrastructure analysis — WHOIS, passive DNS, SSL certificate, and subdomain data that allows analysts to pivot from a known malicious indicator to uncover the broader attacker infrastructure

MDTI Integration with Microsoft Sentinel

MDTI can feed IoC data into Sentinel through two mechanisms:

TAXII connector — Sentinel's Threat Intelligence TAXII data connector polls a TAXII 2.x server (MDTI exposes one) on a scheduled interval and imports matching indicators into the ThreatIntelligenceIndicator table in Log Analytics. Once in the table, indicators are available for KQL queries and analytics rule matching.
Threat Intelligence Platforms (TIP) connector — integrates with third-party TIP platforms (MISP, ThreatConnect, Anomali) via the Microsoft Graph Security API tiIndicators endpoint. Indicators pushed to the Graph API appear in the same ThreatIntelligenceIndicator table.

Within Sentinel, the Threat Intelligence blade provides a searchable UI over the ThreatIntelligenceIndicator table, allowing analysts to search for specific IoCs, view their validity period, and manually add or retire indicators.

TI-based analytics rules in Sentinel can automatically match imported indicators against incoming log data. The built-in TI map * to * analytics rule templates cover:

TI map IP entity to AzureActivity — matches malicious IPs against Azure management plane activity
TI map IP entity to CommonSecurityLog — matches against CEF/Syslog firewall and proxy events
TI map Domain entity to DNS Events — matches malicious domains against DNS query logs
TI map File Hash entity to DeviceFileEvents — matches malicious hashes against MDE file telemetry

MDTI Integration with Defender XDR

Inside Defender XDR, MDTI enrichment surfaces automatically in incident and entity pages:

When an incident involves an IP address or domain that matches an MDTI indicator, the entity page shows the threat intelligence context inline — threat actor association, campaign details, confidence level
The Threat Intelligence section in the Defender XDR portal provides a direct UI into MDTI (for customers with the MDTI license or Defender XDR with MDTI integration enabled)
Advanced hunting can query the ThreatIntelligenceIndicator table directly for correlation with DeviceEvents, EmailEvents, and other workload tables

Hunting with Threat Intelligence

A practical KQL pattern for correlating MDTI IoCs against endpoint telemetry in Sentinel:

// Find devices that made network connections to known malicious IPs
let MaliciousIPs = ThreatIntelligenceIndicator
    | where Active == true
    | where ExpirationDateTime > now()
    | where NetworkIP != ""
    | project NetworkIP, Description, ThreatType, ConfidenceScore;
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where ActionType == "ConnectionSuccess"
| join kind=inner MaliciousIPs on $left.RemoteIP == $right.NetworkIP
| project Timestamp, DeviceName, RemoteIP, RemotePort,
          ThreatType, ConfidenceScore, Description
| order by Timestamp desc

// Find emails with attachments matching known malicious hashes
let MaliciousHashes = ThreatIntelligenceIndicator
    | where Active == true
    | where FileHashValue != ""
    | project FileHashValue, FileHashType, ThreatType;
EmailAttachmentInfo
| where Timestamp > ago(7d)
| join kind=inner MaliciousHashes on $left.SHA256 == $right.FileHashValue
| project Timestamp, SenderFromAddress, RecipientEmailAddress,
          FileName, SHA256, ThreatType
| order by Timestamp desc

Exam Tips & Key Takeaways

MDI sensor placement — the MDI sensor runs directly on each domain controller, not on a dedicated server. Forgetting this distinction leads to wrong answers about deployment architecture.
MDE passive mode vs. block mode — when a non-Microsoft AV is the primary protection, MDE runs in passive mode (detects but does not block). EDR in block mode must be explicitly enabled to allow MDE to block even in passive mode. This is a common exam distinction.
ASR rule modes — before enforcing Block in production, always use Audit mode first. Exam scenarios about "minimizing disruption while implementing ASR" always point to Audit mode.
Conditional Access App Control requires MDCA — session controls in Conditional Access ("Use Conditional Access App Control") route the session through the MDCA reverse proxy. Without a Defender for Cloud Apps license, this option has no effect.
Audit Premium for MailItemsAccessed — the ability to determine which emails a compromised account accessed requires Audit (Premium), not Audit (Standard). Standard audit does not capture the MailItemsAccessed event.
DLP Endpoint requires MDE onboarding — Endpoint DLP only works on devices enrolled in Defender for Endpoint. If a question asks how to prevent sensitive file copy to USB on laptops, the prerequisites include MDE onboarding, not just a DLP policy.
IRM pseudonymization — in Insider Risk Management, user identities are pseudonymized by default. De-anonymization requires the Investigator role and is audit-logged. This is important for exam questions about privacy controls in IRM.
JIT access closes ports automatically — JIT VM access temporarily opens management ports for a specified time and IP range, then automatically reverts the NSG rule. Analysts don't need to remember to close ports.
Golden Ticket detection requires MDI + DC sensors — Kerberos Golden Ticket attacks are only detectable if MDI sensors are on every DC. Missing sensors on even one DC creates a blind spot.
Zero Trust maturity: VPN → ZTNA — a common scenario describes an organization wanting to replace VPN with per-application access. The answer is Microsoft Entra Private Access (Global Secure Access), not App Proxy (which is for HTTP/HTTPS apps only).
MDTI TAXII in Sentinel — threat intelligence IoCs are imported via the TAXII connector into the ThreatIntelligenceIndicator table. Analytics rules then match these against log data. The exam may test the table name or the connector type.
AIR automation levels matter — the automation level (No automation / Semi / Full) is set per device group in MDE, not globally. Production device groups typically use Semi automation to require human approval for remediation actions.
Sensitivity label encryption persists — AIP/MIP encryption travels with the file. Even if a labeled file is emailed externally or copied to a USB drive, recipients without the appropriate Entra ID permission cannot open it.
Custom trainable classifiers need a testing phase — after providing seed examples, classifiers go through a test-and-evaluate phase before they can be used in policies. You cannot deploy a custom classifier immediately after training.