Set a Delay for Microsoft Content Services to Evaluate Email Content

I was asked about a Microsoft Technical Community post from July 2023 titled Oversharing Pop-up in Outlook– Customize experience via GPO settings. Some folks couldn’t get the pop-up windows to work with the newly branded Outlook (classic), so I decided to take a look.

Outlook DLP Policy Tips and Pop-Up Windows

When a tenant has configured Data Loss Prevention (DLP) policies to prevent sharing of sensitive data, Outlook and OWA evaluate message content and display policy tips if configured in DLP rules. Figure 1 shows how Outlook displays a policy tip after detecting some credit card information in a message.

Outlook sends email content to Microsoft content services for processing by DLP policies. If a violation is found and a policy tip is configured, Outlook displays the policy tip. It’s possible to use a sensitivity label to block access to content services for Microsoft Office apps. Although the intended use case for assigning such a label to an email is to stop Copilot for Microsoft 365 processing message content, the label also stops DLP policy tips. Blocking a visual indicator isn’t optimal, but a backstop exists in that the transport service can block messages when it processes the checks defined in DLP policies.

The Problem Being Solved with Outlook DLP Policy Tips

The problem that the pop-up messages attempt to solve is that it’s possible to insert sensitive data into a message and send it before Outlook has the time to send the content to Microsoft content services, which means that the user never sees the policy tip. The solution that I tested involved configuring the specify wait time to evaluate sensitivity content setting in a Cloud Policy configuration in the Microsoft 365 apps admin center (Figure 2).

Enabling the setting and specifying a period (in seconds) instructs Outlook (classic) to pause for the specified period before sending a message. Allowing 15 seconds or so should be enough for Outlook to transmit the email to Microsoft content services and receive a response. During this process, users see a message to tell them that the organization requires email to have a sensitive content check before transmission (Figure 3).

Depending on the DLP rule conditions, a violation discovered by the content check causes Outlook to display the policy tip with or without the message being blocked. If allowed by the DLP rule, the sender can override the block and continue to send the email. Figure 4 shows a DLP rule configured with a policy tip and the ability for a sender to override the block.

When content services detect a policy violation, Outlook displays the policy tip and the dialog to allow the user to override the policy (Figure 5).

DLP captures DLPRuleUndo audit records when users override a policy when sharing sensitive documents from SharePoint Online and OneDrive for Business. Exceptions cited by email senders are included in the audit data payload for the records. The same records are not captured when people override a DLP block with Outlook. I have flagged this issue to Microsoft and await their response.

Outlook DLP Policy Tips Good if You Can Handle the Sending Delay

Outlook pop-ups for sensitive data checks close a gap that might stop someone from sending a message containing sensitive content only to have DLP reject the message when it goes through the Exchange transport service. Closing any gap is goodness, as is the additional education people see when they see that messages are checked. The downside is that users might dislike the delay all outgoing messages experience to allow content services to process their content, plus the lack of audit records. If you can live with these issues, then pop-up warnings for Outlook might be a policy to experiment with a small target group before making it live for everyone.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Oversharing Popups  for Outlook Help Users Avoid DLP Problems

Originally due for deployment in March 2023, Microsoft is rolling out the ability for Outlook clients to detect and highlight messages using “oversharing popups” if the messages have specific sensitivity labels. The change is covered by message center MC523046 (last updated 9 June 2023) and Microsoft 365 roadmap item 100157. It’s also associated with Microsoft 365 roadmap item 100255, which covers the general effort to provide customers with replacement technology for the features available in the Azure Information Protection unified labeling client (due to retire in April 2024).

Azure Information Protection (AIP) labels were the predecessor of Microsoft 365 sensitivity labels. Users had to install a separate add-in to use labels (now the unified labeling client). As part of the process to retire the unified labeling client, Microsoft has incorporated information protection technology in the Microsoft 365 apps. The UI exposed by the AIP is gradually being replaced in native Microsoft 365 features. The arrival of the sensitivity bar in Microsoft 365 apps is an example of the process in action.

Implementing Oversharing Popups in Microsoft 365 DLP Policies

In this case, instead of relying on the unified labeling client to detect potential “oversharing” problems when users compose email, it’s now possible to include checks in Data Loss Prevention (DLP) policies. The effect is to cause Outlook to use a policy tip to highlight that a message contains sensitive content that shouldn’t be shared outside the organization as users work with message content. DLP detects the oversharing condition in either the message or an attachment and the user is forced to take action before they can send the message.

DLP policies have always been able to detect and block oversharing of email. What’s different here is that DLP checks happen during message composition instead of the user sending the message and receiving a non-delivery notification because a DLP policy detects a violation and blocks the message. Of course, oversharing of email protected by a sensitivity label might not matter all that much if the rights granted in the sensitivity label don’t allow the external recipient to read the content. The value of the policy tip is that by proactively highlighting the issue, the user can take action to avoid problems detected by DLP. For instance, they could choose a different label for the message (and justify the downgrade).

Microsoft documents an example DLP policy to explain how the oversharing policy tip work. They document the steps for creating a policy with both the Microsoft Purview compliance portal and PowerShell. Despite my affiliation for PowerShell, I wouldn’t do anything with DLP rules through PowerShell because of the relative complexity of rule construction.

Testing DLP Oversharing Popups

After creating a DLP policy with a rule to check for the presence of sensitivity labels on email addressed to non-internal domains (Figure 1), wait about an hour to allow the policy information to replicate.

You’ll know that the rule works if you see a policy tip when composing a message to an external recipient and the message or any attachment has one of the sensitivity labels specified in the rule. Figure 2 shows a message assigned the Public sensitivity label, which isn’t covered by the rule. However, the attachment has the Confidential sensitivity label (you can’t see this, so you’ll have to trust me), so DLP detects a violation and displays the policy tip to say that the recipient isn’t authorized to receive this information.

Attempts to send the message fail and Outlook displays a pop-up to tell the user why (Figure 3). OWA displays a similar prompt. In both cases, the user must take action before they can send the message.

It’s possible that a user will send a message with one of the sensitivity labels defined in the policy from Outlook mobile. It’s also possible that a user will send a message before the DLP code in Outlook or OWA detects a problem. In these instances, the Exchange transport service imposes the general block on sharing messages with the specified sensitivity labels and rejects the message.

