Executive Summary:
| In most companies, employees have a tool—email—that lets them send information outside the company. Unless you take precautions, that information might include sensitive data. Luckily, Microsoft Exchange Server 2007 has built-in tools and vendors offer third-party products that can detect and act on mail containing sensitive data before the mail is sent. Here is what you need to know before you start using such a tool or product. |
Sensitive data that the general public shouldn't see—such as HR data, pricing information, or intellectual property—exists in every business. If your business stores sensitive data electronically and your network is connected to the Internet, there's a chance that sensitive data might cross your firewall because most employees have a tool—email—that lets them send all kinds of information outside the company. Luckily, Microsoft Exchange Server 2007 has a built-in tool—Policy Management, which you can use to create Transport Rules to scan outbound email—and vendors offer third-party products that can detect and act on mail containing sensitive data before the mail is sent. However, before you start using such a tool or product, you need to understand the terminology, understand the ways in which these products work, and understand the importance of the human component.
Understanding the Terminology
Detecting and preventing data leaks is a relatively new concept that goes by many different names, including outbound content compliance (OCC), content monitoring and filtering, information leak prevention and detection, data loss prevention, data leak prevention, and extrusion prevention. I prefer OCC because it clearly states that we're looking to enforce compliance of security policies on data going outside the company.
Even more terms are used to describe the types of sensitive data that OCC products are designed to detect and act on. A general term that encompasses all the data you don't want leaking out is nonpublic information. Terms for more specific types of sensitive data include personally identifiable information, protected health information, personal financial information, Payment Card Industry (PCI) data, and company confidential data.
How OCC Products Work
If you're an Exchange or IT administrator, you're likely familiar with Information Rights Management (IRM), which is available in Microsoft Office 2003 and later. IRM lets you specify who can access and use documents and email messages. It also helps protect against unauthorized printing, forwarding, and copying. OCC differs from IRM in that OCC looks for the sensitive data as it is leaving the organization.
OCC products typically detect nonpublic information one of two ways: They can use described methods or registered methods. Described methods use regular expressions and advanced regular expressions to detect defined patterns (e.g., social security numbers, credit card numbers) in outbound data. Registered methods detect nonpublic information by checking outbound data against registered data to see whether there's a match. The registered data can be keywords, dictionaries (e.g., a dictionary of health terms), or even mathematical hashes. The latter is used in document fingerprinting.
In document fingerprinting, mathematical hashes (i.e., "fingerprints") are created for documents containing sensitive data. The documents can then be detected by their hash values. To detect documents that have been obfuscated, you can typically define a minimum amount of data to match so that a match still occurs when only a portion of a document is present.
Registered methods have greater accuracy than described methods. However, using both methods is your best bet because registered methods search for known data and described methods search for unknown data.
To find nonpublic information being leaked through messaging systems such as Exchange, OCC products can act as a monitor on a switch, a proxy, or a Message Transfer Agent (MTA) in an outbound SMTP path, each of which has its advantages. As a monitor on a switch, an OCC product can reset a connection when an incident occurs (i.e., nonpublic information is detected). As a proxy, an OCC product will have flexibility in how it responds to an incident because it's speaking to the destination on behalf of the client. As an MTA, an OCC product is the most flexible in terms of the actions it can take in response to an incident because the message is stored locally. Plus, there's no possibility that part of the message can be transmitted before sensitive data is detected because the message is stored on the MTA before the next hop.
How an OCC product looks for leaks determines the protocols that you can monitor. You’ll want to monitor any allowed protocol that people can use to send data outside the company. The most commonly monitored protocols are SMTP, IM, FTP, and HTTP Secure (HTTPS).
When OCC products detect an incident, they can take several types of actions. Often OCC products quarantine or redirect messages containing nonpublic information so that the messages can be reviewed. Redirection can also be used in conjunction with an encryption server. When a message with nonpublic information is being sent to a trusted destination, it can be rerouted through an encryption server, then sent to the recipient.
The Human Component
When you're deciding on the actions you want the OCC product to take in response to an incident, you need to take into consideration that most leaks are not malicious but rather inadvertent. Most users don’t understand their companies' security policies and are using outdated communication procedures. For this reason, auditing before acting is always advisable. Notifying users about their offending messages is important because it's your opportunity to educate users about the company's OCC policies and the consequences they'll face if they don't follow those policies.
After an incident occurs, action (other than an audit) has been taken, and the user has been notified, someone needs to manage the incident (e.g., determine what nonpublic information was involved, take steps to prevent future infractions). The responsibility for managing incidents might not fall on the shoulders of Exchange or IT administrators. Although Exchange and IT administrators are used to having full access to data, they might not have access to incident data because the data is confidential. Thus, sometimes a compliance team or HR manages incidents. Other times, managing incidents is a task shared among various teams, such as the Exchange, HR, and security teams.
When multiple teams manage incidents, assigning responsibilities becomes important. Many OCC products offer horizontal and vertical levels of permissions. When you delegate horizontal levels of permissions, you're determining what a person may view (e.g., incidents, policies, reports). When permissions are delegated vertically, you're determining what a person can do with what they see (e.g., modify policies, act on incidents, create reports). For example, you might determine that HR should be able to view incidents and policies but not modify policies.
Reporting on incidents is important. It shows management that the company's OCC strategy is working. It also aids in the OCC management cycle by helping the company fine-tune its OCC policies and actions. With OCC, fine-tuning is crucial because nonpublic information isn't easily categorized and constantly changes.
Only Part of the OCC Plan
Using an OCC product to detect and act on nonpublic information leaks in messaging systems is, of course, only one part of an effective OCC strategy. There are other ways in which nonpublic information can be leaked, so you need to identify all the types of nonpublic information your company needs to protect, where that information is stored, and how it might be leaked outside the company. User education needs to be a big part of your OCC strategy. Users need to know about your company's OCC policies and the consequences of not adhering to them. For more information about developing an OCC strategy, check out the Microsoft white paper "Meeting the E-Mail Compliance Challenge With Microsoft Exchange Server 2007" (http://www.microsoft.com/exchange/evaluation/compliance.mspx), Proofpoint's white paper "Outbound Email & Content Security" (http://www.proofpoint.com/resource-center), and Vontu's white paper "7 Requirements of Data Loss Prevention" (http://www.vontu.com/resources).
—Paul Lucido, Senior Messaging Engineer, Fidelity Information Services
End of Article
Register
