Exchange Server 2013 Data Loss Prevention

When I first learned about Microsoft's implementation of Data Loss Prevention (DLP) for Exchange Server 2013 (including Exchange Online) and Outlook 2013, I didn't think much of the feature. It didn't appear to offer much value for the average customer and depended on the deployment of a new desktop client. Plus, DLP wasn't supported by Outlook Web App (OWA), and there was no prospect of any mobile client supporting its features. All in all, I concluded that DLP wasn't very beneficial. However, depending on your need for this kind of technology, that statement might not be true. The implementation has some interesting aspects that deserve discussion and better understanding, which is my goal here.

DLP Isn't New

The need to prevent data loss (or leakage) is well understood, possibly because there have been many instances in which company or personal information has been compromised by being made public deliberately or accidentally. An interesting white paper from McAfee, "Data Loss by the Numbers," provides some graphic examples where millions of records held by large public companies were lost in some form. The result can be brand erosion, legal expenses, customer loss, and an almost guaranteed public relations disaster. So, taking action to protect data is of prime concern. A lot of the focus in the past has been on erecting and maintaining traditional security barriers. This might keep out hackers and scammers, but it does nothing to prevent employees from causing data loss, usually by accident. As McAfee's paper remarks, "While the total of insider incidents equated to 44 percent, the great majority were accidental."

DLP isn't a new technology. Vendors such as Symantec, EMC, and Cisco Systems have been offering DLP solutions to manage the disclosure of confidential information for years. White papers on the topic have been published for years as well. For example, the SANS Institute white paper "Data Loss Prevention" was published back in 2008.

In January 2013, Gartner published the Magic Quadrant for Content-Aware Data Loss Prevention, which tracks and analyzes vendors' DLP solutions in the email area. Tellingly, Microsoft doesn't appear in the magic quadrant. The version of DLP included in Exchange 2013 is Microsoft's first venture into the area, so you'd expect that some flaws and shortcomings exist, the most obvious of which is client coverage.

On the plus side, Microsoft's implementation builds on some existing strengths such as:

• The ability to direct every message in an organization through a known chokepoint (the Exchange transport pipeline), where the message content can be examined
• A highly functional desktop client that lends itself to built-in intelligent reviewing of content as it's typed by the user

Microsoft has extended the Exchange transport rules to incorporate the examination of confidential data en route through the transport pipeline. Microsoft also provides Policy Tips to help users understand when they might be including sensitive data in messages. Policy Tips look very much like the MailTips introduced in Exchange 2010/Outlook 2010.

It's important to understand that DLP isn't intended to monitor users' behavior and check the content of the messages they send. Other tools, such as transport rules, retention policies, and eDiscovery searches, are available to handle more direct forms of compliance. DLP is designed to help companies protect themselves by ensuring that employees don't include sensitive information such as social security numbers or credit card data inside email messages when they shouldn't be doing so. With that said, user education is part of DLP. If a DLP solution helps users understand when they might be doing something wrong, there's a higher chance that they'll do better in the future. This is assuming that the clients understand DLP policies and can signal errors when they occur. With that introduction, let's look at some of the details of how DLP is implemented in Exchange 2013 and Outlook 2013.

DLP Components

On the client side, you need to use Outlook 2013 Professional Plus to be able to:

• Use the XML package describing the DLP policy defined for the organization. Clients download the package from Exchange 2013 mailbox servers every 24 hours. The package specifies the types of sensitive data that shouldn't be included in messages and the action to take if sensitive data is detected.
• Examine text as it's typed into a message body by a user and recognize the types of sensitive data covered by the DLP policy. The text recognition engine is really quite impressive, as it can associate different pieces of text to determine a high degree of confidence that the text pieces, when taken together, represent sensitive data. For example, if a 16-digit number matches the Luhn algorithm, it could well be a credit card number. If a date that could be a credit card expiration date (e.g., 11/15) is also present, it represents additional evidence that the two pieces of text represent credit card data. Finally, if someone's name is also present close to the other pieces of text, then a high degree of confidence exists that sufficient information is there for a recipient to charge something to a credit card.
• Display DLP Policy Tips when sensitive data is detected to advise users that such data is present and what they should do about it. The Policy Tip might display a message that states the email can't be sent because of the type of data it contains, or the Policy Tip might just be advisory (e.g., "you shouldn't really be sending that kind of data"). It's also possible to allow users to override a policy by asking them to provide a justification for the override. That justification can then be sent along with information about the message to a compliance manager, who can take appropriate action after examining the full context of the message. For example, an HR representative might need to send a message containing a social security number from time to time. An override received from a HR representative is OK, whereas an override from an administrator working in another department who circulated some HR data might not be.

