223 lines
13 KiB
Markdown
223 lines
13 KiB
Markdown
# Assignment: Identity Baseline
|
|
|
|
> *Enforce what you already have. Every other M365 security control is downstream of this one.*
|
|
|
|
This is a **scoped assignment package** — a complete, principled delivery guide for one specific client brief. It is designed to work with limited organizational engagement and to leave behind infrastructure that holds without anyone needing to want it.
|
|
|
|
---
|
|
|
|
## The Brief
|
|
|
|
Client requests that fall within this scope:
|
|
|
|
- *"Secure our M365 / our identities are a mess"*
|
|
- *"We need MFA enforced — the auditor asked for it"*
|
|
- *"We got phished and IT wants to prevent it happening again"*
|
|
- *"Review our user accounts and admin accounts"*
|
|
- *"Make sure only the right people have access"*
|
|
|
|
This assignment does not require executive sponsorship. It requires one named IT lead with Global Administrator access and a tolerance for findings.
|
|
|
|
---
|
|
|
|
## Scope Boundary
|
|
|
|
**In scope:**
|
|
- Entra ID authentication configuration (MFA, legacy auth, auth methods)
|
|
- Conditional Access policy review for existing policies (not full CA architecture)
|
|
- Global Administrator and other privileged role audit
|
|
- Break-glass account establishment
|
|
- Entra ID Protection risk policy baseline
|
|
- Authentication method registration and SSPR configuration
|
|
- Service principal and app registration review (inventory and flag — not remediate)
|
|
|
|
**Out of scope:**
|
|
- Conditional Access policy design and architecture → [Assignment: CA Architecture](assignment-ca-architecture.md)
|
|
- Device compliance and Intune → [Assignment: Intune Security Baseline](assignment-intune-security-baseline.md)
|
|
- Privileged Access Management (PIM, PAM, PAW) → separate privileged access engagement
|
|
- Active Directory on-premises → hybrid identity engagement
|
|
- Application permissions remediation → separate service identity engagement
|
|
|
|
When the client asks for something adjacent, log it in the scope boundary signals section at the end of the engagement. Do not absorb it silently and do not pitch the next engagement. The log is the record.
|
|
|
|
---
|
|
|
|
## Before You Touch Anything
|
|
|
|
These three steps happen before any change, on day one.
|
|
|
|
**1. Break-glass accounts.**
|
|
If the tenant has no cloud-only break-glass accounts excluded from all CA policies, create two before proceeding. Document their credentials out of band (not in the same tenant). Alert on their sign-in. This is the safety net. Without it, a misconfigured CA policy can lock the entire tenant — including you.
|
|
|
|
**2. CAExporter baseline.**
|
|
Export the current CA policy state using [CAExporter](https://github.com/merill/caexporter). This JSON export is the before-state. Every change made during this engagement is measurable against it. It is also the rollback reference if something breaks.
|
|
|
|
**3. Authentication sign-in log baseline.**
|
|
Export 30 days of Entra sign-in logs, filtered for legacy authentication clients. This is the baseline for measuring the impact of legacy auth block and the evidence that the block is complete. Without it, you cannot demonstrate that legacy auth is actually gone — only that a policy exists.
|
|
|
|
---
|
|
|
|
## Principles Applied
|
|
|
|
**Automation over procedure.**
|
|
Every control in this assignment is a policy, not a document. MFA enforcement is a CA policy, not a user awareness campaign. Legacy auth block is an authentication policy or CA rule, not a helpdesk notification. A procedure only works when someone follows it. A policy works when no one is looking.
|
|
|
|
**Kill chain first.**
|
|
There are two controls in this assignment that matter more than all others: MFA enforcement on all users, and legacy auth block. Everything else — admin hygiene, SSPR configuration, risk policies — is valuable but secondary. If the engagement ends early, these two must be complete.
|
|
|
|
**Visibility as accountability.**
|
|
Every export, every report, every baseline produced during this engagement exists in the client's own tenant and documentation system permanently. A sign-in log showing zero legacy auth clients is evidence that outlasts the engagement. An admin account inventory with a date on it creates accountability that does not require anyone to actively manage it.
|
|
|
|
**Scope discipline.**
|
|
Anything discovered outside scope goes into the scope boundary log — not into the work plan. A consultant who silently fixes adjacent problems during a scoped engagement creates unscoped liability and destroys the client's ability to understand what was done. Log it, name it, leave it.
|
|
|
|
---
|
|
|
|
## Delivery Architecture
|
|
|
|
Sequenced by impact, not by calendar. Each step depends on the one before it.
|
|
|
|
### Step 1 — Baseline (no changes)
|
|
|
|
| Action | Output |
|
|
|--------|--------|
|
|
| CAExporter export | CA policy baseline JSON |
|
|
| Break-glass accounts created and monitored | Break-glass documentation (out of band) |
|
|
| Sign-in log export: legacy auth clients | Legacy auth client list |
|
|
| Global Administrator audit: who holds it, cloud-only vs synced, standing vs eligible | Admin account inventory |
|
|
| Service principal inventory: client secrets expiry, Graph permissions, admin consent | Service principal risk log |
|
|
| Authentication method registration report | Who has MFA registered, by method |
|
|
| SSPR configuration review | Current state documented |
|
|
|
|
At the end of Step 1, share the admin account inventory and legacy auth client list with the named client lead. No recommendations yet. Just findings, plainly stated.
|
|
|
|
---
|
|
|
|
### Step 2 — Kill Chain (two controls)
|
|
|
|
**Legacy authentication block.**
|
|
Deploy via Entra authentication policies (tenant-wide, preferred) or CA policy (targeted by legacy auth client type). Stage it: report mode for 48 hours, confirm zero legitimate legacy auth clients in sign-in logs, then enforce. The 48-hour window exists because there are always surprises — a printer, a shared mailbox script, an MFA-unregistered VIP. Find them before enforcement, not after.
|
|
|
|
**MFA enforcement.**
|
|
If the client has no CA policies at all: deploy one CA policy requiring MFA for all users, all cloud apps, excluding break-glass accounts. If the client has existing CA policies: review coverage gaps and close them. Staged: exclude a pilot group of 10 users for 24 hours, confirm no breakage, then enforce broadly.
|
|
|
|
These two controls are the assignment's kill chain contribution. Legacy auth block plus MFA enforcement closes the most common attack path in the Microsoft ecosystem. Both should be complete before Step 3 begins.
|
|
|
|
---
|
|
|
|
### Step 3 — Admin Hygiene
|
|
|
|
**Global Administrator audit.**
|
|
Every account with Global Administrator should be cloud-only (not synced from on-premises AD — a synced account can be compromised on-prem to take the cloud). Count standing Global Admins. The target is zero standing Global Admins beyond break-glass and emergency access. If PIM is not in scope, document the gap and log it. If the client has PIM licensing (P2), note it — it is the correct next step.
|
|
|
|
**Admin account separation.**
|
|
Admins should have a dedicated admin account separate from their daily-use account. If they do not, log it as a scope boundary signal for a privileged access engagement. If the client will accept one quick win: rename or create dedicated admin accounts for any standing Global Admins. This is a short task with meaningful blast-radius reduction.
|
|
|
|
**Service principal review.**
|
|
Flag any service principal with:
|
|
- Client secrets expiring in under 30 days (operational risk, not security risk — but surfaces the gap)
|
|
- Tenant-wide admin consent granted
|
|
- Graph permissions: `RoleManagement.ReadWrite.Directory`, `AppRoleAssignment.ReadWrite.All`, `Application.ReadWrite.All`, `Directory.ReadWrite.All`
|
|
|
|
Log all flags in the scope boundary signals. Do not remediate service principals in this assignment — it requires application owner coordination and deserves its own scoped engagement.
|
|
|
|
---
|
|
|
|
### Step 4 — Risk Baseline
|
|
|
|
**Entra ID Protection.**
|
|
If the tenant has P2 licensing (included in E5, available separately), deploy:
|
|
- User risk policy: require password change at High risk (Conditional Access, not legacy user risk policy)
|
|
- Sign-in risk policy: require MFA step-up at Medium or High risk
|
|
|
|
If no P2: document the gap. Log the licensing delta for the leave-behind.
|
|
|
|
**SSPR.**
|
|
If SSPR is not enabled: enable it for all users with a minimum of two authentication methods required. Default to Microsoft Authenticator + email or phone. SSPR with strong auth methods removes helpdesk dependency for password resets and is a prerequisite for a healthy MFA rollout.
|
|
|
|
---
|
|
|
|
## Structural Resilience Checklist
|
|
|
|
Controls that hold without ongoing human willingness after this engagement closes.
|
|
|
|
- [ ] MFA enforcement CA policy active — not in report mode
|
|
- [ ] Legacy authentication blocked at tenant level — not just reported
|
|
- [ ] Break-glass accounts exist, are cloud-only, are excluded from CA, are monitored with alerts
|
|
- [ ] Break-glass credentials documented out of band
|
|
- [ ] Sign-in risk and user risk policies active (if P2 licensed)
|
|
- [ ] CAExporter export stored in client documentation
|
|
- [ ] SSPR active for all users
|
|
|
|
These are the controls that keep working after the engagement ends. If any item is not checked at handover, document why and log the residual risk.
|
|
|
|
---
|
|
|
|
## Kill Chain Contribution
|
|
|
|
**What this assignment closes:**
|
|
|
|
| Attack vector | Control deployed |
|
|
|---------------|-----------------|
|
|
| Password spray against cloud accounts | MFA enforcement |
|
|
| Credential stuffing using breached passwords | MFA enforcement + Entra ID Protection |
|
|
| Legacy authentication protocol abuse (SMTP, IMAP, MAPI) | Legacy auth block |
|
|
| Basic phishing for MFA bypass via legacy clients | Legacy auth block |
|
|
| Attacker using compromised admin account persistently | Break-glass monitoring, admin hygiene |
|
|
|
|
**What this assignment does not close:**
|
|
|
|
| Remaining gap | Addressed by |
|
|
|---------------|-------------|
|
|
| Device-based attacks (unmanaged device as access vector) | [Assignment: Intune Security Baseline](assignment-intune-security-baseline.md) |
|
|
| Adversary-in-the-middle / session token theft | Device compliance in CA + token protection |
|
|
| Standing Global Administrator accounts | Privileged access engagement (PIM) |
|
|
| Service principal over-permission | Service identity engagement |
|
|
| Data exfiltration through sanctioned apps | Collaboration and data security assignment |
|
|
| Persistence via application consent abuse | Service identity engagement |
|
|
|
|
The kill chain contribution of this assignment is significant and real. The residual gaps are also real. Both belong in the leave-behind.
|
|
|
|
---
|
|
|
|
## Leave-Behind Package
|
|
|
|
Every item below must be delivered at handover. The engagement is not complete until all items exist in the client's own documentation system.
|
|
|
|
| Artifact | Description |
|
|
|----------|-------------|
|
|
| **CAExporter JSON (before)** | CA policy state at engagement start |
|
|
| **CAExporter JSON (after)** | CA policy state at engagement close |
|
|
| **Admin account inventory** | Every privileged role assignment: account name, role, cloud-only vs. synced, standing vs. eligible, last sign-in |
|
|
| **Legacy auth sign-in confirmation** | Sign-in log export showing zero legacy auth clients post-block |
|
|
| **MFA registration report** | Authentication method registration by user, at engagement close |
|
|
| **Break-glass documentation** | Account names, monitoring alert confirmation, out-of-band credential storage reference |
|
|
| **Service principal risk log** | Flagged principals with permissions and expiry dates |
|
|
| **Scope boundary log** | Every finding outside this scope, named and prioritized |
|
|
| **Residual risk statement** | Plain-language summary of what this assignment did not close and why |
|
|
|
|
The residual risk statement is not optional. A client who receives a clean handover without a residual risk statement has been misled about their posture.
|
|
|
|
---
|
|
|
|
## Scope Boundary Signals
|
|
|
|
Log these when you find them. Do not fix them. Do not pitch them. The log is the record.
|
|
|
|
| Signal | Points toward |
|
|
|--------|--------------|
|
|
| No device compliance policies exist | Intune Security Baseline assignment |
|
|
| CA policies exist but are poorly designed (overlapping, unnamed, undocumented) | CA Architecture assignment |
|
|
| Global Admins have standing privilege with no PIM | Privileged access engagement |
|
|
| Entra Connect / Cloud Sync server is domain-joined to production domain | Hybrid identity engagement — T0 isolation |
|
|
| AD FS present | Hybrid identity engagement — Golden SAML risk, migration to PHS |
|
|
| Service principals with tenant-wide admin consent | Service identity engagement |
|
|
| No Defender for Office 365 baseline | Collaboration security assignment |
|
|
| Audit logging not configured or retention < 90 days | Detection baseline assignment |
|
|
|
|
---
|
|
|
|
*For the conditional access architecture built on top of this baseline, see [Assignment: CA Architecture](assignment-ca-architecture.md).*
|
|
*For technical depth on hybrid identity and the sync server risk, see [Book II — Hybrid Identity](../books/01-hybrid-identity.md).*
|
|
*For privileged access architecture, see [Book III — Privileged Access](../books/02-privileged-access.md).*
|