Microsoft 365 Security

Defender for Endpoint covers the endpoint EDR layer: device onboarding, ASR rules, tamper protection, and EDR in block mode. This chapter covers Microsoft 365 security in two parts: configuration of the administrative controls in SharePoint, Teams, and Defender for Office 365 that define what is and isn't allowed; and the security operations tools used to detect, investigate, and respond to threats.

Product / Admin Center	Function	Primary Concern
SharePoint Admin Center	Unmanaged device access, external sharing	Data exposure from unmanaged or guest access
Teams Admin Center	External access, guest access, meeting policies	Unauthorized external communication
Defender for Office 365 (MDO)	Safe Links, Safe Attachments, anti-phishing	Phishing, BEC, malware in email and files
Defender for Cloud Apps (MDA)	SaaS visibility, OAuth governance, session controls	Data exfiltration, insider threats, cloud misuse
Defender for Identity (MDI)	Active Directory and Entra ID anomaly detection	Credential theft, lateral movement, reconnaissance
Defender XDR Portal	Unified incident correlation and response	Correlated triage across all workloads

Licensing

GCC High (CMMC)

MDO Plan 2, MDA, and MDI are included in Microsoft 365 GCC High E5 and Microsoft 365 GCC High E5 Security. If the tenant is on E3, they are available as add-ons.

Product	Minimum License
MDO Plan 1 (Safe Links, Safe Attachments)	M365 E3 + Defender for Office 365 P1 add-on, or E5
MDO Plan 2 (Threat Explorer, AIR, Attack Sim)	M365 E5 or E5 Security
Defender for Cloud Apps	M365 E5, E5 Security, or MDA standalone
Defender for Identity	M365 E5, E5 Security, or MDI standalone

Portal: https://security.microsoft.us (GCC High XDR portal)

Commercial

Product	Minimum License
MDO Plan 1	M365 Business Premium, E3 + P1 add-on, or E5
MDO Plan 2	M365 E5 or E5 Security
Defender for Cloud Apps	M365 E5, E5 Security, or MDA standalone
Defender for Identity	M365 E5, E5 Security, or MDI standalone

Portal: https://security.microsoft.com

---

Microsoft 365 Security Configuration

SharePoint Admin Center

The SharePoint Admin Center governs tenant-wide sharing and unmanaged device access. Two settings here are prerequisites for controls configured elsewhere in this guide.

Unmanaged Device Access

This setting limits what SharePoint and OneDrive deliver to browser sessions on devices that are not Intune-managed or hybrid-joined. It is the server-side component that makes the Conditional Access "Use app enforced restrictions" policy effective. Without this setting enabled, the CA policy has no enforcement effect on SharePoint.

GCC High (CMMC)

Navigate to: SharePoint Admin Center (admin.sharepoint.us) → Policies → Access control → Unmanaged devices

Commercial

Navigate to: SharePoint Admin Center (admin.sharepoint.com) → Policies → Access control → Unmanaged devices

Setting	Recommended Value
Unmanaged devices	Allow limited, web-only access

Allow limited, web-only access blocks download, sync, and print from unmanaged devices while permitting browser-based viewing. This satisfies the requirement to protect data on unmanaged devices without blocking access entirely.

Relationship to Conditional Access

The Conditional Access — App-Enforced Restrictions policy sends SharePoint a session token indicating whether the device is compliant. SharePoint's unmanaged device setting then determines what that non-compliant session can do. Both must be configured for the control to function end-to-end.

GCC High (CMMC)

NIST SP 800-171 Rev. 3 3.1.19 requires protecting CUI on mobile and non-organizational devices. This setting, combined with the CA app-enforced restrictions policy, is the technical control satisfying that requirement for browser-based SharePoint access.

Commercial

For HIPAA and GLBA environments, this setting satisfies the "technical safeguard" requirement for remote access to ePHI or GLBA-regulated data without requiring device enrollment as a prerequisite.

External Sharing

Tenant-wide sharing settings establish the ceiling for what sensitivity label container policies can permit. Labels can restrict sharing further on a per-site basis but cannot exceed the tenant default.

Setting	Recommended Value
SharePoint external sharing	New and existing guests (requires sign-in)
OneDrive external sharing	New and existing guests
Guests must sign in using the same account invitations are sent to	On

Navigate to: SharePoint Admin Center → Policies → Sharing

---

Teams Admin Center

The Teams Admin Center governs external communication, guest participation, and meeting behavior. These settings interact with sensitivity label container policies for Teams channels.

External Access

External access allows your Teams users to search for, call, and chat with users in external Microsoft 365 tenants.

