From 633f82c5a722612829ed11186f70825e75a29d4d Mon Sep 17 00:00:00 2001 From: Tomas Kracmar Date: Tue, 9 Jun 2026 16:56:48 +0200 Subject: [PATCH] feat: Add four consultant assignments (identity, CA, Intune, collaboration) --- .../playbooks/assignment-ca-architecture.md | 292 ++++++++++++ .../assignment-collaboration-security.md | 443 ++++++++++++++++++ .../playbooks/assignment-identity-baseline.md | 222 +++++++++ .../assignment-intune-security-baseline.md | 384 +++++++++++++++ 4 files changed, 1341 insertions(+) create mode 100644 antifragile-consulting/playbooks/assignment-ca-architecture.md create mode 100644 antifragile-consulting/playbooks/assignment-collaboration-security.md create mode 100644 antifragile-consulting/playbooks/assignment-identity-baseline.md create mode 100644 antifragile-consulting/playbooks/assignment-intune-security-baseline.md diff --git a/antifragile-consulting/playbooks/assignment-ca-architecture.md b/antifragile-consulting/playbooks/assignment-ca-architecture.md new file mode 100644 index 0000000..10e6ae0 --- /dev/null +++ b/antifragile-consulting/playbooks/assignment-ca-architecture.md @@ -0,0 +1,292 @@ +# Assignment: Conditional Access Architecture + +> *CA policies are enforcement points, not audit tools. A policy in report-only mode is a sensor. A policy in enabled mode is a wall. Know which you're building before you start.* + +This is a **scoped assignment package** — a complete, principled delivery guide for one specific client brief. It can be delivered standalone or immediately after [Assignment: Identity Baseline](assignment-identity-baseline.md). If identity baseline has not been completed, the prerequisites section below applies first. + +--- + +## The Brief + +Client requests that fall within this scope: + +- *"Review our Conditional Access policies — we're not sure they're right"* +- *"We need to enforce MFA properly, not just per-user MFA"* +- *"Our auditor wants evidence of access controls"* +- *"We got a new employee and nobody knows how access actually works"* +- *"We bought E5 and want to use the CA features"* +- *"We need compliant devices to be required for access"* (if Intune baseline is already deployed) + +This assignment does not require executive sponsorship. It requires one named IT lead with Global Administrator access, tolerance for a 72-hour report-only period per policy before enforcement, and awareness that policy changes affect all users. + +--- + +## Scope Boundary + +**In scope:** +- Audit of all existing CA policies (coverage, gaps, naming, exclusions, mode) +- Design and documentation of a complete CA policy set +- Staged deployment of the baseline policy set (identity-level controls) +- Device compliance integration if Intune compliance policies are already active +- Named locations configuration +- Authentication strengths configuration (phishing-resistant MFA for admins) + +**Out of scope:** +- Intune compliance policy configuration → [Assignment: Intune Security Baseline](assignment-intune-security-baseline.md) +- Microsoft Defender for Cloud Apps session controls (app-enforced restrictions are in scope; MDCA-dependent session policies are not) +- Privileged Identity Management configuration → privileged access engagement +- Identity Baseline (MFA registration, legacy auth, admin account hygiene) → [Assignment: Identity Baseline](assignment-identity-baseline.md) + +**Dependency:** This assignment can configure device compliance as a CA signal, but only if Intune compliance policies are already active and returning compliance state for enrolled devices. If Intune is not deployed, the device-compliance policies in this assignment are designed in report-only mode and left for activation when Intune is ready. Do not activate device-compliance CA policies against an environment where device enrollment is incomplete — the result is a broad lockout. + +--- + +## Before You Touch Anything + +**1. Break-glass confirmation.** +Before touching any CA policy, confirm that two cloud-only break-glass Global Admin accounts exist and are excluded from all CA policies. If they do not exist, create them and configure sign-in alerts before proceeding. See [Assignment: Identity Baseline](assignment-identity-baseline.md) for the break-glass standard. This step is non-negotiable — a misconfigured CA policy with no break-glass is a full tenant lockout. + +**2. CAExporter baseline.** +Export all existing CA policies using [CAExporter](https://github.com/merill/caexporter). Store the JSON export as the before-state. Every change is measurable against it. This is also the rollback reference. + +**3. Per-user MFA audit.** +Run the per-user MFA state report (Entra admin center → Users → Per-user MFA). If per-user MFA is enabled for any accounts, document it. Per-user MFA and CA-enforced MFA operate on separate control planes and interact unpredictably: a user with per-user MFA *enforced* may bypass some CA policies. Resolution is part of Step 3 below. + +**4. Sign-in log baseline.** +Export 30 days of sign-in logs. Note the distribution of authentication methods in use, client application types (modern vs. legacy), and any conditional access results (success, failure, report-only). This is the baseline against which policy impact is measured. + +--- + +## Principles Applied + +**Automation over procedure.** +A CA policy enforces MFA whether or not anyone remembers to ask for it. A checklist does not. Every identity control in this assignment is implemented as a CA policy — self-enforcing, continuous, requiring no human decision to operate after deployment. + +**Kill chain first.** +The policy set in this assignment is sequenced by structural impact. Legacy auth block and universal MFA enforcement come first because they close the widest attack path. Device compliance, location controls, and session policies come after. If the engagement ends early, the first two policies are the ones that matter. + +**Explicit design, documented intent.** +Every policy deployed in this assignment has a documented name, purpose, conditions, grant controls, exclusions, and the date it was set to enabled. A CA policy with no documented intent is a liability: nobody can safely modify it, nobody knows if it can be removed, and future administrators work around it rather than through it. The leave-behind package for this assignment is the policy design document — not just the JSON export. + +**Report-only before enforcement.** +Every new policy goes to report-only mode for a minimum of 48–72 hours. Sign-in logs are reviewed during that window to confirm expected behavior before enforcement. This is not optional. The cost of a production lockout — even for 30 minutes — is higher than the cost of 72 hours' delay. + +--- + +## Delivery Architecture + +### Step 1 — Audit (no changes) + +Document the current state honestly. The finding is not a criticism of the IT team — it is the starting point. + +| Action | Output | +|--------|--------| +| CAExporter export | CA policy baseline JSON and human-readable summary | +| Per-user MFA state export | Accounts with per-user MFA enforced vs. disabled vs. not configured | +| Policy coverage matrix | Every policy: name, state (enabled/report-only/disabled), conditions, grant, exclusions, last modified, named owner | +| Gap analysis | Conditions with no coverage; duplicate coverage; exclusion lists with individual accounts | +| Sign-in log review | Authentication methods in use; legacy auth clients; CA policy results | +| Named locations inventory | Trusted IPs and named locations configured, if any | + +Deliver the audit findings to the named client lead before writing any policies. The coverage matrix should be readable without technical background — each row is one policy, each column answers one question. Include a plain-language summary: "You have 14 policies. Three are disabled and appear forgotten. Two overlap in ways that may create gaps. Five have no named owner and no documented purpose. Legacy authentication is not blocked at the CA level." + +--- + +### Step 2 — Design + +Before deploying anything, produce the complete policy set design on paper (or in a document). Every policy defined, every exclusion justified, every interaction between policies mapped. Review with the named client lead before deployment begins. + +The policy set is designed in three layers. Deploy them in order. + +**Layer 1 — Identity controls (no device dependency)** +These work immediately, without Intune or any device management. Deploy first. + +**Layer 2 — Admin controls (elevated requirements for privileged roles)** +Stricter controls applied specifically to accounts holding privileged roles. Deploy after Layer 1 is stable. + +**Layer 3 — Device and session controls (Intune dependency)** +Require device compliance as a CA signal. Deploy only when Intune compliance policies are active and returning results. Design these policies now; activate them when the Intune assignment is complete. + +--- + +### Step 3 — Deploy Layer 1 (staged) + +Each policy follows the same deployment sequence: +1. Create policy in **report-only** mode +2. Wait 48–72 hours; review sign-in logs for the policy's report-only results +3. Identify any legitimate traffic that would be blocked; create exclusion groups or refine conditions +4. Switch to **enabled** +5. Monitor sign-in logs for 24 hours +6. Only then move to the next policy + +Do not deploy multiple policies simultaneously. Each policy change has independent blast radius; sequential deployment makes causality clear when something breaks. + +**Legacy authentication block first.** This is the one control that cannot afford to be partially deployed. If legacy auth is blocked via CA but not via Entra authentication policies, a policy gap in CA can allow legacy auth through. Confirm after deployment that the sign-in log shows zero legacy auth sign-ins. Zero is the only acceptable result. + +**Per-user MFA resolution.** After CA-enforced MFA is active for all users, disable per-user MFA for all accounts except break-glass. Leaving both active creates a split control plane. The CA policy is the authoritative control; per-user MFA is the legacy mechanism. They should not coexist once CA is stable. + +--- + +## The Baseline Policy Set + +This is the policy set to deploy on every engagement. Adapt scope and exclusions to the client's environment; do not adapt the design principles. + +**Naming convention:** +`CA-[Audience]-[Condition or Trigger]-[Grant or Block]` + +Examples: `CA-AllUsers-LegacyAuth-Block`, `CA-Admins-AllApps-RequirePhishingResistantMFA` + +Consistent naming is not aesthetic preference — it is the difference between a policy set that can be maintained and one that accumulates technical debt. + +**Exclusion groups:** +All exclusions use Entra ID security groups, never individual accounts (except break-glass, which is excluded by account). Group membership is reviewed as part of the leave-behind. A group named `CA-Exclusion-BreakGlass` is named and owned; an individual account exclusion is invisible in aggregate policy review. + +--- + +### Layer 1 — Identity Controls + +| Policy | Conditions | Grant / Block | Notes | +|--------|-----------|---------------|-------| +| `CA-AllUsers-LegacyAuth-Block` | All users / All cloud apps / Legacy auth clients (Exchange ActiveSync + Other clients) | Block | Deploy first. Confirm zero legacy auth in sign-in logs post-enforce. | +| `CA-AllUsers-AllApps-RequireMFA` | All users / All cloud apps / All platforms / Exclude break-glass group | Require MFA | Core enforcement. Deploy second. Resolve per-user MFA conflict after this is stable. | +| `CA-GuestUsers-AllApps-RequireMFA` | Guest and external users / All cloud apps | Require MFA | Separate policy: guests often require different exclusion handling. | + +**E3 stops here for identity-layer controls.** Risk-based policies (sign-in risk, user risk) require Entra ID P2. If the client has P2 licensing, add: + +| Policy | Conditions | Grant / Block | Notes | +|--------|-----------|---------------|-------| +| `CA-AllUsers-HighUserRisk-RequirePasswordChange` | All users / High user risk | Require MFA + password change | P2 required. Requires Identity Protection enabled. | +| `CA-AllUsers-MedHighSignInRisk-RequireMFA` | All users / Medium and High sign-in risk | Require MFA | P2 required. Step-up for risky sign-ins. | + +--- + +### Layer 2 — Admin Controls + +| Policy | Conditions | Grant / Block | Notes | +|--------|-----------|---------------|-------| +| `CA-Admins-AllApps-RequirePhishingResistantMFA` | Directory roles (Global Admin, Privileged Role Admin, Security Admin, Exchange Admin, SharePoint Admin, User Admin, Conditional Access Admin, Application Admin) / All cloud apps | Require authentication strength: Phishing-resistant MFA | Phishing-resistant = FIDO2 security key, Windows Hello for Business, or certificate-based auth. Requires auth strength configured in Entra. Standard Authenticator push is not phishing-resistant. | +| `CA-Admins-AllApps-RequireCompliantOrHybridDevice` | Same role scope / All cloud apps | Require compliant device OR hybrid Azure AD joined | Layer 3 control applied early to admins specifically. Activate this even before broad device compliance enforcement if Intune covers admin workstations. | + +**Why admins get a separate, stricter policy set:** Admin credentials are the highest-value target in the tenant. An attacker who can bypass MFA on an admin account owns the tenant. Standard Authenticator push MFA is bypassed by MFA fatigue attacks (request flooding until the user approves). Phishing-resistant MFA is not. The separation in the policy set makes it explicit that admin accounts have a different requirement — and makes it auditable. + +--- + +### Layer 3 — Device Controls (activate when Intune is ready) + +Design these policies now. Activate them after [Assignment: Intune Security Baseline](assignment-intune-security-baseline.md) is complete and device compliance results are stable. + +| Policy | Conditions | Grant / Block | Notes | +|--------|-----------|---------------|-------| +| `CA-AllUsers-AllApps-RequireCompliantDevice` | All users / All cloud apps / All platforms | Require compliant device OR require MFA | Start with OR (compliant device OR MFA) — gives unmanaged-device users a path via MFA. Once enrollment is high enough, switch to AND or compliant-only. | +| `CA-AllUsers-SensitiveApps-RequireCompliantDevice` | All users / Exchange Online + SharePoint Online / All platforms | Require compliant device | Strict. Apply to sensitive apps first before all apps. | +| `CA-AllUsers-UnmanagedDevice-AppEnforcedRestrictions` | All users / Exchange Online + SharePoint Online / Any platform / Filter: not compliant, not hybrid-joined | Session: app-enforced restrictions (use limited web access) | Limits download and sync on unmanaged devices accessing mail and documents. Requires Exchange Online and SharePoint to be configured for app-enforced restrictions. E3-compatible. | + +The `CA-AllUsers-UnmanagedDevice-AppEnforcedRestrictions` policy is the most immediately valuable Layer 3 control for E3 clients without full Intune enrollment — it degrades access rather than blocks it, which is easier to deploy without user disruption. + +--- + +### Named Locations (supporting the policy set) + +Configure named locations before deploying any location-based policies. + +| Location | Purpose | +|----------|---------| +| **Trusted corporate networks** | Office IP ranges. Used to relax MFA requirements on trusted networks if the client explicitly requests it. Default recommendation: do not relax MFA on any network — trusted location is less durable than device compliance. | +| **High-risk countries** (optional) | Countries from which the client has no operations and no expected sign-ins. Can be used to block access or require MFA as a step-up. Use carefully: VPN exit nodes and mobile roaming will trigger this. Document the decision. | + +Named locations are often requested but rarely worth the operational overhead unless the client has a specific use case (blocking sign-ins from a defined list of countries, or relaxing physical office controls). Include in the design document; deploy only if the client has a clear requirement. + +--- + +## Structural Resilience Checklist + +Controls that hold without ongoing human willingness after this engagement closes. + +- [ ] `CA-AllUsers-LegacyAuth-Block` is **enabled** — not report-only — and sign-in logs confirm zero legacy auth clients +- [ ] `CA-AllUsers-AllApps-RequireMFA` is **enabled** and covers all users including guests (separate guest policy) +- [ ] `CA-Admins-AllApps-RequirePhishingResistantMFA` is **enabled** and authentication strength is configured +- [ ] Per-user MFA has been disabled for all accounts after CA-enforced MFA is stable (except break-glass) +- [ ] All exclusions use named Entra ID groups — no individual account exclusions except break-glass +- [ ] Every policy has a documented name, intent, owner, and date of last review +- [ ] CAExporter export (before and after) stored in client documentation +- [ ] Layer 3 policies exist in **report-only** mode, ready for activation when Intune is complete + +--- + +## Kill Chain Contribution + +**What this assignment closes:** + +| Attack vector | Control deployed | +|---------------|-----------------| +| Password spray with no MFA prompt | `CA-AllUsers-AllApps-RequireMFA` | +| MFA fatigue attack against admin accounts (push flooding) | `CA-Admins-AllApps-RequirePhishingResistantMFA` | +| Legacy protocol abuse (SMTP AUTH, IMAP, Basic Auth REST) | `CA-AllUsers-LegacyAuth-Block` | +| Credential stuffing from breached credential lists | MFA enforcement | +| Guest account lateral movement through weakly controlled external access | `CA-GuestUsers-AllApps-RequireMFA` | +| Unmanaged device access to sensitive apps (if Layer 3 activated) | `CA-AllUsers-UnmanagedDevice-AppEnforcedRestrictions` | + +**What this assignment does not close:** + +| Remaining gap | Addressed by | +|---------------|-------------| +| Adversary-in-the-middle / session token theft post-MFA | Device compliance in CA + Entra token protection (P2) | +| Unmanaged device as unrestricted access vector | [Assignment: Intune Security Baseline](assignment-intune-security-baseline.md) + Layer 3 activation | +| Standing admin privilege (long-lived sessions, no JIT) | Privileged access engagement (PIM) | +| Sign-in risk and impossible travel detection | Entra ID P2 Layer 1 additions | +| App permission abuse (OAuth consent phishing) | Service identity engagement | + +The residual gap the client is most likely to feel: a stolen session token (from phishing with AiTM proxy) bypasses MFA because it captures the token after MFA completes. This is the next-generation phishing technique. Mitigating it requires token binding to device compliance — a Layer 3 control — plus Entra token protection (P2 feature). Document this in the residual risk statement. + +--- + +## Leave-Behind Package + +| Artifact | Description | +|----------|-------------| +| **CAExporter JSON (before)** | CA policy state at engagement start | +| **CAExporter JSON (after)** | CA policy state at engagement close | +| **Policy design document** | Every deployed policy: name, intent, conditions, grant/block, exclusion groups, owner, date enabled | +| **Policy coverage matrix** | Human-readable: which users are covered by which policies, which apps, which platforms | +| **Per-user MFA resolution record** | Confirmation that per-user MFA has been disabled post-CA deployment | +| **Layer 3 design document** | Device compliance policies designed but not yet activated; activation prerequisites and checklist | +| **Exclusion group inventory** | Every CA exclusion group: name, members, review cadence | +| **Sign-in log confirmation** | Legacy auth: zero clients post-block. MFA: applied to >99% of sign-ins. | +| **Named locations documentation** | Any configured named locations with business justification | +| **Scope boundary log** | Every finding outside this scope, named and prioritized | +| **Residual risk statement** | What this assignment did not close, specifically including AiTM/token theft risk | + +The Layer 3 design document is the explicit handoff to the Intune assignment. A CISO reading the leave-behind package can see exactly what was built, why, what it prevents, and what comes next — without needing to ask. + +--- + +## Scope Boundary Signals + +| Signal | Points toward | +|--------|--------------| +| No Intune enrollment or compliance policies active | Intune Security Baseline assignment — activate Layer 3 after | +| Global Admins have no phishing-resistant MFA method registered | Auth method enrollment drive; may need hardware key procurement | +| Entra ID P2 not licensed; client has credential-stuffing exposure | Licensing recommendation: P2 for Identity Protection (cheaper than full E5) | +| App registrations with broad Graph permissions visible in sign-in logs | Service identity engagement | +| Service accounts authenticating with CA policies applied | Service account remediation — service accounts should use managed identities or workload identity federation, not user-like credential flows through CA | +| Defender for Cloud Apps not licensed; session control requests needed | MDCA engagement for full session control | +| Sign-in logs show access from unexpected geographies | Named location policy review; may warrant country block | +| Audit log retention < 90 days | Detection baseline assignment | + +--- + +## Buildable-On: What the Next Assignment Depends On + +The Intune Security Baseline assignment builds directly on the CA architecture deployed here. Specifically, it depends on: + +1. **`CA-AllUsers-AllApps-RequireCompliantDevice` exists in report-only mode.** The Intune assignment activates this policy as its final step — the point where device compliance becomes an access control, not just a reporting tool. +2. **CA exclusion groups are using the right naming convention.** Device compliance policies deployed in Intune reference the same user groups used in CA. Consistent group naming prevents the Intune assignment from having to clean up CA policy exclusions mid-deployment. +3. **Sign-in logs show MFA is enforced.** The Intune assignment cannot safely activate device-compliance CA policies if MFA enforcement is incomplete — an unmanaged device could otherwise use the compliance check as a bypass path. + +If all three conditions are true at handover, the Intune assignment can activate Layer 3 without revisiting the CA work. If any condition is false, the scope boundary log documents what needs to be resolved first. + +--- + +*For the identity foundation this builds on, see [Assignment: Identity Baseline](assignment-identity-baseline.md).* +*For the device compliance integration that activates Layer 3, see [Assignment: Intune Security Baseline](assignment-intune-security-baseline.md).* +*For the technical depth on privileged access architecture that informs admin CA requirements, see [Book III — Privileged Access](../books/02-privileged-access.md).* diff --git a/antifragile-consulting/playbooks/assignment-collaboration-security.md b/antifragile-consulting/playbooks/assignment-collaboration-security.md new file mode 100644 index 0000000..82e2088 --- /dev/null +++ b/antifragile-consulting/playbooks/assignment-collaboration-security.md @@ -0,0 +1,443 @@ +# Assignment: Collaboration and Data Security + +> *Data is liquid. It leaves where you put it — copied, shared, forwarded, synced, linked. The question is never "is it locked down" but "where can it flow, who can reshare it, and can you see and reverse the flow?"* + +This is a **scoped assignment package** and the fourth in the M365 security sequence. It addresses the data and collaboration layer: how corporate data moves, where it leaks, and what structural controls reduce the blast radius when it does. It can be delivered standalone, but the device and identity controls from the preceding assignments are assumed in the residual risk analysis. + +This assignment completes the **"Secure M365"** engagement when delivered after Identity Baseline, CA Architecture, and Intune Security Baseline. + +--- + +## The Brief + +Client requests that fall within this scope: + +- *"Secure our M365 / harden our Exchange and SharePoint"* +- *"We're worried about data leaking through email or shared links"* +- *"We got a phishing email and want to prevent it"* +- *"Our auditor wants to see DLP controls"* +- *"We need email authentication — DMARC / DKIM / SPF"* +- *"We need to know what's being shared externally"* +- *"Set up sensitivity labels"* + +This assignment does not require executive sponsorship. It requires one named IT lead with Global Administrator and Exchange Administrator access, tolerance for discovering that external sharing is significantly wider than assumed, and willingness to remove sharing types that users may push back on. + +--- + +## Scope Boundary + +**In scope:** +- External sharing exposure mapping ("Anyone" links, external guests, external shares) +- Removal of anonymous sharing and external auto-forwarding +- Exchange Online Protection (EOP) hardening: anti-phishing, anti-malware, anti-spam +- Email authentication: SPF verification, DKIM enablement, DMARC deployment +- SharePoint and OneDrive tenant-level sharing governance +- Guest access governance: expiration, review cadence +- Sensitivity label taxonomy and deployment (foundation: 3–4 labels) +- DLP baseline: 3–5 known high-value patterns for Exchange, SharePoint, OneDrive +- Audit logging verification and configuration +- App consent governance: restrict user consent, enable admin consent workflow + +**Out of scope:** +- Comprehensive data classification programme → separate Purview engagement +- Defender for Office 365 P1/P2 advanced configuration (Safe Links, Safe Attachments, Attack Simulation) → E5 or add-on engagement +- Microsoft Defender for Cloud Apps session controls → MDCA engagement +- Retention policies and data lifecycle governance → separate Purview engagement +- On-premises Exchange decommissioning → separate hybrid engagement +- Cross-tenant access configuration (B2B direct connect) → out of scope unless specifically requested +- Entitlement management and full guest lifecycle (P2 feature) → out of scope for E3 + +When the client asks for comprehensive DLP — covering all data types across all services — scope it as a separate engagement. A DLP programme that attempts to cover everything produces alert fatigue that degrades the protection for the things that actually matter. + +--- + +## Before You Touch Anything + +**1. Crown jewels question.** +Before configuring any control, ask the named client lead one question: *"Which three data sets, if leaked, would cause the most harm to the organisation — regulatory, competitive, or reputational?"* + +If they cannot answer, that inability is finding #1. You cannot apply protection asymmetrically until you know what the asymmetry is for. Sensitivity labels, DLP policies, and restricted-site configurations all depend on this answer. If the organisation genuinely cannot identify its crown jewels, document it and apply the default framework (financial data, HR data, and strategic/M&A communications) as a starting point. + +**2. Surface map.** +Before making any changes, enumerate the actual external exposure. The findings are almost always worse than the client assumes — and the enumeration itself, shared with the client lead, is often the moment that creates willingness for the removal steps that follow. + +Run these reports before touching configuration: + +| Report | Tool / Location | +|--------|----------------| +| "Anyone" (anonymous) links | SharePoint admin center → Reports → Sharing → or Graph API | +| External shares (authenticated guest links) | SharePoint admin center → Sharing report | +| Guest users with last sign-in date | Entra ID → External Identities → All users (filter: Guest) | +| External auto-forwarding rules | Exchange admin center → Mail flow → Rules; or PowerShell: `Get-TransportRule` filtered for external redirect | +| User-consented OAuth app grants | Entra ID → Enterprise applications → filter: User consent | +| SPF, DKIM, DMARC status | MXToolbox or PowerShell DNS lookup per domain | +| Unified Audit Log status | Compliance portal → Audit → or `Get-AdminAuditLogConfig` | + +Deliver the surface map to the named client lead before proceeding to any removal steps. State the findings plainly: "You have 847 anonymous sharing links. Fourteen mailboxes have active external forwarding rules. You have 312 guest accounts, 189 of whom have not signed in within 90 days. DMARC is not configured. Your Unified Audit Log has not been enabled." + +These are facts, not accusations. The client lead needs to see the actual exposure before approving the removal steps. + +--- + +## Principles Applied + +**Remove first, then govern.** +The highest-impact actions in this assignment are removals: anonymous links, external auto-forwarding, over-permissioned OAuth grants. These are not governance gaps — they are open doors. No amount of sensitivity labelling or DLP configuration compensates for an anonymous sharing link that routes around every identity control built in the preceding three assignments. Subtraction comes first. + +**Name the crown jewels before you protect them.** +Even-spreading protection across all data is the concave failure: enormous maintenance cost, false positive noise that trains users to click through warnings, and the real exfiltration lost in the background. Sensitivity labels and DLP policies are applied to the crown jewels and known high-value patterns — not to everything. Three well-targeted DLP policies that fire reliably are worth more than thirty policies that nobody trusts. + +**Visibility before governance.** +The surface map is the most valuable deliverable in this assignment. An organisation that has never seen its "Anyone" link count, its guest list with last sign-in dates, or its auto-forward rule inventory cannot govern what it has. The surface map creates visibility; governance follows from it. + +**Protection must travel with the data.** +A sensitivity label with encryption is the only control that survives data leaving the tenant. Container controls — SharePoint permissions, CA policies, device compliance — stop working the moment the file is downloaded and forwarded. For the crown jewels, the protection must be bound to the file itself. Everything else is a gate on the way out, not a lock on the data. + +--- + +## Delivery Architecture + +### Step 1 — Surface Map (no changes) + +*Described above in "Before You Touch Anything." Complete and deliver before proceeding.* + +The surface map has a second purpose beyond informing the work: it is the before-state that makes the leave-behind measurable. "You had 847 anonymous links; you now have 0" is a concrete, auditable risk-reduction statement. + +--- + +### Step 2 — Remove the Dangerous Paths + +These actions have the highest impact per unit of effort in the entire assignment. They should be completed before any additive control is deployed. + +**Kill anonymous "Anyone" links.** + +Set the tenant-level sharing policy to prohibit new "Anyone" links: +- SharePoint admin center → Policies → Sharing +- External sharing: set to **New and existing guests** (requires authentication) — not "Anyone" +- This stops new anonymous links from being created. It does not revoke existing links. + +Existing anonymous links must be revoked separately. Use the SharePoint Sharing Report or a Graph API query to enumerate them, then decide with the client lead: bulk revoke all, or review and selectively revoke. Bulk revoke is correct for any link created more than 90 days ago with no documented business justification. Document the decision and the revocation count. + +**Block external auto-forwarding.** + +External auto-forwarding rules are the most reliable mailbox-compromise exfiltration technique. They should not exist. + +- Exchange admin center → Mail flow → Remote domains → Default domain → Uncheck "Allow automatic forwarding" +- Or via the outbound anti-spam policy: set automatic forwarding to **Off** +- After disabling, audit existing rules: `Get-TransportRule | Where-Object { $_.RedirectMessageTo -like "*@*" }` and `Get-Mailbox -ResultSize Unlimited | Get-InboxRule | Where-Object { $_.ForwardTo -or $_.RedirectTo -like "*@*" }` + +Any active external forwarding rule found during the audit is a potential incident indicator. Treat each one as suspicious until confirmed legitimate by the mailbox owner and the named client lead. Document the outcome for each. + +**Restrict user OAuth consent.** + +Users should not be able to grant arbitrary third-party applications access to tenant data. + +- Entra ID → Enterprise applications → Consent and permissions → User consent settings +- Set to: **Allow user consent for apps from verified publishers, for selected permissions (classified as low impact)** — or **Do not allow user consent** (more restrictive; requires admin approval workflow to compensate) +- Enable the **Admin consent workflow**: users can submit a request; named admins receive and review it + +Review existing user-consented grants. Flag any app with permissions in these categories: +- `Mail.Read`, `Mail.ReadWrite`, `Mail.Send` — reads or sends all mail +- `Files.ReadWrite.All`, `Sites.Read.All` — accesses all files and sites +- `User.Read.All`, `Directory.Read.All` — reads full directory + +High-permission user-consented grants should be reviewed with the named client lead and revoked where the app is not recognised, not actively used, or not from a verified publisher. Revoke through Entra ID → Enterprise applications → [App] → Permissions → Revoke user consent. + +--- + +### Step 3 — Exchange Online Protection Baseline + +EOP is included in E3 and M365 Business Premium. It handles anti-phishing, anti-malware, and anti-spam for Exchange Online. Default EOP configuration is functional but not optimal. + +**Email authentication (SPF, DKIM, DMARC):** + +| Protocol | What it does | Configuration | +|----------|-------------|---------------| +| **SPF** | Declares which servers may send email as your domain | DNS TXT record — verify it exists and is not over-broad (`+all` invalidates it) | +| **DKIM** | Cryptographically signs outbound email | Enable in Exchange admin center → Email authentication → DKIM → Enable for each domain. Key rotation is handled automatically. | +| **DMARC** | Specifies how receiving servers handle SPF/DKIM failures | DNS TXT record. Deploy in stages: `p=none` (monitoring) → verify no legitimate mail fails → `p=quarantine` → eventually `p=reject`. Minimum target for this assignment: `p=quarantine` after 30-day monitoring period shows no legitimate mail failing. | + +Without DMARC, your domain can be spoofed in inbound email to your users and in outbound email to others. SPF and DKIM without DMARC do not enforce — DMARC is the enforcement record. + +**Anti-phishing policy (EOP):** + +- Exchange admin center → Policies & rules → Threat policies → Anti-phishing +- Enable impersonation protection for: the organisation's own domain(s), key users (CEO, CFO, board members, finance team) +- Enable mailbox intelligence (learning sender patterns) +- Set action for impersonation detections: **Quarantine** (not move to Junk — quarantine is reviewed; Junk is ignored) + +If the client has Defender for Office 365 P1 (included in M365 Business Premium or as an add-on): enable Safe Links and Safe Attachments. These are materially more effective than EOP baseline anti-phishing. Note the gap if E3 without the add-on. + +**Anti-malware policy:** + +- Threat policies → Anti-malware +- Enable common attachment filter: block executable file types (.exe, .vbs, .js, .ps1, .bat, .cmd and others) +- Zero-hour auto purge (ZAP): ensure it is enabled — retroactively quarantines malware found after delivery +- Admin notifications: notify security team on malware detection + +**Anti-spam policy:** + +- Threat policies → Anti-spam +- Bulk complaint level threshold: set to 6 (aggressive; default is 7) +- Enable outbound spam notifications: alert the security team when a mailbox is detected sending spam (indicator of compromise) +- Verify SPF hard fail is evaluated + +--- + +### Step 4 — Sharing Governance + +Sharing governance operates at multiple levels in M365. The tenant setting is the ceiling — per-site can be more restrictive but never more permissive than the tenant setting. + +**Tenant-level settings (SharePoint admin center → Policies → Sharing):** + +| Setting | Target value | Notes | +|---------|-------------|-------| +| External sharing — SharePoint | New and existing guests | Requires guest authentication. "Anyone" was removed in Step 2. | +| External sharing — OneDrive | New and existing guests | Match SharePoint setting or more restrictive. | +| Require guests to sign in using the same account | Yes | Prevents link forwarding to a different account. | +| Allow guests to share items they don't own | No | Prevents reshare chain from escaping first-hop control. | +| Guest access expiration | 30 days (or per organisation policy) | Guests must be reviewed and re-invited; standing access expires. | +| Link permissions default | View | Least privilege; users explicitly upgrade if edit is needed. | +| Link expiry (new and existing guest links) | 30 days | Prevents permanent link accumulation. | + +**Per-site controls — crown jewel sites:** +For sites identified in the crown jewels question (Step 1 of "Before You Touch Anything"): +- Set external sharing to **Only people in your organization** +- Remove broad internal permissions ("Everyone except external users", "All company") +- Document the named owners of the site and the access review schedule + +Internal oversharing is often overlooked: a finance site accessible to "All company" means any compromised internal account reaches the financial data. Restrict sensitive sites to named groups with specific membership. + +--- + +### Step 5 — Guest Governance + +Guest accounts are standing external blast radius. Every guest that has not been reviewed is an unknown with access to unknown data. + +**Immediate actions:** + +1. **Export the guest list with last sign-in date.** In Entra ID → Users → filter by User type: Guest. Export to CSV. Sort by last sign-in date. +2. **Flag for removal:** guests who have not signed in within 90 days and have no active project sponsorship. Present the list to the named client lead for approval before removing. +3. **Remove approved stale guests.** Document the count. + +**Ongoing governance (configure before handover):** + +| Control | Configuration | +|---------|--------------| +| Guest invitation restrictions | Restrict to Entra ID admins only (not all users can invite guests) | +| Guest access expiration | Configure in Entra ID → External Identities → External collaboration settings: Guest user access expires after 180 days unless reviewed | +| Access reviews | Entra ID → Identity Governance → Access reviews — create a quarterly review for all guests. Reviewer: IT lead or line-of-business owner. Action on no response: remove access. | + +Access reviews require Entra ID P2 for full automation. For E3, a manual quarterly review using the Entra guest export is the alternative — document the cadence in the leave-behind and assign an owner. + +--- + +### Step 6 — Sensitivity Labels Foundation + +Sensitivity labels are the mechanism that makes protection travel with the data. A labelled document carries its permissions wherever it goes — downloaded, emailed, shared externally. + +**Label taxonomy — baseline (4 labels):** + +| Label | Meaning | Default protection | +|-------|---------|-------------------| +| **Public** | Intended for external distribution | No restrictions | +| **Internal** | Default for internal business content | No external sharing by default | +| **Confidential** | Business-sensitive; restricted distribution | Encrypt; restrict to organisation members; no external forwarding | +| **Highly Confidential** | Crown jewels: financial, legal, M&A, HR | Encrypt; restrict to named group; no download on unmanaged device; watermark | + +Keep the taxonomy to four labels. More labels increase classification fatigue and reduce the percentage of content that gets labelled at all. A four-label taxonomy that users understand and apply is worth more than a twelve-label taxonomy that nobody uses. + +**Deployment:** + +1. Create labels in Microsoft Purview compliance portal → Information protection → Labels +2. Publish labels to all users via a label policy +3. Configure auto-labelling for the Highly Confidential label: define content patterns (e.g., project name, internal designation) that trigger auto-labelling in SharePoint and OneDrive +4. Set the default label for SharePoint sites identified as crown jewel sites: Confidential + +**For Highly Confidential — encryption configuration:** +- Rights Management encryption: Only organisation members can open; no external forwarding; no printing +- Apply to: the named crown-jewel sites and document libraries + +The label is the escape hatch. A Highly Confidential document downloaded to an unmanaged device and forwarded externally is still encrypted — the attacker has ciphertext, not data. This is the only control in this assignment that holds after data leaves the tenant. + +--- + +### Step 7 — DLP Baseline + +DLP policies intercept known sensitive information patterns transiting Exchange, SharePoint, and OneDrive. Deploy DLP as a scalpel: 3–5 specific, high-confidence patterns. Do not attempt comprehensive coverage. + +**Target patterns for most organisations:** + +| Policy | Pattern | Initial action | +|--------|---------|---------------| +| Payment card data | Credit card numbers (PCI scope) | Policy tip to user + admin alert | +| National identity numbers | National ID / tax number format for the client's jurisdiction | Policy tip to user | +| Crown jewel content | Sensitivity label: Highly Confidential (label-based DLP) | Block external sharing + admin alert | +| External forwarding with attachments | Email to external recipients with attachments > threshold | Notify user | + +Start every DLP policy in **simulation mode** (test/audit) before enforcement. Review DLP activity reports after 48 hours of simulation. Identify false positives. Tune the policy. Then enable with **notify only** before moving to **block**. + +The sequence: simulation → notify → block. Never skip the simulation and notify stages. + +**What E3 DLP covers:** Exchange Online, SharePoint Online, OneDrive for Business. It does not cover Teams messages (requires Purview add-on) or endpoint DLP (requires Purview or E5 compliance). + +Note the gaps in the residual risk statement: DLP at this scope does not cover Teams conversations or files shared through channels. If Teams is a primary working environment for crown-jewel content, document this as a gap pointing toward a Purview engagement. + +--- + +### Step 8 — Audit Logging + +Audit logging is the foundation of any post-incident forensics capability. If it is not enabled, every breach investigation starts with nothing. + +**Unified Audit Log:** + +```powershell +# Verify status +Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled + +# Enable if false +Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true +``` + +E3 default retention: 90 days. Verify actual retention in the Compliance portal → Audit. If the client has regulatory requirements for longer retention (NIS2, DORA, banking regulations typically require 1 year minimum), document the gap. The E3 upgrade path is the Audit (Premium) add-on or E5 compliance. + +**Mailbox audit logging:** + +```powershell +Get-Mailbox -ResultSize Unlimited | + Where-Object {$_.AuditEnabled -eq $false} | + Set-Mailbox -AuditEnabled $true +``` + +Verify that key mailbox audit operations are captured: MailboxLogin, SendAs, SendOnBehalf, HardDelete, FolderBind. + +**Critical audit events to verify are captured:** + +| Event category | Why it matters | +|---------------|---------------| +| File and page activities | Accessed, downloaded, shared — the data exfiltration footprint | +| Sharing and access request activities | External shares created; guest invitations sent | +| Synchronization activities | Files synced to devices (OneDrive sync client) | +| Exchange admin activities | Transport rule creation/modification; external forwarding | +| Azure AD sign-in events | Anomalous sign-ins, MFA failures, conditional access decisions | +| DLP rule matches | Evidence that DLP policies are firing | + +--- + +## Structural Resilience Checklist + +Controls that hold without ongoing human willingness after this engagement closes. + +- [ ] Anonymous sharing blocked at tenant level — confirmed by SharePoint sharing settings +- [ ] Existing anonymous links revoked — count documented +- [ ] External auto-forwarding blocked at tenant level — confirmed by transport rule and outbound spam policy +- [ ] Active external forwarding rules reviewed and removed +- [ ] DKIM enabled for all domains +- [ ] DMARC deployed at minimum `p=quarantine` after monitoring period +- [ ] User OAuth consent restricted — admin consent workflow active +- [ ] High-permission user-consented OAuth grants reviewed +- [ ] Guest expiration configured — new guests expire by default +- [ ] Stale guests removed (90+ days inactive, no active sponsorship) +- [ ] Guest access review cadence documented with named owner +- [ ] Sensitivity labels published to all users — Highly Confidential label with encryption +- [ ] DLP baseline policies active (post-simulation and notify stages) — not in simulation only +- [ ] Unified Audit Log enabled +- [ ] Mailbox audit logging enabled for all mailboxes + +--- + +## Kill Chain Contribution + +**What this assignment closes:** + +| Attack vector | Control deployed | +|---------------|-----------------| +| Data exfiltration via anonymous link (bypasses all identity controls) | Anonymous link prohibition + existing link revocation | +| Business email compromise via mailbox forwarding rule | External auto-forwarding block + rule audit | +| OAuth consent phishing (malicious app requesting mail/file access) | User consent restriction + high-permission grant review | +| Domain spoofing (impersonation of the client's domain in email) | DMARC `p=quarantine` | +| Phishing email impersonating known users or domain | Anti-phishing impersonation protection | +| Crown-jewel document leaking outside the tenant | Sensitivity label encryption (Highly Confidential) — protection travels with file | +| Known sensitive data patterns transiting email or SharePoint | DLP baseline policies | +| Stale guest accounts as standing external foothold | Guest expiration + stale guest removal | + +**What this assignment does not close:** + +| Remaining gap | Addressed by | +|---------------|-------------| +| Advanced phishing: Safe Links, Safe Attachments | Defender for Office 365 P1 (E5 or add-on) | +| Teams message DLP | Purview compliance add-on | +| Endpoint DLP (data leaving via USB, local app) | Purview E5 compliance or endpoint DLP engagement | +| Full data lifecycle governance (retention, disposal) | Purview engagement | +| MDCA session controls (block download from browser on unmanaged device) | MDCA engagement | +| Full guest lifecycle management (access packages, entitlement) | Entra ID Governance (P2) engagement | +| Residual data on unmanaged/BYOD devices | App Protection Policies (Intune assignment) | + +--- + +## Leave-Behind Package + +| Artifact | Description | +|----------|-------------| +| **Surface map report** | Before-state: "Anyone" link count, external shares, guest list with last sign-in, forwarding rules found, OAuth grant inventory, SPF/DKIM/DMARC status | +| **Anonymous link revocation record** | Links revoked: count, method, date | +| **External forwarding rule audit** | Rules found, disposition of each (removed / confirmed legitimate / flagged as suspicious) | +| **OAuth grant review record** | Grants reviewed, grants revoked, grants retained with justification | +| **EOP policy documentation** | Anti-phishing, anti-malware, anti-spam settings with rationale | +| **DMARC monitoring report** | DMARC aggregate reports at `p=none` before moving to `p=quarantine`; confirmation of quarantine deployment | +| **Sharing governance configuration** | Tenant sharing settings, crown-jewel site configurations | +| **Guest governance documentation** | Expiration settings, access review configuration, stale guest removal count, review cadence with named owner | +| **Sensitivity label documentation** | Label taxonomy, label policy, encryption configuration for Highly Confidential | +| **DLP policy documentation** | Each policy: target pattern, scope, actions, simulation results before enforcement | +| **Audit logging confirmation** | Unified Audit Log status, retention period, mailbox audit status | +| **Scope boundary log** | Every finding outside this scope, named and prioritized | +| **Residual risk statement** | What this assignment did not close: Teams DLP gap, endpoint exfil path, advanced phishing gap, guest lifecycle limitations | + +--- + +## Scope Boundary Signals + +| Signal | Points toward | +|--------|--------------| +| Significant Teams usage for crown-jewel content; Teams DLP not covered | Purview compliance engagement | +| No independent M365 backup — Microsoft recycle bin only | Recovery and detection engagement (Book VI) | +| Audit log retention < regulatory requirement | Audit (Premium) add-on; or compliance-driven M365 upgrade | +| On-premises Exchange still in the estate | Hybrid Exchange engagement — decommissioning path | +| Advanced phishing; no Defender for Office 365 P1 | E5 / MDO add-on evaluation | +| High volume of user-consented high-permission OAuth apps | Entitlement management engagement | +| Crown-jewel data accessible to broad internal groups | Information architecture engagement (governance, IA, Purview classification) | +| No independent M365 backup | Recovery and detection engagement | +| No incident response plan | IR planning engagement | + +--- + +## Completing the "Secure M365" Engagement + +When all four assignments are delivered, the client has: + +**Identity Baseline** — MFA enforced for all users and phishing-resistant MFA for admins. Legacy authentication blocked at the tenant level. Break-glass accounts established and monitored. Admin accounts separated and audited. + +**CA Architecture** — A named, documented, principled CA policy set. Layer 1 (identity) and Layer 2 (admin elevation) enforced. Layer 3 (device compliance) activated following the Intune assignment. Per-user MFA conflict resolved. + +**Intune Security Baseline** — Device compliance policies returning results for the enrolled fleet. Compliant device required for M365 access (CA Layer 3 active). BitLocker, patch compliance, and LAPS deployed. Update rings with canary. App Protection Policies for BYOD. The real device population is mapped and documented. + +**Collaboration and Data Security** — Anonymous links removed. External auto-forwarding blocked. Email authentication at DMARC quarantine. External sharing governed. Stale guests removed. Sensitivity labels deployed with crown-jewel encryption. DLP baseline active for known high-value patterns. Audit logging enabled. + +**What this engagement does not close** — and what the CISO has in writing: +- Session token theft (AiTM phishing) → Entra ID P2 + token protection +- EDR and post-compromise detection → Defender for Endpoint P2 or Wazuh augmentation +- Standing privilege → PIM / PAM engagement +- Active Directory on-premises hardening → hybrid identity and AD hardening engagement +- Full data governance → Purview engagement +- Backup and recovery → recovery and detection engagement +- Incident response capability → IR planning and detection baseline engagement + +The residual risk statement across all four packages is the honest description of what has been built and what remains. It is not a sales document — it is the record that the client's security posture was improved deliberately, with full awareness of what was and was not in scope. + +--- + +*For the identity foundation, see [Assignment: Identity Baseline](assignment-identity-baseline.md).* +*For the CA architecture, see [Assignment: CA Architecture](assignment-ca-architecture.md).* +*For the device security baseline, see [Assignment: Intune Security Baseline](assignment-intune-security-baseline.md).* +*For the data and collaboration philosophy, see [Book V — Data & Collaboration](../books/04-data-and-collaboration.md).* +*For the recovery and detection layer this engagement exposes as the next priority, see [Book VI — Recovery & Detection](../books/05-recovery-and-detection.md).* diff --git a/antifragile-consulting/playbooks/assignment-identity-baseline.md b/antifragile-consulting/playbooks/assignment-identity-baseline.md new file mode 100644 index 0000000..3abba9c --- /dev/null +++ b/antifragile-consulting/playbooks/assignment-identity-baseline.md @@ -0,0 +1,222 @@ +# 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).* diff --git a/antifragile-consulting/playbooks/assignment-intune-security-baseline.md b/antifragile-consulting/playbooks/assignment-intune-security-baseline.md new file mode 100644 index 0000000..dbafb81 --- /dev/null +++ b/antifragile-consulting/playbooks/assignment-intune-security-baseline.md @@ -0,0 +1,384 @@ +# Assignment: Intune Security Baseline + +> *The device will be compromised. Compliant is not the same as secure, and the portal toggle is not the same as the device's behaviour. Build for the compromise, not against it.* + +This is a **scoped assignment package** — a complete, principled delivery guide for one specific client brief. It closes the device-layer gap and activates the CA Layer 3 policies designed in [Assignment: CA Architecture](assignment-ca-architecture.md). It can be delivered standalone, but its full structural value is realised when CA Layer 3 is activated at the end. + +--- + +## The Brief + +Client requests that fall within this scope: + +- *"Deliver a security baseline for our Intune-managed endpoints"* +- *"Set up Intune / we need device management"* +- *"We need compliant devices to be required for M365 access"* +- *"Our auditor wants evidence that devices are encrypted and patched"* +- *"We have Intune but nobody set up the security policies"* +- *"We're retiring SCCM and going cloud-native"* (if co-management migration is explicitly scoped) + +This assignment does not require executive sponsorship. It requires one named IT lead with Intune Administrator access, a tolerance for a grace-period before enforcement, and an understanding that the enrollment rate at the start is almost never what the CMDB says. + +--- + +## Scope Boundary + +**In scope:** +- Device population mapping (what is actually authenticating, vs. what is enrolled, vs. what the CMDB says) +- Compliance policies: Windows, macOS, iOS, Android — as applicable to the fleet +- Device configuration profiles: Windows security baseline settings +- Windows Update rings (quality and feature updates) +- Windows LAPS (local admin password management) +- App Protection Policies for BYOD iOS and Android (MAM without MDM) +- Enrollment review and gaps (not a new enrollment deployment unless scoped separately) +- CA Layer 3 activation: connecting compliance state to Conditional Access + +**Out of scope:** +- SCCM co-management migration → separate engagement (scope is complex and fleet-specific) +- Autopilot setup and Autopilot-based provisioning → separate deployment engagement +- EDR configuration: Defender for Endpoint advanced features, custom detection rules → separate or within E5 engagement +- WDAC / Smart App Control / application allowlisting → advanced application control engagement +- Driver and firmware update management → note as gap, recommend Windows Update for Business or third-party where Intune is insufficient +- GPO conflict resolution for hybrid-joined estates → flag; recommend cloud-native migration path +- Endpoint Privilege Management (JIT local admin elevation) → note as follow-on if standing local admin cannot be removed + +When the client asks about SCCM migration or Autopilot, scope it separately. Co-management is a legitimate transitional architecture but it adds complexity that deserves its own scoped engagement with its own completion criteria. + +--- + +## Before You Touch Anything + +**1. Break-glass exclusion.** +Confirm that break-glass accounts are excluded from all device-compliance CA policies. A flaky compliance signal must never lock out tenant recovery. If CA Layer 3 is not yet designed, this step ensures the door is open when it is deployed. + +**2. Four-population mapping.** +The CMDB is a claim. Authentication logs are facts. Before configuring compliance policies, build the real device picture from four sources: + +| Population | Source | +|-----------|--------| +| **Enrolled (MDM)** | Intune device list | +| **Registered (Entra)** | Entra ID → Devices → All devices | +| **Authenticating** | Entra sign-in logs (30 days), filtered by device detail | +| **CMDB** | Whatever the client has | + +Map the differences. Devices in sign-in logs but not in Intune are known-unmanaged — they reach data and you cannot apply compliance policies to them. Devices in the CMDB but not in sign-in logs may be retired equipment or offline devices that have never actually authenticated. The gap between enrolled and authenticating is the real finding, and it belongs in the leave-behind regardless of whether it is addressed in this engagement. + +**3. Existing Intune policy audit.** +If Intune has been configured before — even partially — audit what exists before touching anything. Duplicate compliance policies, conflicting configuration profiles, and orphaned enrollment restrictions are common. A client who says "Intune is set up" often has one compliance policy created in 2021, three enrollment profiles nobody recognises, and a Windows security baseline applied to a group that no longer exists. Export the current state. + +**4. CA Layer 3 status.** +Check whether `CA-AllUsers-AllApps-RequireCompliantDevice` exists in report-only mode from the CA Architecture assignment. If it does, this assignment ends by activating it. If it does not exist, design and deploy it in report-only mode as part of this assignment — but do not activate it until compliance coverage is proven. + +--- + +## Principles Applied + +**Compliance is a signal, not a checkbox.** +A device marked compliant in Intune carries a staleness window: compliance is evaluated on check-in cadence, not continuously. A device can fall out of compliance — lose encryption, miss patches, be rooted — and still hold a valid compliant token and access grant for hours. Design around this: the compliance requirement at CA is a meaningful control that raises the cost of attack, not a guarantee of device integrity. Document what it is and what it isn't. + +**Test on real devices, not portal configurations.** +A Conditional Access policy can show a perfectly correct configuration in the portal and enforce nothing. The same applies to compliance policies: a policy assigned to a group can appear active and produce no compliance results for enrolled devices whose group membership has drifted. And MAM/App Protection enforcement has documented gaps between the toggle and the actual device behaviour — gaps that vary by platform, OS build, and companion app version. For every control that matters, confirm it with a real device producing the expected result. Write the expected result down before you test, not after. + +**Velocity with a brake.** +Update rings exist not to slow patching but to make patching safe at speed. An unbraked push to the entire fleet is one bad update away from a mass outage — the kind that stops production, not the kind that stops attackers. A canary ring with a real halt-and-rollback capability is the mechanism that lets the rest of the fleet patch fast and safely. The canary must be tested — an untested canary is just the first domino with a friendly name. + +**The device is disposable; the data boundary is the protection.** +Every design decision in this assignment should ask: if this device is wiped and reprovisioned in an hour, does anything important break? A device that can be reprovisioned in an hour is antifragile. A device whose compromise is a crisis is fragile, regardless of how many compliance policies are applied to it. Build for reprovisionability: Autopilot, LAPS, application deployment from Intune, user profile from OneDrive. The compliance baseline hardens the device; the reprovision capability makes its loss survivable. + +--- + +## Delivery Architecture + +### Step 1 — Population Mapping and Audit (no changes) + +| Action | Output | +|--------|--------| +| Four-population mapping (enrolled / registered / authenticating / CMDB) | Device population report: counts, deltas, known-unmanaged estimate | +| Existing compliance policy audit | Policy inventory: assignments, settings, mode, last modified | +| Existing configuration profile audit | Profile inventory: conflicts, orphaned assignments, platform coverage | +| Update ring inventory | Current rings or absence of rings | +| Sign-in log: device compliance state | What proportion of sign-ins carried a compliant device signal in the last 30 days | +| LAPS status | Whether Windows LAPS is deployed or legacy LAPS or neither | + +Share the device population report with the named client lead before writing any policies. The finding is almost always the same: the managed fleet is smaller than assumed, the dark population is larger than assumed, and several CMDB entries have not authenticated in months. State it plainly. + +--- + +### Step 2 — Compliance Policies (report mode first) + +Deploy all compliance policies in report mode. Review results for 72 hours before activating noncompliance actions. The goal at this step is to see the real compliance state of the fleet — not to block anyone. + +**Noncompliance action sequence (apply to all compliance policies):** + +| Day | Action | +|-----|--------| +| 0 | Mark noncompliant (reporting only — this is immediate and always on) | +| 1 | Send email notification to user | +| 7 | Block access (activates when `CA-AllUsers-AllApps-RequireCompliantDevice` is enabled) | +| 30 | Retire device (for persistent noncompliance — confirm with client lead before activating) | + +The 7-day grace window is not leniency — it is the window in which IT can identify and remediate legitimate noncompliance (device in repair, device offline, missed check-in) before a user is blocked. Without it, the first enforcement wave produces a support ticket flood. With it, enforcement is gradual and explainable. + +**Windows compliance policy — baseline settings:** + +| Setting | Value | Rationale | +|---------|-------|-----------| +| BitLocker required | Yes | Unencrypted devices lose data on physical theft | +| OS minimum version | Windows 10 22H2 / Windows 11 22H2 | Below this: no Windows LAPS; OS in extended support only | +| Defender AV enabled | Yes | Baseline detection | +| Defender real-time protection | Yes | | +| Firewall enabled | Yes | | +| Secure boot enabled | Yes | Blocks bootkit-level compromise | +| TPM required | Yes (for new enrollments; consider exclusion group for legacy hardware) | PRT TPM-binding requires TPM | +| Password required | Yes | Minimum complexity, minimum length 8 | +| Maximum inactivity before screen lock | 15 minutes | | + +Do not configure the compliance policy to evaluate Microsoft Defender for Endpoint risk score unless Defender for Endpoint P2 (E5) is licensed. Misconfiguring this setting against an E3 tenant produces false noncompliance for all devices. + +**macOS compliance policy (if fleet includes Macs):** + +| Setting | Value | +|---------|-------| +| FileVault enabled | Yes | +| OS minimum version | macOS 13 (Ventura) or later | +| Password required | Yes | +| Firewall enabled | Yes | +| System Integrity Protection | Yes | + +**iOS compliance policy:** + +| Setting | Value | +|---------|-------| +| OS minimum version | iOS 16 or later | +| Passcode required | Yes | +| Jailbreak detection | Block jailbroken devices | +| Device threat level | Secured (no threat level tolerance) | + +**Android compliance policy:** + +| Setting | Value | +|---------|-------| +| OS minimum version | Android 12 or later | +| Device PIN required | Yes | +| Rooted devices | Block | +| Minimum security patch level | Within 90 days | + +**The honest note on jailbreak/root detection:** detection is an arms race. A motivated attacker with a current tool bypasses it. Treat root detection as a tripwire that raises the cost of the attack, never as a barrier that stops it. Document this in the residual risk statement. + +--- + +### Step 3 — Device Configuration Baseline + +The Microsoft Windows Security Baseline (available in Intune → Endpoint security → Security baselines) is the starting point. It encodes Microsoft's recommended settings as an Intune profile that enforces continuously. + +**Deployment approach:** +1. Deploy the Windows Security Baseline in **report mode** to a pilot group (10–20 devices, IT team first) +2. Review conflicts and configuration gaps for 48 hours +3. Resolve any conflicts with existing policies (overlapping profiles produce unpredictable results — Intune applies the stricter setting per-setting by default, but conflicting values create undefined behaviour) +4. Expand to production groups +5. Monitor Intune reports for policy conflicts and noncompliance + +**Additional configuration profiles (deploy after the security baseline is stable):** + +| Profile | Purpose | Notes | +|---------|---------|-------| +| **BitLocker configuration** | Enable BitLocker silently, escrow recovery keys to Entra | Separate from compliance (compliance requires BitLocker; this profile configures how it's applied) | +| **Microsoft Defender AV** | Configure exclusions, scheduled scans, PUA protection | Do not configure AV exclusions broadly — each exclusion reduces coverage | +| **Firewall configuration** | Block inbound connections, logging | Complements compliance requirement | +| **Edge browser baseline** | SmartScreen, extension management, safe browsing, disable password manager sync | Applies to corporate Edge profile; test carefully — extension management can break legitimate workflows | +| **Windows Hello for Business** | Phishing-resistant authentication at device layer | If deploying phishing-resistant MFA (required by CA-Admins policy), WHfB is the most practical path | + +--- + +### Step 4 — Update Rings + +Update rings are the mechanism that makes patching fast and safe simultaneously. Deploy three rings minimum. + +**Ring structure:** + +| Ring | Assignment | Quality update deferral | Feature update deferral | Notes | +|------|-----------|------------------------|------------------------|-------| +| **Canary** | IT team (5–10 devices) | 0 days | 0 days | Takes every update immediately. Canary for production rings. Must include at least one machine that runs every critical business application. | +| **Pilot** | 10–15% of fleet, varied roles | 7 days | 30 days | Broad business representation. If Canary is clear after 7 days, Pilot proceeds. | +| **Production** | Remainder | 14 days | 90 days | Conservative deferral. If Pilot is clear after 7 days, Production proceeds. | + +**Pause and rollback configuration:** +Configure Intune update rings with the pause capability enabled. Define in the client's runbook: +- Who has authority to pause an update ring (named person, not a committee) +- What the trigger is for pausing (Canary devices showing a known issue, not a vague "something might be wrong") +- Maximum pause duration before the pause is reviewed (7 days) + +An untested pause capability is a fiction. Test it during the engagement: deploy an update to Canary, confirm it lands, pause the ring, confirm the pause holds, resume. This takes 30 minutes and is the only proof the mechanism works. + +--- + +### Step 5 — Windows LAPS + +Standing local administrator accounts are the device-layer version of standing privilege. If the same local admin password is shared across the fleet (common in legacy environments), one compromised device yields lateral movement credentials for the entire estate. + +**Windows LAPS (cloud-native):** +- Available on Windows 10 22H2+ and Windows 11 22H2+ with current patches +- Configure backup target: Entra ID (cloud-native; no on-prem infrastructure required) +- Rotation schedule: 30 days, plus rotate on device handoff +- Requires Entra ID P1 (included in E3) + +**Deployment:** +1. Enable LAPS in Entra ID (Entra admin center → Devices → Device settings → Enable Microsoft Entra Local Administrator Password Solution) +2. Create an Intune LAPS policy (Endpoint security → Account protection → LAPS) +3. Assign to a pilot group; confirm password backup to Entra after check-in +4. Expand to production + +**For legacy LAPS (on-prem AD environments where Windows LAPS is not yet deployable):** +Legacy LAPS (the original Microsoft LAPS MSI) remains deployable via Intune for hybrid-joined devices. Flag this as a transitional state — cloud-native Windows LAPS is the destination. + +**What this does not solve:** if standing Domain Admin or local admin is provided to specific IT staff outside of LAPS, that standing privilege is out of scope for this assignment. Log it in scope boundary signals. + +--- + +### Step 6 — App Protection Policies (BYOD) + +App Protection Policies (MAM without MDM) manage the data layer on personal devices without enrolling the device. This is the correct model for BYOD: wall the corporate data, not the device. + +**The honest caveat, stated plainly:** App Protection Policy enforcement has gaps. The policy controls what managed apps should do; the actual enforcement is dependent on the app version, OS version, companion app (Company Portal on Android), and specific API support. "Block copy/paste to unmanaged apps" blocks in documented paths — it does not block screenshots, OS-level share sheet on some platforms, or every third-party clipboard manager. Test on real devices. Document what you verified and where the limits are. + +**Deploy separate policies per platform.** iOS and Android are not symmetric. A policy that works on iOS may not produce the same behaviour on Android. Test both independently. + +**iOS App Protection Policy — baseline settings:** + +| Setting | Value | +|---------|-------| +| Prevent "Save As" to personal storage | Block | +| Restrict cut/copy/paste to managed apps only | Managed apps with paste in | +| Require PIN for app access | Yes (after 5 minutes inactivity) | +| Minimum OS version | iOS 16 | +| Offline grace period before access blocked | 720 hours (30 days) | +| Selective wipe after failed PIN attempts | Yes (after 10 attempts) | +| Minimum app version | Latest − 1 (configure per app) | +| Jailbroken/rooted devices | Block | + +Apply to: Outlook, Teams, Edge, OneDrive, SharePoint mobile. These are the apps through which corporate data flows on BYOD devices. + +**Android App Protection Policy — same baseline settings.** Test enforcement independently — behaviour on Android differs, particularly clipboard controls and "open in" restrictions. + +**Selective wipe verification:** +Test selective wipe on a real BYOD device before the engagement closes. Confirm that corporate data (email, files, Teams content) is removed and personal data (photos, personal apps) is not. This is the capability that makes MAM politically viable — if the user doesn't trust that it won't touch their personal data, enrollment fails. Document the test. + +--- + +### Step 7 — CA Layer 3 Activation + +This is the step that connects device compliance to access control. Everything before this point has been deploying and measuring; this step makes compliance matter for access. + +**Prerequisites before activating:** + +- [ ] Compliance policy deployed and returning results for ≥ 80% of the enrolled fleet +- [ ] 72 hours of report-only compliance results reviewed — no widespread false noncompliance identified +- [ ] Break-glass accounts confirmed excluded from device compliance CA policies +- [ ] Named client lead has approved activation in writing +- [ ] IT team briefed on noncompliance action timeline (users blocked after day 7 if noncompliant) +- [ ] Helpdesk runbook written: what to do when a user is blocked due to noncompliance + +**Activation sequence:** +1. Switch `CA-AllUsers-AllApps-RequireCompliantDevice` from report-only to **enabled** +2. Monitor Intune compliance dashboard and Entra sign-in logs for 24 hours +3. Confirm: compliant devices are signing in successfully; noncompliant devices are being blocked at CA +4. Confirm: break-glass accounts are not blocked + +Do not activate device-compliance CA policies on a Monday or before a public holiday. An unexpected compliance failure during a period of low IT staffing is a bad outcome that a one-day wait entirely prevents. + +**After activation, the compliance signal is live.** A device that loses compliance — drops encryption, falls behind on patches, is rooted — will be blocked from M365 access within the 7-day noncompliance action window. This is the control working as designed. + +--- + +## Structural Resilience Checklist + +Controls that hold without ongoing human willingness after this engagement closes. + +- [ ] Compliance policies deployed and returning results for enrolled devices +- [ ] Noncompliance action timer active (day 7 block — not just report) +- [ ] Windows Security Baseline profile active on production fleet +- [ ] Update rings deployed with Canary, Pilot, and Production separation +- [ ] Update ring pause tested at least once +- [ ] Windows LAPS deployed; local admin passwords backing up to Entra +- [ ] App Protection Policies active for iOS and Android BYOD (tested on real devices) +- [ ] Selective wipe tested on BYOD device +- [ ] `CA-AllUsers-AllApps-RequireCompliantDevice` **enabled** (not report-only) +- [ ] Break-glass accounts excluded from device compliance CA policies — confirmed with a real sign-in + +--- + +## Kill Chain Contribution + +**What this assignment closes (or significantly raises the cost of):** + +| Attack vector | Control deployed | +|---------------|-----------------| +| Stolen credentials used from unmanaged/unknown device | CA Layer 3: compliant device required | +| Physical theft of unencrypted device | BitLocker compliance requirement | +| Lateral movement via shared local admin credentials | Windows LAPS: unique per-device passwords | +| Unpatched OS exploited at known CVE | Update rings: enforced patch cadence | +| BYOD personal device accessing corporate data without controls | App Protection Policies: data container on unmanaged device | +| Attacker persistence on device after credential reset | Compliance noncompliance action: device retired after persistent noncompliance | + +**What this assignment does not close:** + +| Remaining gap | Addressed by | +|---------------|-------------| +| Session token theft post-compliance check (AiTM phishing) | Entra token protection (P2) + continuous access evaluation | +| Compromised but still-compliant device (stale signal window) | Defender for Endpoint device risk integration (E5) | +| App-layer data exfiltration through sanctioned apps | Collaboration and data security assignment | +| Advanced malware, post-exploitation on managed device | EDR: Defender for Endpoint P2 (E5) or Wazuh/Sysmon augmentation | +| Standing privilege on servers accessed from managed devices | Privileged access engagement | +| Dark access (legacy auth, long-lived tokens bypassing CA) | Legacy auth block (identity baseline) + token lifetime policies | + +The most important gap to document plainly: a managed, compliant device that carries a stolen session token (issued after legitimate MFA) still has access. The compliance signal does not re-evaluate session tokens retroactively. Continuous Access Evaluation (CAE) narrows this window for supported apps — verify which apps in the client's environment support CAE, and document the remainder as residual risk. + +--- + +## Leave-Behind Package + +| Artifact | Description | +|----------|-------------| +| **Device population report** | Four-population map: enrolled, registered, authenticating, CMDB; delta analysis; known-unmanaged estimate | +| **Compliance policy documentation** | Every policy: settings, assignments, noncompliance action timeline, rationale | +| **Compliance dashboard export** | Compliance rates by policy and platform at engagement close | +| **Configuration profile documentation** | Security baseline and supplemental profiles: settings, assignments, conflict analysis | +| **Update ring documentation** | Ring structure, deferral schedule, pause/rollback procedure, pause test result | +| **LAPS deployment confirmation** | Devices with LAPS active; Entra backup confirmed; rotation schedule | +| **App Protection Policy documentation** | iOS and Android policies: settings, tested behaviours, documented gaps per platform | +| **Selective wipe test record** | Device tested, result, personal data confirmed intact | +| **CA Layer 3 activation confirmation** | Sign-in log showing compliant devices accessing successfully, noncompliant devices blocked | +| **Scope boundary log** | Every finding outside this scope, named and prioritized | +| **Residual risk statement** | What this assignment did not close: stale compliance signal, AiTM token theft, EDR gap, dark access | + +--- + +## Scope Boundary Signals + +| Signal | Points toward | +|--------|--------------| +| Shadow IT apps visible in Intune application inventory | Collaboration and data security assignment; shadow AI discovery | +| SCCM co-management active; GPO policies conflicting with Intune | Co-management migration engagement; AD hardening | +| Hybrid-joined devices that depend on line-of-sight to DC | Cloud-native migration path; hybrid identity engagement | +| No Defender for Endpoint P2; device risk signal not feeding CA | E5 licensing gap; E3 augmentation with Wazuh/Sysmon | +| Standing local admin accounts for IT staff outside LAPS scope | Privileged access engagement (Endpoint Privilege Management) | +| Autopilot not configured; device reprovision takes days not hours | Autopilot deployment engagement | +| Legacy devices below Windows 10 22H2 in the compliance-excluded group | Accelerate OS refresh; document as known risk with timeline | +| Audit log retention < 90 days | Detection baseline assignment | +| MAM enforcement gaps found during BYOD testing | Document with vendor; consider MDM enrollment for corporate-issued mobile | + +--- + +## Buildable-On: What the Next Assignment Depends On + +The Collaboration and Data Security assignment builds on the device posture deployed here. Specifically: + +1. **`CA-AllUsers-UnmanagedDevice-AppEnforcedRestrictions` behaviour** is now testable against the real unmanaged device population. With enrolled and unmanaged devices mapped, you know which users will be affected by app-enforced restrictions and can design the policy accurately. +2. **The application inventory from Intune** surfaces the shadow IT picture that informs data security scope — what apps are running, what cloud storage is installed, whether consumer AI tools are present. +3. **Managed device as a data exfiltration boundary** — with compliant devices required for access, the remaining data risk is through sanctioned apps on managed devices. That is the scope of the next assignment. + +--- + +*For the identity foundation, see [Assignment: Identity Baseline](assignment-identity-baseline.md).* +*For the CA Layer 3 policies this assignment activates, see [Assignment: CA Architecture](assignment-ca-architecture.md).* +*For the governing philosophy on device posture, see [Book IV — Devices & Endpoint](../books/03-devices-and-intune.md).*