On the server side, Exchange 2013 provides the ability to define DLP policies through the compliance management section of the Exchange Admin Center (EAC). Underpinning EAC is a set of Exchange Management Shell (EMS) cmdlets such as New-DlpPolicy that you can use to programmatically create and control DLP policies should you prefer.

A DLP policy is essentially a container that holds a set of specialized transport rules that check messages as they pass through the transport pipeline. Transport rules have been around since Exchange Server 2007. They're an important part of the compliance landscape because they provide a guaranteed method to examine messages in transit to recipients inside and outside the organization. The set of conditions, actions, and exceptions that can be used in transport rules has been dramatically expanded since Exchange 2007 to add to the variety of situations that can be handled by transport rules. The integration of DLP policies has been achieved by adding the condition "if the message contains sensitive data" to check for a specified type of sensitive data and actions to take if the condition is met. Exchange 2013 is capable of examining message bodies and attachments for sensitive data.

Apart from the guarantee that all messages will be checked against DLP policies, the biggest advantage of using transport rules is that it's a solution that works across all clients. Even if you don't use Outlook 2013, you can still deploy DLP policies through transport rules. The end user experience will be less elegant, but the policy will work effectively and efficiently. However, you need to keep in mind that the Exchange 2013 mailbox servers must take over the responsibility of message transport for the organization. Neither Exchange Server 2010 nor Exchange 2007 transport servers know anything about DLP policies and have no visibility of the transport rules that implement the policies. Thus, any message that passes through a down-level transport server will do so unchecked. This is a small but important implementation detail that needs to be covered in any DLP deployment.

Sensitive Data Types

Creating a DLP policy involves knowing what kind of sensitive data you're interested in controlling. A number of common data types come to mind when you consider what kind of information you prefer users to not include in messages. I already discussed credit card numbers and social security numbers. Although credit cards use a worldwide format, personally identifiable information (PII) and other sensitive data types differ from country to country.

It wouldn't make much sense if Microsoft provided a virtual blank sheet for everyone to define their own view of sensitive data. Mistakes would be made and inconsistencies would abound. Fortunately, Microsoft has provided a set of out-of-the-box definitions for sensitive data that you can use immediately without having to figure out what essential characteristics might best describe some data formats. For example, there are definitions for:

• ABA routing numbers
• Credit card numbers
• U.S. Social Security numbers
• Canada bank account numbers
• European Union debit card numbers
• Australian passport numbers
• German driver's license numbers

Over time, it's likely that the inventory of sensitive data types will expand to cover other types of data used in other countries.

DLP Templates

A DLP policy is unlikely to cover a single sensitive data type. Typically, companies need to include multiple data types in their DLP policy. Although you can create a DLP policy from scratch to reflect the customized needs of a company, Microsoft provides DLP templates designed to help you build a DLP policy for common-use scenarios. Each template contains a set of rules to check for the data types that you might want to protect.

When you create a new DLP policy, you can choose a template and Exchange will populate the new policy from the information in the chosen template. You can alter the policy afterward by removing unwanted rules or adding new rules as your needs dictate.

Microsoft hopes that third parties will create suitable DLP templates for use in particular industries or circumstances. These templates can then be provided to customers in an XML format and imported to create a new DLP policy.

Let's walk through the process of defining a DLP policy using one of the standard templates provided by Microsoft. The steps are:

1. Determine the types of sensitive data to protect.
2. Create a new DLP policy.
3. Examine and test the DLP policy's rules.
4. Enforce the DLP policy and check the transport rules.
5. Audit the DLP policy.

Step 1: Determine the Types of Sensitive Data to Protect

The most basic step in defining any policy is to understand what the policy is designed to do. In this case, you want to protect the company against inadvertent disclosure of sensitive data, so the first step is to determine what types of sensitive data to protect. You then have to think about the conditions that you want to check for, whether any exceptions exist, and what action to take if a policy violation is detected. Because a DLP policy affects users, it's a good idea to get buy-in from the HR and legal departments, and inform users about the new policy when implementation time comes around.

Step 2: Create a New DLP Policy

After the need for a DLP policy is clearly defined, you can create it in EAC. Go to the compliance management section in EAC and click data loss prevention. As you can see in Figure 1, there are three ways to create a new policy: using a template, importing a policy, and creating a custom policy from scratch. In most circumstances, you'll start by selecting one of the standard templates provided by Microsoft, so choose the New DLP policy from template option.