Navigate to: Teams Admin Center → Users → External access

Setting	Recommended Value
Allow users to communicate with Teams users in external organizations	On — restrict to specific domains if the organization's external partner list is well-defined
Allow users to communicate with Skype for Business users	Off unless operationally required

Guest Access

Guest access allows external users to be added as members of Teams channels.

Navigate to: Teams Admin Center → Users → Guest access

Setting	Recommended Value
Allow guest access in Teams	On
Allow guests to make private calls	Off
Allow guests to use IP video	On
Allow guests to edit sent messages	On
Allow guests to delete sent messages	Off

Meeting Policies

Navigate to: Teams Admin Center → Meetings → Meeting policies → Global (org-wide default)

Setting	Recommended Value
Anonymous users can join a meeting	Off
Who can bypass the lobby	People in my organization and guests
Allow external participants to give or request control	Off
Allow meeting recording	On
Allow transcription	On

Container label interaction

Sensitivity labels applied to Teams channels can restrict guest access and external sharing on a per-team basis, overriding these tenant defaults in a more restrictive direction. See Sensitivity Labels for label container settings.

---

Defender for Office 365

MDO adds threat protection layers on top of Exchange Online Protection (EOP), which handles basic anti-spam and anti-malware. MDO Plan 1 adds pre-delivery detonation; Plan 2 adds post-breach investigation and training.

Safe Links

Safe Links rewrites URLs in email and Office documents and checks the destination at click time against Microsoft's threat intelligence feed. This catches URLs that were benign at delivery but were weaponized after the fact — a common technique in multi-stage phishing.

Setting	Recommended Value
Enable Safe Links for email messages	On
Enable Safe Links for Office apps	On
Do not track when users click Safe Links	Off (tracking required for audit evidence)
Do not allow users to click through to original URL	On for Restricted users
Apply real-time URL scanning	On

Safe Links policies scope to recipients. Create a stricter policy for privileged users (executives, IT admins) that does not permit click-through.

Safe Attachments

Safe Attachments detonates email attachments in an isolated sandbox before delivery. Delivery is delayed by up to 5 minutes while detonation completes. For organizations where email latency is operationally sensitive, configure Dynamic Delivery — this delivers the email body immediately and replaces the attachment with a placeholder until detonation completes.

Setting	Recommended Value
Safe Attachments unknown malware response	Block
Dynamic Delivery	On (for non-privileged users)
Enable redirect	On — route malicious attachments to security team mailbox
Apply Safe Attachments to SharePoint, OneDrive, Teams	On (requires separate toggle in Global Settings)

Enable for SharePoint and Teams

Safe Attachments for SharePoint/OneDrive/Teams is controlled by a separate setting in Policies & rules → Threat policies → Global settings, not within the Safe Attachments policy itself. It is off by default.

Anti-Phishing: Impersonation Protection

MDO's anti-phishing policy adds impersonation detection on top of EOP's spoof intelligence. Impersonation protection watches for emails that claim to be from a specific user or domain without being that user or domain.

Users to protect (impersonation): Add executives, finance approvers, and any user who sends wire transfer or payroll instructions. Attackers specifically target these roles for BEC (Business Email Compromise).

Domains to protect (impersonation): Add your own domain(s) and any partner domains from which you regularly receive sensitive instructions.

Setting	Recommended Value
Enable users to protect	On — add C-suite + finance + IT admins
Enable domains to protect	On — add owned domains + key partner domains
If message is detected as impersonated user	Quarantine
If message is detected as impersonated domain	Quarantine
Enable mailbox intelligence	On
Enable intelligence for impersonation protection	On

---

Security Operations

Attack Simulation Training

Attack Simulation Training (AST) sends simulated phishing emails to users and measures click rates, credential submission rates, and reporting rates. It requires MDO Plan 2.

GCC High (CMMC)

NIST SP 800-171 Rev. 3 3.2.2 requires organizations to provide security awareness training. AST fulfills the practical exercise component of that requirement. Schedule quarterly simulations across the tenant and configure automatic training assignment for users who click.

Retain simulation results as audit evidence: Attack simulation training → Reports → export to CSV. CMMC assessors may request this as evidence of 3.2.2 compliance.

Commercial

Configure at minimum two simulation campaigns per year. Use a mix of techniques: credential harvest, link in attachment, and OAuth consent grant. Users who click should be automatically enrolled in the corresponding micro-training module (built into AST). Track improvement in click rates over time as a security program KPI.

Threat Explorer and Real-Time Detections