The Power of Policy Tips

Allowing users to correct potential errors when they compose email is a good idea. Apart from anything else, it helps reinforce the idea that email can contain confidential and sensitive information that shouldn’t go outside the organization. I’s much more powerful when users see policy tips that help amend behavior than simply having their email rejected for some inexplainable (to them) reason.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Especially for Those Who Write About Technology

Like everyone else who writes about Microsoft technology, I could get upset by the latest outbreak of branding mania which brings us the Microsoft Purview suite. The grand pronouncement telling us that the future of compliance and data governance is here left me cold.

The announcement features the normal Microsoft mix of new names, previously announced stuff (like co-authoring of protected documents on mobile devices), extensions for existing capabilities (like 51 new sensitive information types for use in DLP and auto-label policies), and genuinely-interesting advances (like multi-stage disposition for items at the end of their retention period). The latter is due in public preview in May 2022. In essence, you’ll be able to apply a new retention label to items automatically when the retention period of the original label expires and set off a new retention cycle. And yes, this will require a high-end license.

Bringing Purview Together

At first glance, you might conclude that Microsoft assembled an array of loosely-connected add-ons and existing capabilities and applied Microsoft Purview as a common prefix. Some have called the resulting suite “Purview for E5” on the basis that you need Office 365 E5 or other high-end licenses to use its capabilities. I can see how this feeling might exist because many of the services do require high-end licenses. However, some do not, like Microsoft Purview Information Protection (aka MIP or sensitivity labels) or Microsoft Purview Data Loss Prevention (DLP), both of which deliver a lot of functionality to Office 365 E3 tenants.

Admittingly, both MIP and DLP have E5 caveats. Any automatic application of sensitivity labels through auto-label policies, trainable classifiers, or default labels ups the ante to E5, and while DLP is happy to process Exchange Online, SharePoint Online, and OneDrive for Business with an E3 license, ask it to consider information leakage in a Teams chat or channel conversation, and DLP demands E5.

The devil is in the detail when it comes to licensing any aspect of Microsoft 365 compliance, both in the past and heading into the Purview future, which is why it’s good to have a copy of the Detailed Microsoft Compliance Licensing Comparison XLS. The spreadsheet is dated April 2021, but that’s OK as it’s soon to be renamed the Microsoft Purview Licensing Comparison XLS…

New Sensitive Information Types

Running Get-DlpSensitiveInformationType now returns 262 sensitive information types published by Microsoft (or classifiers, as the new term seems to be), plus whatever custom information types a tenant defines. That’s a bunch of entities to test content against in DLP and other policies managed by Microsoft Purview Information Protection.

Revealed at Ignite 2021 last November, and available in tenants, the new sensitive information types include bundled and unbundled entities. A bundled entity is simply a collection of sensitive information types managed as a single type. For example, if you add the All Medical Terms and Conditions type to a DLP policy, DLP can detect any medical term or condition found in SharePoint, Exchange, and Teams content.

An unbundled entity is a sensitive information type that stands on its own. It can be used in a DLP policy to detect specific information, or it can be used as part of a bundled entity. For example, the Ireland Physical Addresses type is an unbundled entity, but it’s also part of the All Physical Addresses bundled entity. The update includes types to detect addresses in 38 countries and 10 specific types covering medical terms and conditions, like Blood Test Terms.

Being from Ireland, it’s natural to try out the Ireland Physical Addresses type. The (now renamed) Microsoft Purview Compliance portal offers the chance to test sensitive information types against input files. I created a text file with my home address in it, used it as input for a test, and was a little disappointed to find that the matches weren’t quite as good as I hoped (Figure 1).

Unlike other sensitive information types, which you can edit to see the criteria used for matching, Microsoft doesn’t support editing of the new types yet, so I couldn’t see how I could improve the test results. In any case, I’m sure the sensitive information type will be better in a policy, once I figure out what kind of policy to use it in.

And Now to Book Updates

Apart from documenting new functionality as it becomes available, the Office 365 for IT Pros eBook team also keeps our text current with Microsoft naming. Or at least, we do our best to. We’ve been through the recent Microsoft Defender rebranding and now we’ll update chapters to use all the approved Microsoft Purview product names. It’s a pain because the time spent chasing brand names takes away from the time available to investigate how Microsoft 365 works. Microsoft couldn’t be rebranding just to distract our attention, could they?

Handling Encryption, Signing, and Permission Controlled Email

A recent question in the Microsoft Technical Community about Data Loss Prevention (DLP) policies covered the difference between encrypted, permission controlled, and signed messages. In this instance, the DLP policy rule included an exception to allow a message containing some sensitive data to pass if encrypted. However, the exception wasn’t triggered for messages protected by Office 365 message encryption (OME) or sensitivity labels. The documentation covering email exceptions didn’t add much insight.

Email encryption has been around for years. S/MIME and PGP are two examples of commonly used email encryption technologies. First supported by Exchange Server 2003, S/MIME support for message encryption and signing is still available in Exchange Online, with the caveat that tenants must take charge of the details of deploying and managing S/MIME to users.

Microsoft acknowledges that its OME and sensitivity labels technologies are direct competitors to S/MIME. These products are based on Azure Rights Management rather than public key technology. For Office 365 tenants, Microsoft protection is easier to deploy and manage, and it can encrypt email sent to other Microsoft 365 tenants and external domains without the need for the receiving organizations to take any action.

It’s even possible to configure sensitivity labels to use S/MIME instead of rights management protection. This is a custom configuration for sensitivity labels that requires the unified labeling client (and Azure Information Protection licenses). I have never used this facility and do not know how well it works in practice.

Email Exceptions for DLP

All of which brings me to the set of email message type exceptions available for a DLP rule (Figure 1). When Microsoft started to develop service-wide Data Loss Prevention capabilities, the set of actions, exceptions, and conditions available for Microsoft 365 DLP policies was more limited for email than Exchange Online DLP. Over time, Microsoft 365 DLP processing capabilities became better and better. Building out the exceptions available in rule processing is an example of where improvements have occurred. A year or so ago, tenants could move their Data Loss Prevention focus away from Exchange Online transport rules (ETRs) to Microsoft 365 DLP without losing functionality.

