Data Loss Prevention (DLP) for Microsoft Teams: capabilities and limitations

AGAT Software team

This article will be dealing with the difference between using real-time and near-real-time Data Loss Prevention (DLP) for Microsoft Teams and featuring a video with an experiment on the topic. We will also discuss how does Microsoft address policies when signing in as a guest.

Introduction

Data Loss Prevention (Also called Data Leak Prevention) Solutions can be different in many aspects like rule setting, customization options and platforms covered. It does not matter which industry or business type, data is transferred at an extreme fast pace and those who need a DLP want to see an action taking place that can mitigate the effects of sensitive information being transferred on messages, files, and more relevant to our days, video and audio conversations.

What is more, companies want to keep consistency in blocking internal employees from sharing sensitive information while being guests or external users with other companies, which arguably could be one of the most important concerns.

DLP approaches – Real-Time preventive or Near-Real-Time proactive 

Companies adopt different approaches to handle Data Loss Prevention needs. 
When Intellectual Property (IP)  protection is on the table, prevent or block-  is the approach that is needed while in other cases a proactive approach is good enough. Proactive can also be used for compliance awareness. Companies can adopt a proactive approach realizing that there is no limit to the channels that an employee can cause data leakage and rather invest in training and awareness.

Microsoft near real-time DLP for messages and files 

Microsoft has been offering for a good time DLP services for their Teams Unified Communications Software and since then it has had different feedback from its users.

While many users praise their near-real-time handling of messages, others are quite unfulfilled with the DLP capabilities of files
The main point has been described as long delays to handle those files, which could allow the end users to download and see before anything occurs. The second point is that custom rules, ie. those specifically designed by users, do not apply to files and can result in lack of coverage.

As for now, Microsoft has been improving the handling of DLP policies for messages, while it has been said that they will release the ability to block files from arriving to the end user, turning the platform into non-real-time.

Definitions that matter

It is important to highlight that Microsoft describes their DLP as near-real-time, and here definitions play a big role.

The comparison would be as following: 

Let’s take a situation of getting wet in the rain or touching a hot stove as a situation you want to avoid in some cases. We can all understand that opening the umbrella after the rain has started or quickly removing your hand from the hot stove is less good than avoiding the situation from the first place as damage is done. Near Real-time is near protection. Almost protected against damage and threats. For many this is sufficient but for others it is not an applicable solution.

In the world are various examples of both real-time systems, those who require a continual input, constant processing and steady output of data: Data streaming – Radar systems – Customer service systems – Bank ATMs

For near-real time, when speed is important but processing time is accepted to be in minutes instead of seconds, these are the usual examples: Processing sensor data – IT systems monitoring – Financial transaction processing

Some of this information was based on this blog post by syncsort.

See how a user can get access to sensitive file even when Microsoft DLP is enforced 

In this video it’s possible to see a simulation of a real-life scenario of Microsoft intervening on a “sensitive” (DLP defined) file being sent from one user to another. As it’s shown, Microsoft DLP takes around 50 minutes to detect a file containg sensitive information (defined on policies). That time is more than enough to download the file and

Microsoft Teams DLP Limitations and risks

DLP Limitations when signing in as a guest

If sharing sensitive data within the internal scope of the company presents a big risk, all the more so when talking about employees sharing it externally. If this sounds logic to you, then pay attention. This next video is going to show that on Microsoft Teams Data Loss Prevention.

In the experiment a DLP policy is set up to catch sensitive data. At first it shows working when dealing with internal employees. Now, when the same user logs in to another company as a guest, the policy won’t take effect.

This shows an existential threat when dealing with Data Leak Prevention policies

DLP not working when dealing as a Guest

Our approach: Sphereshield Real-Time DLP for Microsoft Teams

Here at AGAT software we have developed a real-time approach for a DLP in Microsoft Teams. The solution works by analyzing the content being sent before it can reach the end user, not giving any chance to the end user to see or download anything. We believe that it is the difference between pressing the brakes a little bit late and not even turning on the engine.

On the other side, SphereShield Data Loss Prevention policies are context aware and can apply for both internal and external communications. This addresses the biggest risks making it impossible to circumvent the system.

When Data Loss prevention is a real concern and a need, the only solution is a real-time DLP that is context aware

For more information CONTACT US