Threat Explorer (MDO Plan 2) and Real-Time Detections (MDO Plan 1) provide an interactive query interface over email metadata and delivery events. Use them to:

• Identify all emails from a sender during an incident
• Find all recipients of a phishing campaign across the tenant
• Determine the delivery action taken (delivered, junked, blocked, quarantined)
• Trigger soft deletes of delivered phishing emails across all mailboxes

Soft deleting a delivered phishing campaign:

1. Threat Explorer → filter by sender domain or subject
2. Select matching messages → Take actions → Move to deleted items or Soft delete
3. Review action status in the Action center

Automated Investigation and Response (AIR)

AIR (Plan 2) automatically investigates alerts, correlates related mailbox events, and recommends or executes remediation actions without analyst intervention. It is integrated with the XDR incidents view — AIR investigations appear as sub-investigations within an incident.

Enable AIR and configure the action approval setting:

Setting	Value
Automated investigation trigger	On
Remediation approval	Auto-approve for High confidence verdicts; Require approval for Medium

---

Defender for Cloud Apps

Defender for Cloud Apps is Microsoft's CASB (Cloud Access Security Broker). It sits between users and cloud apps, providing visibility into SaaS usage, behavioral analytics, and inline session controls.

Shadow IT Discovery

MDA discovers cloud apps in use across the tenant by analyzing traffic logs from Defender for Endpoint (agent-based) or by ingesting firewall/proxy logs. The output is an app catalog showing:

• App name and risk score (Microsoft-assigned, 0–10)
• Number of users and transactions
• Data uploaded/downloaded volumes
• Whether the app is sanctioned or unsanctioned

Enable cloud app discovery via MDE integration:

MDA settings → Cloud discovery → Automatic log upload → Connected apps → enable the Microsoft Defender for Endpoint integration. This routes endpoint DNS and network telemetry to MDA automatically — no firewall log collection needed.

Review the discovered app catalog monthly and Unsanction apps that pose risk (file sharing via personal storage, unapproved generative AI tools, shadow ERP integrations).

App Governance

App Governance monitors OAuth app consent grants — third-party and internal apps that have been granted permissions to the tenant. Compromised OAuth apps are a common persistence mechanism: the attacker grants a malicious app Mail.Read or Files.ReadWrite.All permissions and retains access even after the user's password is reset.

Key alert policies:

Alert	Trigger
App with high privilege	App granted Mail.ReadWrite or Directory.ReadWrite.All
Unused app with sensitive permission	OAuth app with broad permissions but < 5 users active in 90 days
App with anomalous data access	App accessing significantly more data than its baseline
Newly registered app accessing sensitive data	New app (< 30 days old) accessing labeled or sensitive content

Review the App governance dashboard monthly. Revoke consent for any app that cannot be attributed to a known IT-approved integration.

Conditional Access App Control

MDA integrates with Entra Conditional Access to proxy sessions through MDA for session-level controls. This enables policy enforcement on content within a session — not just access control at the authentication layer.

Common use cases:

Scenario	Session Policy
Unmanaged device accessing SharePoint	Block download of Confidential-labeled files
External contractor accessing Teams	Block copy/paste of sensitive content
High-risk user (Adaptive Protection)	Monitor all activity and block upload
Any user accessing sensitive SharePoint site	Apply watermark on viewed documents

Configure in Entra CA: create a Conditional Access policy with Session control → Use Conditional Access App Control → Use custom policy. Then configure the matching session policy in MDA.

GCC High (CMMC)

NIST SP 800-171 Rev. 3 3.1.19 requires protecting CUI on mobile and non-organizational devices. MDA session policies are the technical control that satisfies this requirement for browser-based access to SharePoint/Teams from unmanaged devices — blocking download of CUI without blocking access entirely.

CMMC Control Mapping

NIST Control	MDA Capability
3.1.19 — Unmanaged device access to CUI	Session policy blocks CUI download on unmanaged devices
3.13.1 — Monitor communications	Cloud app discovery monitors data flows to SaaS apps
3.14.6 — Monitor for unauthorized use	Anomalous data access alerts in App Governance

Commercial

For HIPAA and GLBA environments, session policies enforcing download blocks on unmanaged devices satisfy the "technical safeguard" requirement for remote access to ePHI or GLBA-regulated data, without requiring device enrollment as a prerequisite.

---

Defender for Identity

Defender for Identity (MDI) monitors on-premises Active Directory and Entra ID for attack patterns associated with credential theft, lateral movement, and reconnaissance. It reads AD audit events via a lightweight sensor installed on domain controllers.

Sensor Deployment