Apart from wanting to maintain the same DLP processing for both on-premises and cloud email workloads, I don’t know of any obvious reason to continue using ETRs within Microsoft 365. That being said, some organizations have enormously complex DLP rules which require substantial effort to move to Microsoft 365 DLP policies. In some cases, these tenants will stay using ETRs until they’re forced to move.

What we learn from Figure 1 is that the available message types for DLP exceptions are:

• Signed messages (digital signature applied by S/MIME).
• Encrypted messages (S/MIME). See this Exchange 2010 documentation.
• Permission controlled (rights management).

Permission controlled is an odd term. I can understand why it’s used because rights management is all about granting permissions to users or groups to interact with content, but the term doesn’t tell the administrator that it means rights management. But it does, and despite the fact that rights management can encrypt email, using Encrypted as an exception won’t work for messages protected by OME or sensitivity labels.

Permission Controlled the Way to Go

For most organizations, the Signed and Encrypted message types are now firmly in the legacy category, and they’ll never need to deploy Data Loss Prevention rules to deal with these types. The majority will use OME and/or sensitivity labels and should therefore use the permission-controlled message type in DLP policy rule exceptions. I never knew this detail until now. Discovering new things about how Microsoft 365 works daily is one of the unique joys (or pains) of coping with the cloud. At least, I think it does…

Learn more about how the Office 365 applications really work on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Two Kinds of DLP

As you might be aware, two types of Data Loss Prevention rules are available for Exchange Online:

• Exchange Online Transport Rules (ETRs): Because all email must travel through the transport system, it made sense for Microsoft to use transport rules to implement DLP in Exchange 2010. ETRs are available for Exchange Server and Exchange Online.
• Microsoft 365 DLP: Otherwise known as unified DLP, this is the preferred approach for DLP within Microsoft 365 tenants, notably because this version is under active development.

When Microsoft first launched unified DLP in 2016, its Exchange capabilities were weaker than ETRs. This, plus a desire to have the same rules active within both on-premises and cloud sides of hybrid environments, made some customers reluctant to embrace unified DLP. Microsoft steadily closed the gap with ETRs over time and reached functional equivalence in 2020. For most organizations, unified DLP is the right answer when looking for a solution to block inadvertent sharing of confidential or sensitive information from SharePoint Online, OneDrive for Business, and Exchange Online. DLP also supports Teams messaging, but unlike the basic workloads, DLP for Teams requires Office 365 E5 or Microsoft 365 equivalent licenses.

Tweaking Continues

Some tweaking of unified DLP processing continues to improve its capabilities and performance. MC306117 (December 17) is an example. The change announced in this message center notification tells tenants that starting January 20, 2022 (presumably – the notice says 2021, but that seems like a year-end error), when DLP evaluates sender-based conditions for email, it will use header sender addresses instead of envelope sender addresses. This makes unified DLP work the same way as ETRs.

Sender Addresses

The change is sensible because most people consider envelope sender addresses when they think about rules they might want to apply. In the world of SMTP, messages have two parts:

• Envelope: Used by mail servers to route messages. The format of envelopes is defined in RFC5321, and the sender information is in the Mail From field. When email reaches its destination, the server discards the envelope and saves the Mail From address in the Return-Path message header.
• Message: Defined in RFC5322, SMTP messages have a bunch of headers and a body. Email clients display the From message header as the message sender.

There is no requirement that the Mail From address in the envelope matches the From address in the message. In fact, it’s very common that the two differ. Take the example of a company which uses a marketing platform like HubSpot to send email to mailing lists. The Mail From address in the envelope will be for a HubSpot server while the From address in the message will be whatever the company wants the message recipient to see.

Checking Who Sent Email

I don’t use my Exchange Online email address to sign up for email communications with many companies, so the number of messages of this type which arrive are limited. However, I found a message from Quest Software to illustrate the point (Figure 1). The sender information in the envelope is revealed by using Outlook’s Message Header Analyzer add-in. You can see that the Return-Path header is different to the sender information shown by the client.

In this instance, the change for DLP processing on January 20 means that DLP will evaluate sender address conditions against Quest@quest.com instead of QuestInc@innovation.quest.com. The change will happen automatically.

Microsoft says that organizations wishing to continue evaluating sender addresses based on envelope data will have the option to change the tenant DLP configuration (they don’t say how). They also say that organizations can configure DLP policy rules using the SenderAddressLocation parameter. This isn’t available yet, but if the same approach is used as for ETRs, the syntax will be:

# Update DLP rule to use both header and envelope sender info for evaluations
Set-DlpComplianceRule -Identity "Rule name" -SenderAddress Header Envelope HeaderOrEnvelope

The values are:

• Header: Use the From message header (new default from January 20).
• Envelope: Use sender information contained in the Mail From value in the message envelope (current default).
• HeaderOrEnvelope: Use both.

Overall, the change makes sense and shouldn’t affect too many organizations, but it’s something to test if your company uses Microsoft 365 DLP policies to process Exchange Online content.

Joins the Controls for Teams Meeting Recordings

Now that Microsoft has created the transition of storage for Teams meeting recordings (TMRs) from Stream (classic) to OneDrive for Business and SharePoint Online (ODSP), attention is focused on how to manage these files. Microsoft plans to introduce an auto-expiration policy for TMRs in January 2022 to allow organizations dictate how long these files exist in ODSP. The auto-expiration policy will work for any Microsoft 365 tenant which has licenses for Teams.

If you have Office 365 E3, users can apply retention labels to TMRs to gain more control over their retention, and if you have Office 365 E5 or Microsoft 365 E5 licenses, you can deploy an auto-label retention policy to find and label TMRs (and track the success of the policy in finding and labeling TMRs). In short, over time, organizations are gaining ways to exert compliance control over TMRs.

Blocking Sharing with Data Loss Prevention

Data Loss Prevention (DLP) for SharePoint Online and OneDrive for Business is included in the Office 365 E3 SKU. The value of DLP is that you can use a policy to protect against inadvertent data leakage caused when someone shares a TMR outside the organization. Imagine what would happen if a competitor got hold of a recording of a discussion, complete with slides, about the development of a new product!

Using much the same approach as taken to identify TMRs for the auto-labeling retention policy, we can build a DLP policy for TMRs which looks for recording files and stamps them with metadata to stop sharing happening. The DLP policy to block external sharing for TMRs is very simple. It is a custom DLP policy (i.e., not created using a template) consisting of:

