On this page
3.1) Data Loss Prevention
1. Deployment Strategy (The “Crawl, Walk, Run” Approach)
- Never Start in Enforcement: Implementing a block policy on day one will halt business operations and generate immediate escalations. Always follow the phased rollout:
- Test it out (Audit Only): Silently gathers data to show you the baseline of what users are sharing.
- Test it out with Policy Tips: Audits the data but displays a warning to the user (e.g., “This email contains sensitive data”), educating them without blocking the action.
- Turn it on right away (Enforcement): Actively blocks or encrypts the data.
- Scoping: Policies should ideally be scoped to specific locations (Exchange, SharePoint, OneDrive, Teams, Endpoints). Avoid massive “All Locations” policies with complex rules, as they are notoriously difficult to troubleshoot.
2. Classifying the Data (What are we protecting?)
- Sensitive Information Types (SITs): Microsoft provides hundreds of out-of-the-box SITs.
- Local Contexts: For example, if you are Australian, familiarize yourself with Australia Tax File Number (TFN), Australia Medicare Number, and Australia Passport Number.
- Custom SITs: Built using Regular Expressions (Regex) + Keywords + Proximity (e.g., finding a 9-digit number within 50 characters of the word “Account”).
- Exact Data Match (EDM): Used to prevent false positives. Instead of looking for any credit card, EDM hashes an export of your actual customer database and only triggers a block if it sees a credit card belonging to a known customer.
- Trainable Classifiers: Machine learning models trained on hundreds of sample documents to recognize a type of document (e.g., Source Code, Resumes, Legal Agreements) regardless of specific keywords.
3. Policy Rules & The User Experience
- Conditions & Exceptions: The most common enterprise condition is:
Content contains [SIT]ANDContent is shared [Outside my organization]. - Confidence Levels & Instance Counts:
- High Confidence: Requires the data pattern, a keyword, and validation (like a checksum).
- Instance Count: Set thresholds. (e.g., 1-4 credit cards = send a warning. 5+ credit cards = hard block and alert the security team).
- User Overrides & Business Justifications: When moving to enforcement, configuring “Allow user to override” is critical. It shifts the liability to the user. They must type a reason (e.g., “Approved by client”) which is logged for the compliance team, preventing the IT Helpdesk from becoming a bottleneck.
4. Endpoint DLP (Securing the Local Device)
- Onboarding: Devices must be onboarded to Microsoft Purview (usually done silently via Intune configuration profiles) to read endpoint signals.
- Capabilities: Endpoint DLP extends protection beyond the browser. It allows you to block users from:
- Copying sensitive files to USB drives.
- Printing sensitive documents.
- Copying sensitive text to the clipboard.
- Uploading files to unsanctioned cloud storage (e.g., blocking upload to personal Google Drive via Edge/Chrome).
5. Alerts, Triage & Permissions
- Role-Based Access Control (RBAC): Being a Global Admin or SharePoint Admin does not grant you access to read the contents of a DLP violation. You must be explicitly assigned the Compliance Data Administrator or Information Protection Investigator role to view the source item in the Content Explorer.
- Alert Fatigue: Bundle alerts to prevent overwhelming the SOC. Configure rules to send an alert only when a specific volume is reached (e.g., “Send an alert when 5 activities occur within 60 minutes”).
6. Essential PowerShell Cmdlets (ExchangeOnlineManagement / Security & Compliance)
- Note: You must connect to the Security & Compliance center specifically, which is nested within the Exchange module.
- Connection:
Connect-IPPSSession - Policy Management:
Get-DlpCompliancePolicy(Lists the high-level policies)Get-DlpComplianceRule(Lists the granular rules nested inside the policies)Get-DlpSensitiveInformationType -Identity "Australia Tax File Number (TFN)"(View the configuration of a specific SIT)