antifragile/antifragile-consulting/playbooks/assignment-collaboration-security.md

# 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).*