• A name and description.
• Target locations. For maximum coverage, choose all SharePoint Online sites and OneDrive for Business accounts. This will stop any sharing of TMRs created for personal meetings (OneDrive) and channel meetings (SharePoint).
• A single rule. The rule looks for any file with the property value ProgId:Media.Meeting that is shared with someone outside the organization. The rule action blocks sharing with people outside the organization. Figure 1 shows what the rule conditions look like. Optionally, the rule can allow users to override the block by providing a justification to explain why they need to share a recording with an external person.

Other rule settings which you might consider include creating a custom policy tip to explain why users can’t share TMRs externally or generating an incident report to alert administrators or other people when a rule violation occurs.

The Effect of DLP

It can take up to an hour before a new DLP policy is effective. When the policy is active, the indexing process for new files detects that TMRs come within the scope of a policy and applies the policy settings to block external sharing. There might be a few minutes before the block is effective for a new file during which it’s possible to create and send a sharing link. However, once the block is in place, the sharing link is nullified.

The effect of the policy is obvious because any document which matches the policy conditions now has a small icon (circle with a line in the middle). In Figure 2, the icon is shown alongside all the TMRs in the Recordings folder. Other video files that don’t have the property set are not marked. Hovering over a TMR reveals information about the file, including a link to a DLP policy tip if set. In this case, the link reveals some custom text to explain that external sharing is not permitted for TMRs.

If the user ignores the warning and goes ahead to try and share the recording anyway, they won’t be able to do this because OneDrive for Business blocks the attempt to create and send a sharing link (Figure 3).

Easy Update

Even if internal users don’t often go back to relisten to what was discussed in a conference call, there’s no doubt that some external people might find that content interesting, perhaps even to the detriment of your company. The time required to create and deploy a DLP policy to block external sharing of TMRs is roughly ten minutes (including a pause to drink coffee). It’s a quick and easy update to make it easier to manage the security of information contained inside these files. This is a good example of the value of DLP.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Second Example of Trend Emerges with Offer to Use Communications Compliance

I don’t like the trend now emerging in Microsoft 365 Data Loss Prevention (DLP) where Microsoft uses DLP policies as a conduit to sell other Microsoft 365 solutions. A case can probably be made to extend a DLP policy to cover Teams, but the October 21 announcement in MC293000 that Microsoft will “surface” recommendations to use Communications Compliance within the DLP workflow (Figure 1) is a step too far.

You might think it is awfully helpful for Microsoft to make suggestions about making better use of DLP. This feeling would be justified if the recommendations improved DLP. However, as I point out when discussing the need to move away from Exchange DLP policies, extending a policy to Teams is not something which can often be done automatically. Likewise, gaining “the ability to apply DLP policy insights to your insider risk practice to better identify user behavior and intent” by configuring a communications compliance policy is not something that should happen as the result of a prompt at the end of updating a DLP policy.

Monitoring Communications

Communications compliance policies monitor interactions between people to detect problems like using offensive or threatening language. The communications covered are email, Teams, Yammer, and Skype for Business conversations (soon to disappear). For Teams and Yammer (only networks configured in Microsoft 365 mode), monitoring happens against the compliance records captured in Exchange Online. Matching occurs using one or more of the trainable classifiers available within a tenant (Figure 2), including those configured by the tenant.

Since the launch of communications compliance in 2019, Microsoft has done a good job of building out the set of available classifiers and expanding language coverage. The image classifiers are language independent. Classifiers won’t catch everything, but they improve over time and the idea is to detect gratuitous and persistent offenders rather than picking up every conceivable issue.

Policy matches result in referrals to human reviewers to check the content and context of the problem messages. The reviewers can decide if a policy violation is present and if so, how best to deal with the offender. All of which is grounded in an organizations HR policies and procedures, and probably heavily influenced at a local level.

There’s lots to like about communications compliance and it’s a good solution for Microsoft 365 to offer. However, this is not a solution that every organization needs or is comfortable with. Communications compliance has a hint of big brother is watching you about it that makes many people uncomfortable. Its implementation requires careful planning to ensure that the organization is prepared and that everyone involved in policy creation and operation from HR to reviewers to managers understand their roles and how to deal with offenses. This is not a project to start on a whim.

Inappropriate Connection

All of which makes me think that it is inappropriate for Microsoft to link DLP with communications compliance. There’s too big a jump between monitoring for inadvertent disclosure of sensitive corporate information outside the organization (the normal DLP scenario) to checking internal communications to detect violations in tone and language. I don’t see the natural connection between policies largely under the control of IT (DLP) and those where HR has huge influence and oversight.

One thing that links both suggestions Microsoft surface within DLP is that they need Office 365 E5 or Microsoft 365 E5 Compliance licenses. Office 365 E3 covers DLP for Exchange and SharePoint, but you need E5 for Teams (a differentiation that’s always seemed strange and inexplicable). Communications compliance is a premium E5 feature. I hope that Microsoft isn’t simply using DLP to push higher-price features to customers. That’s a tactic which might seem reasonable inside Microsoft, but it’s just tacky out in the real world.

PS. Microsoft will run a webinar about moving Exchange DLP policies to Microsoft 365 DLP policies on November 9. Register here.

Keep up to date with developments in compliance and other areas of Microsoft 365 by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

A Nice Idea, But Think Before You Enable the Policy

I’m sure many who read message center notification MC244891 (17 March) about a new Teams DLP policy recommendation widget didn’t think twice about the post. It’s just another recommendation made by Microsoft when an administrator goes to the Compliance Center to do something. Most of the time, these recommendations are candidates for quick dismissal because you want to do something else. Occasionally, they are helpful.

In this case, roadmap item 70731 tells us that the widget detects when an organization is using Teams but isn’t using DLP polices. When this happens, the widget helpfully suggests that it can create a pre-packaged Teams DLP policy to protect a range of personal (PII) and financial data sent in Teams chat and channel conversations (Figure 1). The usual types of sensitive data that people usually worry about are protected: credit card numbers, SSNs, passport numbers, and so on.