Install the MDI sensor on every domain controller (primary and read-only). The sensor reads the AD event log and network traffic in real time and forwards signals to the MDI cloud service.

# Download sensor installer from MDI portal
# Settings → Sensors → Add sensor → Download installer

# Install on each DC (run as Domain Admin)
.\Azure ATP sensor Setup.exe /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<workspace-access-key>"

For GCC High, the MDI workspace endpoint is <workspace-name>.atp.azure.us — verify the installer is configured to point to the correct sovereign cloud endpoint before deploying.

After installation, verify sensor health in the MDI portal (Security.microsoft.us → Settings → Identities → Sensors) — all DCs should show Running within 5 minutes.

Key Detection Categories

Category	Example Detections
Reconnaissance	LDAP enumeration, SMB session enumeration, user/group discovery
Credential access	Pass-the-hash, pass-the-ticket, Kerberoasting, AS-REP roasting, NTLM relay
Lateral movement	Overpass-the-hash, suspected DCSync, remote code execution via WMI/PSExec
Domain dominance	Skeleton key attack, Golden Ticket, DCSync from non-DC
Exfiltration	Unusual large LDAP query, suspected NTDS.dit export

MDI triggers alerts that appear as incidents in the unified XDR portal, correlated with any related MDE, MDO, or Entra signals.

Honeytoken Accounts

MDI supports configuring honeytoken accounts — AD accounts that should never be used in normal operations. Any authentication or query against a honeytoken account generates an immediate High severity alert.

Create 2–3 honeytoken accounts with names that appear valuable to an attacker (e.g., svc-backup, admin-legacy) but are disabled or have no real permissions. Register them in MDI: Settings → Honeytoken accounts.

Integration with Entra ID Protection

MDI feeds its user risk signals into Entra ID Protection. A user flagged by MDI for pass-the-hash activity will have their Entra user risk score elevated, which can trigger a Conditional Access policy requiring MFA re-authentication or blocking access until the risk is remediated — without manual security team intervention.

Ensure the Entra ID Protection integration is enabled in MDI settings: Settings → Microsoft Entra ID → Enable Entra ID Protection integration.

---

Unified XDR Incidents View

The Microsoft Defender XDR portal correlates alerts from MDE, MDO, MDA, and MDI into unified incidents — a single case that links all related alerts, affected users, devices, and emails. This is the primary triage interface for the security operations team.

Incidents Triage Workflow

1. Incidents queue (security.microsoft.us/incidents) — sorted by severity. High/Critical incidents should be triaged within 1 hour.
2. Open an incident → review the Attack story graph — this shows the kill chain: initial access, execution, lateral movement, and data access in a visual timeline.
3. Review Evidence and response — affected mailboxes, devices, users, and cloud apps, with recommended actions for each.
4. Execute remediation actions directly from the incident: isolate device, soft delete emails, revoke user sessions, disable user account.
5. Close the incident with a classification: True positive (with threat type) or False positive.

Advanced Hunting

Advanced Hunting provides a KQL query interface over the full 30-day event history across all Defender workloads. Use it for proactive threat hunting and deep incident investigation.

Useful starting queries:

// Emails delivered containing known phishing URLs
EmailEvents
| where ThreatTypes has "Phish"
| where DeliveryAction == "Delivered"
| summarize count() by SenderFromAddress, RecipientEmailAddress, Subject
| sort by count_ desc

// Devices with high-severity MDI alerts in past 7 days
AlertInfo
| where ServiceSource == "Microsoft Defender for Identity"
| where Severity == "High"
| where Timestamp > ago(7d)
| join AlertEvidence on AlertId
| summarize Alerts=count() by DeviceName, AccountUpn
| sort by Alerts desc

// OAuth apps with Mail.ReadWrite permission granted recently
CloudAppEvents
| where ActionType == "Consent to application"
| where RawEventData has "Mail.ReadWrite"
| where Timestamp > ago(30d)
| project Timestamp, AccountDisplayName, Application=tostring(RawEventData.AppDisplayName)

Secure Score

Microsoft Secure Score aggregates configuration health across the entire Defender XDR suite into a single score. Each recommended action has an associated point value and maps to a control framework (NIST, ISO 27001, SOC 2).

Review Secure Score monthly and prioritize recommendations by:

1. Impact (points)
2. Implementation effort (Low/Medium/High)
3. Regulatory relevance (filter by NIST 800-171 to see compliance-relevant actions)

Secure Score is not a compliance score — a high score does not mean you are compliant. Use it as an operational hygiene metric alongside your compliance control matrix.