Petri Newsletter Sign-up
Office 365 Insider

Here at Petri.com, we get IT — and so can you. Subscribe today to stay informed and knowledgeable regarding the latest on IT.

    See All Petri Newsletters

    Teams Supports Office 365 Data Loss Prevention Policies

    Posted on by Tony Redmond in Microsoft Teams, Office, and Office 365

    Checking Sensitive Data in Teams

    Office 365 Data Loss Prevention (DLP) policies have supported Exchange Online, SharePoint Online, and OneDrive for Business for a couple of years. Originally announced in December 2018, Teams support for DLP is now generally available. Somewhat oddly, while DLP coverage for Exchange and SharePoint is included in the Office 365 E3 plan, you need the Office 365 E5 plan or the Office 365 Advanced Compliance add-on for Teams. With that cheery thought in mind, let’s take a look at how DLP works in Teams.

    Creating an Office 365 DLP Policy for Teams

    You can update an existing DLP policy to include Teams content or create a new policy. For testing purposes, it’s easiest to create a separate policy and use it to scan for a well-known sensitive data type such as credit card numbers. You don’t need to use real credit card numbers as test numbers (like this set from PayPal) to check the policy.

    Whether you update an existing policy or create a new policy, the action to include Teams in DLP checking is the same. You select users and teams to add to the policy. If individual users are specified, Teams applies DLP checks to personal chats involving these people (including chats with others not covered by the policy). When you add teams to a policy (Figure 1), Teams checks all channel conversations within those teams.

    Adding Teams to a DLP policy
    Figure 1: Teams joins the set of DLP locations (image credit: Tony Redmond)

    The usual DLP settings available for checking Exchange, SharePoint, and OneDrive for Business content (what of the 90+ sensitive data types to look for and actions to take) apply to Teams. The only thing that you must remember is that Teams communications are internal while DLP checking for other workloads focuses on outbound email or document sharing. The DLP policy must therefore cover content shared “only with people in my organization” (many existing [policies are probably set to cover content shared “with people outside my organization.” In the context of Teams, this means teams with guest users).

    It can take up to an hour for Teams to make a DLP policy active. In my tests, it usually took less time, but the time depends on service load, so it’s best to set an expectation that it will take a little time before new and changed policies are effective.

    Teams DLP Checking

    The Teams clients don’t scan for DLP violations as users enter text. Instead, to avoid the need to incorporate DLP checking code in clients, Teams checks content against DLP policies after clients submit messages to the Chat service.

    Text in messages is compared against the sensitive data types defined in the policy and other evidence (such as the presence of a keyword like “MasterCard” for a credit card number) is used to calculate the confidence level for a match. Other policy settings such as the number of matches and the people who receive a message are also considered to figure out if a violation exists. If a violation is found, Teams generates a block signal to a “Rethook” (a mechanism used by Teams to flag actions to clients) that tells the client to block the message (Figure 2).

    DLP blocks a Teams message
    Figure 2: DLP blocks a Teams message (image credit: Tony Redmond)

    Users receive a notification in their Activity Feed when Teams blocks one of their messages. In addition, if the user is logged into Teams with a mobile device, they’ll receive a notification on the device that their message is blocked.

    One small problem I noted is that the notification messages Teams sends by email to let users know when someone is trying to reach them in chat can expose sensitive data that’s blocked by policy. It’s unlikely to be a blocking factor for a deployment because the data is only exposed if it’s in the first few lines of a message, but it is something for Microsoft to review.

    Overriding a DLP Block

    When a message is blocked, only the sender can see it. If allowed by policy, the sender can override the block imposed by DLP to make the message visible again (Figure 3).

    Override Teams DLP block
    Figure 3: Overriding a DLP blocked message with the Teams desktop client (image credit: Tony Redmond)

    All the Teams clients support the ability to override a blocked message. Figure 4 shows the options exposed in the mobile client (use Resolve to see the override options). You’ll need a “long press” to see these options for a blocked personal chat – the option is more obvious for channel messages where it’s found on the ellipsis menu.

    Teams resolve block mobile
    Figure 4: Resolving a DLP blocked message on Teams mobile (image credit: Tony Redmond)

    Speedy Blocks

    In my testing, I noted that Teams blocked messages posted to channel conversations faster than personal chats. Microsoft says that both message types go through the same processing pipeline, but at times it could take up to ten minutes before Teams blocked a personal chat when it blocked a violation in a channel conversation in well under a minute. The exact same test content was used to generate the violation in both cases.

    DLP policies only scan for violations in new content. In other words, they don’t perform retrospective checks to find problematic content in old messages.

    DLP Incident messages

    When a violation is detected, the policy can require Office 365 to generate an incident report to send to an administrator. The report tells you the name of the policy that detected the violation and who caused the problem. However, the report doesn’t tell you whether the violation is in a channel or personal chat (and for channel messages, what channel). Here’s some example text:

    A match of one or more of your organization’s policy rules has been detected. Details:
    Person who last modified document: [email protected]
    Severity: High

    Condition matched: Contains sensitive information

    The incident report is a generic format used for Exchange, SharePoint, and Teams, which is why it doesn’t have more precise information specific to Teams such as the name of the channel where a blocked message was posted.

    DLP also captures data about the number of violations within a tenant. This information is available in the DLP dashboard in the Security and Compliance Center where administrators can see details of DLP incidents, including whether the violation happened in a personal chat or channel conversation. For example, the record shown in Figure 5 is for a DLP match in a personal chat (IM).

    Teams audit record DLP
    Figure 5: Details of a DLP violation (image credit: Tony Redmond)

    Items reported in the DLP dashboard are recorded as events in the Office 365 audit log, which means that you can extract and analyze those records if you need further information.

    Solid DLP Implementation

    Microsoft has done a good job in the DLP implementation for Teams. It would be nicer if the incident report was more precise and some work needs to be done on notification messages, but you can’t have everything. The point is that Teams has another string to its compliance bow to join supervision policies, capture of compliance records for eDiscovery, and retention policies. It’s a good line-up to have.

    BECOME A PETRI MEMBER:

    Don't have a login but want to join the conversation? Sign up for a Petri Account

    Register