If the recommendation to turn on the policy is accepted, the widget creates the DLP policy. Administrators can tailor the new DLP policy to meet organizational requirements before activating the policy. For instance, they could add some more sensitive information types to the policy (over 200 standard types are available), including custom types defined by the organization.

The widget is rolling out now and deployment is due to complete in mid-April. Tenants like mine with Teams DLP policies already active won’t see the widget.

The Downside

It’s a good idea to help customers to protect sensitive data. Certainly, the chatty nature of Teams lends itself to an informality which is sometimes not present in other communications, and it’s possible that this might result in some people rushing to send credit card or passport numbers to each other. If this is true in your organization, the pre-packaged Teams DLP policy will stop these bad habits dead.

However, the downside is that Teams is an outlier when it comes to DLP licensing. Unlike Exchange Online and SharePoint Online, both of which support DLP policies with Office 365 E3 licenses, Teams software licensing demands Office 365 E5. It’s an example of how confusing the rules governing Microsoft 365 licensing can be for customers to navigate.

In any case, if you decide to accept Microsoft’s recommendation to create the Teams DLP policy, remember that you’re incurring the requirement to have the appropriate licenses for every user covered by the policy.

The Office 365 for IT Pros eBook team think about the upsides and downsides of details within the ecosystem. It’s the reason why the updates for our book are so worthwhile.

Teams and DLP (and now OneDrive too)

Updated February 24, 2021

Almost two years ago, Microsoft added Teams to the workloads supported by Data Loss Prevention (DLP) policies (Figure 1). For Teams, DLP checking occurs after users send messages to chats or channels. Offending messages are blocked, sometimes after a short delay. The system works well, but whether it is worth spending extra for Office 365 E5 licenses is debatable (DLP checking for Exchange Online and SharePoint Online is covered in Office 365 E3).

In any case, message center update MC234475 published on January 15 says that “DLP for Microsoft Teams will soon support security groups and distribution lists as part of the Teams location picker.” (Microsoft 365 roadmap item 68874). Rollout is scheduled for mid-February with completion worldwide in mid-March.

Upgrading the Teams Location Picker

The title used for MC234475 is a tad obscure for even those accustomed to working with DLP policies. The Teams location picker is a Microsoft term for the UI component used to select the Teams user accounts to include or exclude in a DLP policy. Teams shares its location picker with Exchange Online while SharePoint and OneDrive for Business, which operate based on site URLs, have a different picker. Many DLP policies operate on a whole organization basis, meaning that no accounts are explicitly included or excluded as the DLP policy applies to every channel and every user in the organization. In these cases, you don’t worry about the location picker because it’s not used.

Things are more problematic when different policies are deployed to different user groups within an organization. Now the location picker is used to select which accounts come within the scope of a DLP policy. Exchange Online has always used distribution lists to select accounts to set the scope for policies, but up to now compliance administrators were forced to select individual accounts for Teams DLP policies (the Teams locations). The change being made in the Teams location picker allows administrators to select distribution lists and mail-enabled security groups instead of individual accounts (Figure 2).

Because distribution lists and mail-enabled security groups can contain more than accounts, Teams applies a filter to select only Teams-enabled accounts from the membership.

DLP Used in Large Organizations

Being able to use distribution lists and security groups to select the target accounts for DLP policies is a welcome update because it is much easier to add one or two distribution lists to a policy instead of finding and adding potentially hundreds of individual accounts. In addition, being able to specify distribution lists and mail-enabled security groups instead of individual accounts removes the previous limit of 1,000 individual accounts that could be added to a Teams DLP policy.

Microsoft said that Teams is used by 93 of the Fortune 100 in March 2020. Given that Teams had 44 million active users then and the latest data (October 2020) says Teams has 115 million daily active users, it’s obvious that a bunch of large organizations use Teams. Those are exactly the kind of tenants likely to use DLP to help control the sharing of confidential data. It’s also reasonable to assume that these tenants will be interested in granular control over policy scope (for instance, to apply a policy on a country or department-level basis) and therefore use the Teams location picker. Being able to use distribution lists or security groups reduces administrator workload and avoid the need to use PowerShell to update the Teams location in DLP policies when large number of accounts need to be added.

List and Group Updates Handled

Even better, if you use a distribution list or security group to define the scope of a Teams DLP policy, a background process keeps an eye on the membership of the list or group so that if accounts are added to or leave the list or group, the DLP policy is automatically adjusted to reflect the membership changes.

Picker for OneDrive for Business Accounts

Microsoft 365 notification MC241352 published on February 24 brought further good news in that the picker for OneDrive accounts in DLP policies will support distribution lists and security groups from March 2021 (Microsoft 365 roadmap item 70708). Exactly the same reasons exist why this is a welcome update.

DLP is covered in Chapter 22 of the Office 365 for IT Pros eBook. It’s not the most compelling topic we cover, but it is technically challenging and interesting in its own right.

Sensitive Information Types for Use with DLP

Data Loss Prevention (DLP) isn’t the most exciting topic, but it’s an important way to protect sensitive information stored in Exchange Online, SharePoint Online, OneDrive for Business, and Teams. Office 365 E3 licenses are needed to use DLP policies. The exception is Teams, which for some bizarre reason requires Office 365 E5.

Matching Sensitive Data

The foundation for DLP is the ability to find sensitive information within items. Microsoft 365 does this by scanning items for matches against definitions of sensitive information types as items are added to workloads, mostly when new or changed information is indexed.

The definition for a sensitive information type is a pattern identified by a regular expression or function. For instance, credit card numbers are matched if a fourteen or sixteen digit number is found which complies with Luhn’s algorithm (also used to check other sensitive information types like Canadian Social Security numbers). Additional confidence during the matching process is gained by the presence of other evidence close to the matched term. For instance, the word “Visa” or “MasterCard” close to a number which passes Luhn’s test increases the percentage chance that the number is a credit card.

Organizations can create their own sensitive information types to match information specific to their business, like customer numbers or project identifiers. These definitions join the set of common sensitive information types defined by Microsoft for use in DLP policies.

New Sensitive Information Types

Office 365 notification MC230755 published on 18 December brings the news that Microsoft has added 49 new sensitive information types to its set, which now includes 201 definitions. The new sensitive information types are now rolling out.

