One of the most common questions I hear is some variant of “does Microsoft offer data loss prevention in the cloud?” The answer is yes, but it turns out the question is more nuanced. What data do you want to protect? Is it file data, app data, email & IM’s, or something on-prem or even living in another cloud?
And what does “loss” even mean to you? It’s all data, and it’s all important, and we certainly don’t want to lose any of it. Is loss accidental, intentional, or a combination of the two? Does it mean breach, exfil, or tampering? Do you view protection of that data as automatic or manual?
What constitutes “prevention”? Is it data segregation, encryption (file, disk, network, etc.), good ol’ fashioned backups, or other arcane magic?
Where do you want to protect it? In the service, in transmission, on the endpoint? And what do you want to do about it when detections occur?
Turns out DLP is all of those things, but not to everybody, so I can have 10 conversations about DLP in a week and never cover the same material twice.
To the astute observer, this crosses over into a greater discussion about “data governance,” an overarching set of controls that includes retention, records management, communication compliance, and information protection controls. We covered Azure Information Protection (now Microsoft Information Protection, because who needs consistent product names?) earlier this year, so I won’t reinvent that wheel, but I would encourage you to consider encryption and sensitivity labeling as part of your core data security plan.
Today, though, we’re zeroing in on a fairly targeted definition of DLP: the prevention of inappropriate sharing of sensitive data.
Exchange has always had DLP capabilities, generally created in the form of transport rules. Transport rules are the staid workhorses of DLP, and it’s easy to forget about their significance even in the modern world of having dedicated DLP engines, but we can stop anyone from emailing just about anything to just about anyone, with tons of conditions and configuration options.
Where Office 365 builds upon that and codifies it into an explicit set of controls, however, is the conveniently-named Data Loss Prevention blade in the Compliance Center.
Here we can set global policies for our communications workloads to search for and act on known sensitive information types, like government-issued ID’s, credit card numbers, and other types of PII or business-specific data. There are over 200 pre-canned sensitive information types available, and of course you can always add custom content. The data loss prevention blade allows you to quickly and easily align your policies to compliance requirements across a variety of data-types and geographies.
You can then tailor those policies around low-volume (typically 1 – 10 instances within a given character proximity in a single document) or high-volume detections, with alerting, content encryption, transmission and access restrictions, and user override capabilities.
The blade also got a recent overhaul that now surfaces training content, alerts, endpoint controls, and DLP-related activity. Want to know if your rules are working as expected? Take a look in the Activity Explorer:
And the endpoint controls that are now integrated into this blade take a lot of the guesswork out of configuring consistent settings through Endpoint Manager, though some additional configuration is necessary to onboard machines. If you’ve ever seen my demo on using Windows Information Protection to compartmentalize apps and data to prevent users copying data from say, Edge into Chrome, this is that, but auditable and managed from the cloud instead of from the client.
There are a huge range of capabilities surfaced in the Data Loss Prevention blade, and they pull from and report to other controls in the Compliance Center, like the Data Classification, Information Protection, and Insider Risk Management blades.
We’ll probably have to make Insider Risk Management the focus of a future blog, because seriously, this is cool:
And because our new DLP blade can interact with Cloud App Security, we get SaaS coverage and data governance actions built in. Want to ensure PCI data doesn’t live in a 3rd party app like Box or G Suite? That’s built into the advanced DLP rule wizard:
Since I can leverage Cloud App Security directly from DLP, it’s worth mentioning that I can also leverage it from Conditional Access App Controls in Azure AD to monitor access or even block downloads of corporate files. This is one of the easiest ways to prevent users downloading work data to personal devices, and actually uses Cloud App Security as a reverse proxy with auditing and risk correlation. In my demo environment, I use this rule to ensure that not only corporate, but also compliant devices are required to access and download my SharePoint data.
And speaking of Cloud App Security, I can also build my DLP policies directly in that interface, and it includes several built-in templates to quickly deploy DLP policies:
So, does Microsoft offer DLP in the cloud? Oh yeah: tons of it. From workload to endpoint to the storage and network in-between, we have protections and policies and detection engines that can alert, act, and audit every facet of the DLP discussion, whether you’re talking about the narrow definition of “inappropriate sharing” or more generally interested in data governance as a whole.
Comments