Senior Solution Advisor – Cloud Secure Infrastructure, ACTS
Data Loss Prevention (DLP) is critical for any Microsoft 365-based company – everyone has items they’d hate to see leak out. For those covered by compliance, the pain of data loss is compounded by another agony – the big fines that accompany a major data loss event.
Of particular note is data that can cause another harm, so-called personally identifiable information (PII). When these credit card and social security numbers, or perhaps health information leak out, people get hurt. And the fines are massive. Why do you think Equifax got fined $575 million? It wasn’t for sharing the company party menu selection.
Fortunately, Microsoft 365 has many ways to support DLP. Lower level licenses such as M365 E1 and E3 include DLP for email, itself a major source of data loss, and high-end E5 licenses extend DLP to all major surfaces.
Meanwhile, the Microsoft 365 Compliance Center has an array of DLP features that discover sensitive information, monitor it, and automatically protect data and documents throughout their lifecycle.
1. Conduct a Sensitive Data Inventory
A great place to begin your M365 DLP is by finding out what sensitive data is on your platform, as well as how this data is being created so you can apply ongoing protections. This audit should offer granular visibility into the categories or sensitive data stored, used and created within M365. Visibility can be gained by scanning Exchange, SharePoint, OneDrive and other repositories for data at rest.
IT can define what data needs protecting, but there are categories of clearly sensitive information, including:
- Social Security numbers
- Documents containing passwords (a hacker’s delight!)
- Account numbers
- Credit card numbers
- Health records and personal health information (PHI)
- Financial data
2. Define What Data Should Not Even be on Microsoft 365
Some organizations that are subject to very strict compliance rules, or in industries with deep confidentiality regulations, have data too sensitive to be stored or worked on within M365. This could include powerful financial institutions, government contractors, and medical research and pharmaceutical companies.
Here, IT needs to define what data can never enter M365, and have ways to insure it doesn’t. These techniques are much the same as determining what data gets Data Retention and Sensitivity Labels, such as looking for keywords, using pattern matching and exact matching to discover data and documents that should be isolated from M365.
Alerts and action can then block the files, quarantine them till approved, and coach users on the rules about using this data.
3. Analyze How Data is Shared – and Where the Holes Are
Once you know what sensitive data you have, dive into how this information is shared. How is sensitive data shared within the company, and more importantly, how is it shared externally – and with whom?
This can include, for instance, analyzing how many users have personal, non-company standard email accounts such as Gmail, how many auto forward to these accounts, how many share OneDrive data, and how prevalent is the forwarding of anonymous links.
4. Define and Detail DLP Policies
DLP is not an ad hoc proposition. It is a deep and ongoing process best handled with the right solutions, processes, practices, and policies – plus follow-up, which is done through reporting, adjustment and remediation.
These policies determine how sensitive information is defined, where it resides such as in Microsoft Teams, Exchange, SharePoint OneDrive, and core M365 productivity apps such as Word, Excel and PowerPoint.
Next, policies establish how data sharing is controlled, such as blocking access or the release of documents with health data, PII, financial information, or other confidential materials. Here IT must protect not just M365 cloud apps, but on-premises desktop versions of Word, Excel, and PowerPoint.
DLP policies can be set on the Compliance Center Data Loss Prevention page.
5. Conduct DLP Policy Training
All the policies in the world won’t give you true DLP without end user compliance. Part of your plan should include explaining DLP policies, documenting the policies, training end users on how to comply, and tracking success with regular follow ups.
Corrective actions or notices of non-compliance are also important. With the right tracking and alerts, IT can set up a system to notify a user, say by email, if they attempt to share or email a document with sensitive protected data. The message can include policy tips on how to comply with DLP, and what they should do if they feel they have a legitimate need to share the information.
6. Be Alert to DLP Alerts
IT is responsible for DLP and regulatory compliance, and so must know when data is trying to leave, or worse, has already left the environment. Alerts and reports are both vital to this effort. Alerts don’t create themselves, but are based on DLP policies your organization sets.
The good news – alerts are built right into the Compliance Center’s DLP Alerts Management Dashboard. This offers specific reports for data loss events, as well as an overview of how well your organization complies with the policies you’ve set.
The alerts generally go to the compliance officer detailing what happened, what DLP policy was violated, and what sensitive protected content was involved.
A deeper incident report dives into the details, with the exact document in question, who last worked with the document, and a copy of the original attachment in the case of an email event.
7. Follow the Rules of DLP Engagement — Setting Conditions
DLP rules are based on conditions, and when broken, actions are performed.
DLP rules are based on IT established conditions which determine when the rule is violated. In short, the condition must be met for the rule to be enforced and action taken. Instead of having a rule that just says any document containing drivers license data can’t be shared, the condition may deign that those documents can’t be shared with other organizations and non-employees. Think of a health care worker that needs to work with HIPAA data, but when sent to non-HIPAA companies is considered data leakage or loss.
In that regard, conditions look at two issues, the content itself and whether is it sensitive or needs protection, and the context which is what is done with that content and with whom. As with our HIPAA example, the data is only risky when shared outside the health care organization which violates the rules.
8. Activating Actions
The whole point of DLP policies, rules and conditions is to know exactly when to take action. Depending on configuration, admins can be alerted to take manual action, or actions can be automated which provide faster protection or remediation. For instance, it makes more sense to automatically block access to a sensitive document, and link this to a notification to the end user and possibly the compliance officer or someone who fills that role.
Content restriction actions can apply to everyone except those with explicit permission, restrict access to anyone outside your organization, or restrict access to anyone with a link to the document.
9. Scope DLP by Location
Different groups within your company have different data needs. The finance groups works on the numbers, while product development has no need to see this confidential information, and providing that access is an avenue to leakage.
Access can be determined by location or department and further scoped or controlled down more specific, smaller distribution groups. In the case of finance, not all in that department need access to confidential, and especially unreleased numbers. Scoping policies can be based on security groups, dynamic distribution groups, or distribution lists.
10. Apply Retention and Sensitivity Labels to Protect Data
Retention and Sensitivity Labels are a key way to classify data as sensitive, and set policies for its retention as well as conditions under which it can or cannot be shared (link to Compliance blog). In fact, these Labels can drive policies by acting as the condition in an enterprise’s DLP policy.
(Shawn Pickett is Senior Cloud Solution Advisor with a focus on Cloud Secure Infrastructure hosted in Azure, AWS, and Google Cloud Platform. He is a Trusted IT Executive Advisor for ACTS Consulting clients across multiple verticals advising on Cloud Architecture/Deployment/Security, Disaster Recovery and Business Continuity, Application Hosting, Database Hosting, Cloud Operating Models and Cloud Economics.)