The definitions of sensitive information types created by Microsoft are described online, including the pattern and keywords used in the matching process. You can also get a quick count of the current set by running the Get-DlpSensitiveInformationType cmdlet. In this case, we see the 201 standard Microsoft definitions and 3 added by the organization:

$Dlp = Get-DlpSensitiveInformationType
$Dlp | Group Publisher | Format-Table Name, Count

Name                              Count
----                              -----
Microsoft Corporation               201
Office 365 for IT Pros                3

Microsoft says that the new definitions “unbundle” European Union definitions for driver’s license, passport, and social security numbers. In other words, instead of using generic definitions for these types, country-specific definitions are available for individual European Union countries like Latvia, Hungary, and Luxembourg (Figure 1).

If you’ve been using the Euro definitions in DLP policies, Microsoft recommends that you consider upgrading to country-specific sensitive information types if available to increase the accuracy of matching.

We cover DLP in Chapter 22 of the Office 365 for IT Pros eBook. Subscribe now to stay up to date with changes across Office 365. Our monthly updates will surprise and delight you!

Windows 10 and Edge Deliver Signals for DLP Evaluation

Announced as Generally Available on November 10, Endpoint DLP is a Microsoft 365 offering which uses signals generated by actions performed on Windows 10 workstations to evaluate against DLP policies. Supported actions include copying files to removable media like a USB or to a network share, printing files, uploading to a cloud app, or copying data to the clipboard.

Microsoft leverages its control of Windows and Edge by avoiding the need to deploy additional agents to monitor activity on a workstation. The necessary code to detect actions and submit them for DLP evaluation is incorporated into Windows 10 (version 1809 or later) and recent versions of the Edge browser.

Edge is the preferred browser because it understands how to respect endpoint DLP policies, and you can block other browsers from accessing files protected by policies. For instance, you could block Chrome or Firefox from opening a Word document if a specific retention label is present.

Not an Office 365 Feature

Before you can use Endpoint DLP, you need Microsoft 365 E5 licenses or either the Microsoft 365 E5 information protection and governance or compliance add-ons. This is understandable given that Windows 10 is bundled in the Microsoft 365 suite. Being able to gather information from Windows is a big part of the Endpoint DLP value proposition and it’s important that users have access to builds of Windows which include the DLP code. Having a Microsoft 365 license makes it more likely that users will be current, and not run something like an old Windows 7 or Windows 8 device.

Workstations used by licensed accounts can be onboarded (enabled) through the Microsoft 365 compliance center to start the flow of signals for DLP evaluation, unless they are already enrolled for Windows Defender, in which case Endpoint DLP works without any further configuration.

Looking for Violations

Once a workstation is enabled, actions taken by the user are monitored for potential violations against policy using the same kind of conditions as used to monitor Office 365 activity. For example, attempts to upload documents containing credit card numbers can be detected and stopped. Supported file formats include Office documents, PDF, text, and source code.

Endpoint DLP settings for the organization can be adjusted in the Microsoft 365 compliance center (Figure 1) to reduce the amount of noise in signals by excluding certain folders like the recycle bin, temp folder, or folders used for non-work files. It’s also possible to allow uploads to specific cloud services without generating a violation. Policy thresholds can be set to generate alerts when a large number of similar events happen. For instance, a policy could alert administrators if someone prints more than twenty documents assigned the Confidential sensitivity label.

Checking Devices

When Endpoint DLP is available in a tenant, DLP policies can be created for a target location called Devices, just like choosing SharePoint or Exchange as policy locations. The normal approach is to separate device policies from those used with Office 365 workloads, but you can combine them. Device policies have separate settings for restrictions to enforce when conditions are met (Figure 2).

Signals to SIEM

Apart from being used by DLP, the signals generated by devices can be gathered and analyzed in a SIEM. An example using Azure Sentinel is described in this article.

Good for Some Organizations

Some organizations will like Endpoint DLP very much. Others will not be interested because of the cost of Microsoft 365 licenses, presence of non-Windows devices, or because they’ve invested in other solutions. In either case, this is an area that’s worth keeping an eye on because the signs are that Microsoft is taking advantage of its Information Protection, Office, and Windows assets to create a compelling unified DLP story.

For more independent information about Endpoint DLP, read this article by MVP Anders Onevinn.

For more information about DLP for Office 365 workloads (Exchange, SharePoint, OneDrive, and Teams), read chapter 22 of the Office 365 for IT Pros eBook.

Exploit Sensitivity Labels to Protect Confidential Material Stored in SharePoint Online

If you assign sensitivity labels to critical documents stored in SharePoint Online or OneDrive for Business, you probably don’t want users to share those documents with external parties. It’s possible to restrict sharing at the level of a SharePoint site or tenant to stop documents being shared externally, but that will stop all sharing. Being able to pinpoint and block specific documents is better, especially when someone has made a judgment that a document needs to be protected by a certain sensitivity label. Of course, if the sensitivity label invokes encryption, the recipient might not have the rights to access the content, but it’s better when the block is imposed by the service and the intended recipient doesn’t get a chance to inspect document metadata (title, etc.), which might reveal something of its content.

Last July, Microsoft introduced the initial support in DLP policies for sensitivity labels using checks against the managed property defined in the SharePoint Online schema used to hold the GUID of a sensitivity label. The property is called InformationProtectionLabelId and the check is performed against a document property in the form InformationProtectionLabelId:Guid. For example:

InformationProtectionLabelId:9ec4cb17-1374-4016-a356-25a7de5e411d

In an announcement posted on November 10, Microsoft confirmed full support for sensitivity labels in DLP policies. This means that instead of using a document property, you can specify that the content contains a sensitivity label in the same way as the policy can check for the presence of a sensitive data type (like a credit card number) or retention label.

Simple DLP Policy

A simple DLP policy illustrates the point. The policy needs one rule with two conditions and an action:

• Condition 1: Content contains a retention label, sensitive data type, or sensitivity label. Select sensitivity label and then select the sensitivity label to check (Figure 2).
• Condition 2: Content is shared with someone outside the organization.
• Action: Block access to people outside the organization.

You can decide to apply the policy to selected sites or all sites in the tenant. I elected to use all sites because it means that documents marked as Ultra Confidential cannot be shared externally from any site, including new sites added after the policy becomes active.

The Block in Effect