Figure 2 shows the page you use to name the new policy and select the template that will populate the policy. For this example, enter DLP Consumer Protection and select the U.S. Federal Trade Commission (FTC) Consumer Rules template, which seeks to protect against the sending of consumer data such as credit card information. At the bottom of the screen, make sure that the Test DLP policy with Policy Tips option is selected so that Exchange creates the new policy in test mode rather than enforcing it immediately. This way, you can test the policy to make sure that the conditions and exceptions contained in the rules serve the intended purpose. In addition, immediately enforcing a policy might take users by surprise if Policy Tips start appearing in Outlook or messages are suddenly being rejected because they contain sensitive information. It's always best to prepare users before you make changes that affect the way they work.

Next, save the policy. When you do so, Exchange imports the rules specified in the template and creates them as new transport rules. These rules are associated with the new policy, but they function in the same way as any other transport rule.

Step 3: Examine and Test the DLP Policy's Rules

In EAC, you can select the new policy and view its properties to see the associated rules. Figure 3 shows that the DLP Consumer Protection policy imported five rules from the U.S. Federal Trade Commission (FTC) Consumer Rules template. This might come as a surprise because you might anticipate that a single rule can scan for sensitive data. It's absolutely correct that a single rule can instruct the transport engine to examine every message and attachment for sensitive data, but this isn't really a policy. When you think about it, a policy is likely to have some exceptions (e.g., people booking travel for other employees might need to transmit credit card information to outside vendors) and you might want to set boundaries for sending information. In other words, an employee might be allowed to include a single instance of a credit card number in a message, but you probably wouldn't allow that person to send details of more than a couple of credit cards. A single rule applies a black-and-white test for a condition. A set of rules allows greater flexibility in how the policy is applied in different scenarios.

Thus, this template provides rules to check for sending sensitive data inside and outside the organization and when an unsupported attachment type is detected on a message. The Exchange transport system uses filters provided by the Search Foundation to examine a very large number of different file formats, including PDF and all the Microsoft Office formats. This is designed to prevent users from attempting to circumvent checks by including sensitive data in an obscure file format.

Clicking a DLP rule exposes its properties. Figure 4 shows how these properties are displayed. The interface shouldn't come as a surprise if you've worked with transport rules in Exchange 2013 because it's identical to that used to build other transport rules. In this case, the important aspects are the condition "The message contains sensitive information" and the three types of sensitive information specified: credit card number, U.S. bank account number, and ABA routing number. You can also see that the rule is designed to process messages sent to external recipients (i.e., those outside the organization).

If you click the list of data types, EAC displays more information about them, as shown in the sensitive information types dialog box on the right side of Figure 4. This information provides guidance to Exchange when it examines message bodies and attachments by specifying how many instances of sensitive data must be detected before the rule fires. In this case, the minimum count for all three data types is 10, meaning that Exchange will only enact the rule if 10 or more instances of any of the specified data types is found in a message body or attachment. You can therefore conclude that the rule is intended to protect against scenarios in which someone attempts to send a list of credit card or bank account numbers to an external recipient.

As it happens, the rule copied from the template does nothing but create an audit entry of medium severity. In production, you'd probably want to add an action to block the message and provide a reason to the user to explain why the message couldn't be processed. This illustrates the need to carefully examine all the rules copied from a template to validate that they're suitable for your purposes before putting them into production. In other words, assume nothing just because a component is included with Exchange.

If the rule fires, the specified action is "Block the message but allow the user to override with a business justification and send." This action demonstrates how a rule can force a client to display a Policy Tip to users to inform them that they might be about to do something wrong. It's a client-side action, as the need for an override must be presented before the message gets to the transport system. Outlook 2013 learns about the types of sensitive data to check for and when it should display Policy Tips through two XML files named PolicyNudgeRules and PolicyNudgeClassificationDefinitions. The client downloads them automatically from the mailbox server every 24 hours.

