Business and client needs for data loss prevention features are explored. Learn about scenarios for DLP rules and testing modes in Exchange Server 2016.
- [Instructor] The Data Loss Prevention feature of Exchange Server, is designed to identify emails that contain sensitive information and keep them from being sent. Before we get into how to create these rules, I do want to explore what it is that we hope to accomplish. Security features like certificates and encryption can prevent sensitive email content from being easily read by someone other than the intended recipient, but they do allow the email to be sent.
There are some types of information that may be considered inappropriate for email generally for this reason. Because it's protected proprietary information, or because it violates the privacy of an employee or customer. For example, it would be better if social security numbers and credit card numbers never find their way into an email. Design documents, and elements of your organization's strategic plan may be accessed by multiple employees internally, but should not be allowed to be sent through your Exchange server to an external recipient.
With DLP, you can create rules that will scan the contents of an email for numbers that look like credit card numbers, or other risks. Messages that trigger your rule can be blocked from ever leaving the sender's Exchange mailbox. If you're using Outlook, or Outlook on the web, this scan is done while the message is being composed. And before the user can even click send, they're notified, allowing the message to be rejected before it even reaches the Exchange server.
If your rules are properly planned and implemented, you can avoid the risk of credit card numbers being exposed through email. There is always the risk that a rule is not properly written, and there are two options that can be used to help determine whether you've written the correct rule. Test DLP policy without policy tips is an option that will let you log emails that trigger this rule, but take no action, this is only a test. Another option is to simply warn the user that the content of their message looks like something that should not be sent, but take no action to stop them.
Policy tips would work in Outlook or Outlook on the web, to notify the sender while they're composing their email that their content appears to be a violation. If the employee is using a different email client app, there will be no notification. This may be one reason to consider disabling IMAP and POPP, and other protocols that may be used by client applications other than Outlook. Sometimes you've written the right rule, but there needs to be an override.
One example of this might happen when a user is trying to email a 16 digit serial number to register a warranty for some new gadget. If that serial number looks like a credit card number, a rule that bans the transmission of credit card numbers could register a false positive. This option, to identify false positives, gives the user a chance to see the policy tip, say that it's a false positive, and allow them to send the message. Sometimes, when the rule accurately identifies a risk, there still could be a legitimate reason for someone to email, say, a credit card number.
The practice needs to be blocked generally, but maybe some executives should be given the option of stating their business reason and then be allowed to send the message anyway. If you walk down this road, train your users to keep in mind that once an email has been sent, it can be forwarded, printed, or saved for unintended use later. But if those risks are worth the benefit of some business purpose, a rule can be enforced with an allowance for an explicit business justification.
The sender will be required to type in their business justification. And that will be logged, and could be configured to send an incident report to an executive or to a network administrator. There is one other option, but I would strongly caution against it. A user can be allowed to simply override a DLP block, without giving a reason. Be careful with this option, as it does nothing to protect sensitive information from getting outside of your organization.
Overrides can generate incident reports to tell you about the override after the fact, but they don't prevent intentional distribution of sensitive company information. And I've mentioned credit card numbers as my example throughout, but rules can be made to identify a range of protected information, the DLP can help keep inside your organization. As we move forward, we'll take a look at some of those rules.
- Data loss prevention (DLP) solutions
- DLP solutions for business requirements
- Archiving and message records management
- Planning and configuring retention policies
- Assigning retention policies to users
- RBAC roles for eDiscovery
- Compliance solutions
- How to use MailTips
- Mailbox and administrative auditing