After the DLP policy is published to SharePoint Online, any attempt to share a document with the Ultra Confidential label will proceed as follows:

• User will be able to create and send a sharing link to an external recipient as normal.
• DLP will detect that a link has been generated and block sharing (no further external sharing is possible). The sharer will receive notification that sharing is blocked (Figure 3). At this point, the sharer should probably tell the external person that the sharing link won’t work because…
• If the external person tries to access the document, they’ll be informed that they can’t.

Using Auto-Label Policies To Find and Label Documents

Another way of approaching the problem is to use an auto-label policy to search for documents with a specific characteristic and apply a label to protect the document. This works well, providing that you’re willing to pay for Office 365 E5 licenses to use auto-labeling policies. The technique described above works with Office 365 E3.

Another point to remember is that the most important and critical information in a company often cannot be easily found by auto-labeling. Some human intervention is needed to decide just how confidential a document is and what the appropriate level of protection should be. And when someone applies a highly confidential label to a document, it’s nice that you can then stop external sharing with such a simple DLP policy.

DLP policies are covered in Chapter 22 of the Office 365 for IT Pros eBook. We cover sensitivity labels in Chapter 24. Lots of information to learn from!

Old Security and Compliance Center Split in Two

Office 365 Notification MC202599 posted on January 30 tells tenants that the Microsoft 365 compliance center and Microsoft 365 security center portals are being rolled out in February 2020 with worldwide completion by early March. These portals were originally announced in April 2018 and have been significantly upgraded since (see this post for a discussion of some shortcomings that existed in the preview versions about a year ago). Tenants with Microsoft 365 subscriptions already have access.

The new portals will replace the Office 365 Security and Compliance Center (SCC) introduced in 2016. Microsoft is dividing the functionality found in the SCC across two portals to better reflect the work done in each. It’s a reasonable thing to do considering:

• The number of new features added in the security and compliance areas since 2016 (like sensitivity labels) and the expansion of functionality to handle extra workloads. The SCC was becoming a catch-call for anything remotely connected to security, compliance, or data governance.
• Although administrators might do everything in small tenants, in larger enterprises a division of work often exists and those who handle compliance issues tend not to be the same people who deal with tenant security.
• Many enterprises have upgraded their subscriptions from Office 365 to Microsoft 365. The new portals deliver a common interface for security and compliance work across all areas of Microsoft 365. At least, that’s the vision.

Not Quite Ready for a Total Switchover

The SCC will remain available at https://protection.office.com/homepage for some time to come because not all of the functionality available in it has been transferred to the new portals. It takes time to untangle everything and move code to the new locations, which is why the Microsoft 365 compliance center has a link to the SCC. At this point, the compliance center seems more complete and useful than the security center.

I don’t really have strong feelings about the change. To me, it’s more important that features work all the time, something that could never be said of the SCC in the past. While acknowledging the difficulty of slip-streaming functionality into a portal at a hectic rate, the sad lack of attention to detail was distressing at times. Recently, the SCC seems to have settled down, perhaps because the developers left it alone while they concentrated on the new portals.

Let’s hope that the quality of the new portals is better than the SCC and that Microsoft focuses effort into making sure that all the basic functionality works robustly instead of new and glitzy features like the compliance score. I consider it strange that 75% of a possible maximum score is gained by Microsoft managing controls as a cloud provider (Figure 2).

It’s also annoying that many of the rating used to increase the score could be automatically calculated and are not. For example, the improvement actions include advice such as “implement spam filter” (isn’t that what Exchange Online Protection is doing?) and “implement ATP safe links” (ditto) and “black legacy authentication (has Microsoft looked at the settings active in the tenant?). Oh well, things will improve over time. Won’t they?

The advent of the Microsoft 365 Security and Compliance portals brings joy to the hearts of book authors. We have to refresh all our content to make sure that we refer to the right option in the right portal when we describe functionality. Expect the switchover to happen in the Office 365 for IT Pros eBook over the next few monthly updates.

Nasty Language Now Detected in Email and Teams

In March, I wrote about the update to Office 365 supervision policies to support monitoring of Teams communications in personal and channel conversations. Supervision policies are an Office 365 E5 feature and not every organization feels the need to check email and Teams to ensure compliance with company or industry regulations, but it’s an important part of data governance in some industries.

Recently, in another example of how Microsoft uses the cloud to bring machine learning and artificial intelligence into their products, supervision policies acquired the ability to use data models to check messages. The first data model is “Offensive Language,” which covers a wide range of conditions, including slurs, taunts, racism, homophobia, profanities, and taboo terms designed to help organizations implement anti-harassment and cyber-bulling in the workplace.

Adding the Offensive Language Data Model to a Supervision Policy

Adding the Offensive Language data model to a supervision policy is easy. When creating or editing a policy, you chose what communications to review, including the conditions to select messages. All you need to do is set the Use match data model condition checkbox (Figure 1).

Testing the Policy

After saving the policy, the next thing is to test its effectiveness. This is more easily done with email because Office 365 captures copies of messages for supervision immediately while it takes Teams up to 24 hours to do the same.

Messages selected for supervision are kept in special mailboxes and processed there by reviewers using OWA or the Supervision section of the Security and Compliance Center (Figure 2). Reviewers must decide if the messages picked up by a policy are compliant or non-compliant. Anyone who sends a message containing offensive language to other people needs some counseling. Ideally, the organization should have well-documented and clear procedures to report issues detected through supervision policies to line managers and HR for further action.

Blatant examples of grossly offensive language are picked up without a doubt (for instance, calling someone a f***ing idiot in email) as are messages containing specific keywords (like “homos”). Other messages get through that some might find offensive (you’ll have to do your own testing to find out), but might be caught in time as the learning model is refined to understand the kind of language used in the organization. At least, the great promise of artificial intelligence and machine learning is that administrators don’t have to keep on updating policies to take account of changing circumstances (new forms of insults, for instance). We shall see over time.

English Only

The current data model only handles English language terms. It will take time for Microsoft to build the models to handle offensive language in the many languages supported by Office 365, including regional variations used in the 240+ markets where Office 365 is sold. In the meantime, any local patois won’t be detected by policy, even if it is utterly offensive.

Along with a ton of other information about auditing, supervision policies are covered in Chapter 21 of the Office 365 for IT Pros eBook.