Figure 5 shows what happens when Outlook displays a Policy Tip. In this case, Outlook has detected that a recipient on the message isn't entitled to receive the content because it contains some sensitive data. However, the rule allows the user to override the policy, so Outlook prompts for a business justification. The user can enter anything because the reason will be reviewed and hopefully audited at some point. Alternatively, the user can simply click the button to indicate that the message really doesn't contain sensitive content. (In other words, Outlook's deep content analysis failed for some reason.) In either case, once Outlook is reassured that the message is OK by the user, it will be processed and delivered by the transport system.

If you don't like the standard prompts used for Policy Tips, you can edit them in EAC. To do so, you can use the Customize Policy Tips option when editing DLP rules as explained in the TechNet Manage Policy Tips web page.

Finally, going back to Figure 3, you can see that the first rule in the template is named Allow override. This rule allows users to simply include the word Override in the subject of any message that they want to send that might contain sensitive data. Its effect is to stop DLP checking by setting the special X-Ms-Exchange-Organization-Dlp-SenderOverrideJustification property in the message header with the value "TransportRule override".

You might or might not want to include this rule in the policy that you put into production. Some people feel that it's an invitation to override and nullify the policy and prefer to have users be prompted for a business justification. However, the counterargument is that the rule allows users to override the policy when they send messages from clients that don't have the ability to prompt for a justification.

Step 4: Enforce the DLP Policy and Check the Transport Rules

After you've made sure that the conditions and exceptions contained in the DLP policy's rules serve the intended purpose and made any customizations you want, you can enforce the policy by selecting the policy and editing it to set the enforce check box.

Because DLP policies depend on transport rules, you have to make sure that the rules used by your DLP policy interact with other transport rules in the correct manner. When a new DLP policy is created, its rules are added to the end of the set of existing transport rules. You can see this in Figure 6, where two transport rules previously existed and occupy positions 0 and 1 in the rule priority order. (Position 0 is the highest priority.)

Let's assume that one of the previously existing rules contains the action to force the transport engine to stop processing further rules. If this was the case, the DLP rules would never be executed. This straightforward example demonstrates the need to think about the priority order for DLP rules and how they might interact with other rules.

Step 5: Audit the DLP Policy

Auditing is an important part of building effective policies. If you don't audit how a policy is working, you won't know if it's serving its intended purpose. Office 365 tenant administrators can access the Microsoft Excel Mail Protection Reports plug-in, which includes some DLP analysis. On-premises administrators can attempt to search message tracking logs for instances where messages aren't delivered due to agent intervention (which might or might not be due to a DLP rule). However, the easiest way to understand whether a DLP policy is working as designed is to add an action to the rules so that a copy of any message that violates the policy is sent to a nominated mailbox named incident manager. It's best to set up a specific mailbox to accept incident reports, as it then becomes much easier to review the reports that are subsequently generated.

Going back to the rule shown in Figure 4, you can click the add action button, select the Generate incident report and send it to action, then pick the mailbox to act as the incident manager. As shown in Figure 7, you can also select the message properties that you want to include in the incident report, including a complete copy of the original message and its attachments.

Figure 8 shows a sample incident report. As you can see, this report includes:

• The sender.
• The recipient.
• The message subject.
• The severity level as set by the DLP rule.
• Whether the user overrode the Policy Tip and the reason the user provided.
• The sensitive data type that caused the policy violation. In this case, a single credit card number was detected with a high degree of confidence (85 percent) that met the minimum standard for detection.
• The DLP rule that fired to generate the incident report.
• The actions invoked by the rule. In this case, the audit level was set, the sender was notified, and the incident report was generated.

Lots of information can be included in an incident report. Some of that information is private to the sender and recipient, which means that access to the incident manager should be controlled and restricted to those who need to know.

Changes in Exchange 2013 SP1

Exchange 2013 release to manufacturing (RTM) was the first version to include DLP. Therefore, it's no surprise that DLP in Exchange 2013 SP1 includes two important enhancements. The first enhancement adds the ability to display Policy Tips in OWA and OWA for Devices. The second enhancement allows organizations to add document fingerprints to DLP content analysis.

A document fingerprint is a digital description of a document such as a U.S. income tax return form. The idea is that you can scan a blank copy of any document that might be used to gather sensitive information and upload it to Exchange. Document fingerprints then become a sensitive data type like a credit card number and can be used in the same way as any other sensitive data type in a DLP rule.

A Valuable Technology for Some Companies

DLP in Exchange 2013 is an interesting technology that has been expanded and improved in Exchange 2013 SP1. Like any effort to create and implement a policy, some up-front thinking and work is required to determine the DLP needs and design how the needs can be met by the DLP policy. User education is also a prerequisite. Some companies might be uninterested in DLP for various reasons, but I suspect that those companies that have invested heavily in Microsoft technology and have deployed (or have plans to deploy) Exchange 2013 will find the DLP technology valuable.