Automated Policy Creation to Protect Sensitive Information

Microsoft currently offers Office 365 tenants the opportunity to preview a new version of the Office 365 Admin Center, which is expected to replace the current version later this year.

The new portal was on full display at the Ignite 2018 conference last September, and at the time Microsoft demonstrators promised me that we’d see automated suggestions surface in the portal to help tenant administrators get to grips with the range of functionality available to protect data. Remember that Microsoft gathers an enormous amount of signals about the content users create (something they need to be careful about in the era of GDPR), so they have masses of data to analyze to understand where improvements might be made.

This week, the first suggestion popped up in the Office365ITPros tenant when the portal offered us the opportunity to protect sensitive data better. In fact, a Data Loss Prevention (DLP) policy would do the trick.

Curious Choice for Data to Protect

When I examined the recommendation, I discovered that the Admin Center was concerned that my tenant wasn’t doing a good job of protecting content holding the U.S. Individual Taxpayer Identification Number (ITIN) sensitive data type (one of the standard types available in Office 365).

The suggested settings seemed OK, so I clicked Create policy to see what would happen. After all, it couldn’t do any damage, could it?

Slight Error. Please Retry

Unhappily, the new Office 365 Admin Center was unable to create the DLP policy. Such is life and errors like this are prone to happen in preview releases.

You can expect Microsoft to continue to deliver automated suggestions through the Office 365 Admin Center to help administrators do a better job of managing their tenants. It will be interesting to see how far Microsoft goes with their suggestions and how tenants react to what’s suggested.

While we’re waiting for Microsoft to complete the new Office 365 Admin Center and improve the automated creation of DLP policies, why not read Chapter 22 of the Office 365 for IT Pros eBook to learn how to create policies manually.

Protecting Sensitive Email

Let’s assume that you want to make sure that outbound email containing sensitive data is always encrypted using the (relatively new) Encrypt rights management template. Office 365 includes a wide range of default sensitive data types created for data loss prevention (DLP) policies. You can define your own sensitive data types if necessary.

You could, of course, rely on users to know when they need to apply the Encrypt template to messages (via OWA and Outlook, but not mobile clients), but it’s usually better to make the process automatic. You can do this with a transport rule or a DLP policy. Both can be created through a GUI (the Exchange Administration Center for a transport rule and the Security and Compliance Center for a DLP policy), but where’s the fun in that?

Using a Transport Rule for Encryption

Any sensitive data type known to the tenant can be used in a transport rule to identify messages for protection by including it in the MessageContainsDataClassifications parameter. Here’s a simple PowerShell example that looks for six different sensitive data types. If any are found in a message, Exchange Online applies the Encrypt template.

New-TransportRule -Name "Encrypt external email with PII content" -SentToScope NotInOrganization -ApplyRightsProtectionTemplate "Encrypt" -MessageContainsDataClassifications @(@{Name="ABA Routing Number"; minCount="1"},@{Name="Credit Card Number"; minCount="1"},@{Name="U.S. / U.K. Passport Number"; minCount="1"},@{Name="U.S. Bank Account Number"; minCount="1"},@{Name="U.S. Individual Taxpayer Identification Number (ITIN)"; minCount="1"},@{Name="U.S. Social Security Number (SSN)"; minCount="1"}) -Mode Enforce

Using a DLP Policy for Encryption

Alternatively, you can create a DLP policy that applies a template when messages are shared outside the organization. Two steps are needed to do this in PowerShell. The first creates a DLP policy; the second creates the rule to encrypt email with the same set of sensitive data types specified for the transport rule and attaches the rule to the policy.

New-DlpCompliancePolicy -Name "Encrypt external sensitive mail" -ExchangeLocation "All"

New-DlpComplianceRule -Name "Encrypt external email with PII content" -Policy "Encrypt external sensitive mail" -AccessScope NotInOrganization -EncryptRMSTemplate "Encrypt" -NotifyUser "LastModifier" -NotifyPolicyTipCustomText "This email contains sensitive PII information and will be encrypted when sent." -NotifyEmailCustomText "This email contains sensitive PII information and will be encrypted when sent." -ContentContainsSensitiveInformation @(@{Name="ABA Routing Number"; minCount="1"},@{Name="Credit Card Number"; minCount="1"},@{Name="U.S. / U.K. Passport Number"; minCount="1"},@{Name="U.S. Bank Account Number"; minCount="1"},@{Name="U.S. Individual Taxpayer Identification Number (ITIN)"; minCount="1"},@{Name="U.S. Social Security Number (SSN)"; minCount="1"})

Choose How to Encrypt

As you can see, Office 365 offers several ways to apply encryption via policy to outbound email. It’s important that you choose either transport rules or DLP policies to protect sensitive data as it is easy to cause confusion if protection is applied for the same content using multiple methods.

We cover transport rules in Chapter 17 of the Office 365 for IT Pros eBook, DLP policies in Chapter 22, and rights management templates in Chapter 24.  You might say that we have this topic covered…

Phone Numbers Get in the Way

A Petri.com article explains how the new GDPR Data Loss Prevention (DLP) template ran into some problems because its rules blocked perfectly legitimate email due to the presence of phone numbers in user autosignatures.

Mail autosignatures carry a lot of information about people – their name, position, company name, business address, phone numbers and sometimes even company registration numbers. It’s genuinely hard to come up with rules that pick out personal data to block the transmission of this information outside the company while letting normal business communications flow unimpeded. Microsoft made the rules in the GDPR DLP template a little too sensitive, which caused email to be blocked.

Of course, people might ask why testing didn’t catch a problem like this. There’s no good answer to that question except to say that the diversity of autosignatures and the range of information carried in autosignatures is pretty large. The full spectrum of what you might find across 28 EU countries might not have been included in the test suite.

Central Cloud Deployment

One of the nice things about the cloud is that changes can be made centrally and then picked up by tenants without administrator intervention. Microsoft is tweaking the rules in the GDPR template to make them less sensitive to phone numbers. You can expect the fix “soon.”

DIY Sensitive Data Types

You can try your hand at defining your own custom sensitive data types through the Classifications section of the Security and Compliance Center. We explain how in Chapter 22 of Office 365 for IT Pros, along with a heap of other information about how DLP policies work and how to deploy them effectively.