Understanding Information Rights Management

Applies to: Exchange Server 2010

Every day, information workers use e-mail to exchange sensitive information such as financial reports and data, legal contracts, confidential product information, sales reports and projections, competitive analysis, research and patent information, and customer and employee information. Because people can now access their e-mail from just about anywhere, mailboxes have transformed into repositories containing large amounts of potentially sensitive information. As a result, information leakage poses a serious threat to most organizations. To help prevent information leakage, Exchange 2010 includes Information Rights Management (IRM) features which provide persistent online and offline protection of e-mail messages and attachments.

Contents

What is Information Leakage

Traditional Solutions to Information Leakage

Information Rights Management in Exchange 2010

Applying IRM Protection to Messages

Supported Scenarios for IRM Protection

Decrypting IRM-Protected Messages to Enforce Messaging Policies

Pre-Licensing

IRM Agents

IRM Requirements

Configuring and Testing IRM

What is Information Leakage?

Leakage of potentially sensitive information can be costly for an organization on multiple fronts and have wide-ranging impact on the organization and its business, employees, customers, and partners. Additionally, local and industry regulations increasingly govern how certain types of information are stored, transmitted, and secured. To avoid violating applicable regulations, organizations must protect themselves against intentional, inadvertent, or accidental information leakage.

The following are some consequences resulting from information leakage:

• Financial damages   Depending on the size, industry, and local regulations, information leakage may also result in financial impact due to loss of business or fines and punitive damages imposed by courts or regulatory authorities. Public companies may also risk losing market capitalization due to adverse media coverage.
• Damage to image and credibility   Information leakage can damage an organization's image and credibility with customers. Moreover, depending on the nature of communication, leaked e-mail messages can potentially be a source of embarrassment for the sender and the organization.
• Loss of competitive advantage   One of the biggest threats from information leakage is the loss of competitive advantage in business. Disclosure of strategic plans or mergers and acquisitions information can potentially lead to loss of revenue or market capitalization. Some of the other threats include loss of research, analytical data, and other intellectual property.

Traditional Solutions to Information Leakage

Although some traditional solutions to information leakage may protect the initial access to data, they often don't provide constant protection. For example, the following table lists some traditional solutions and their limitations

Solution	Description	Limitations
Transport Layer Security (TLS)	TLS is an Internet standard protocol used to secure communications over a network by means of encryption. In a messaging environment, TLS is used to secure server-server and/or client-server communications. By default, Exchange 2010 uses TLS for all internal message transfers. Opportunistic TLS is also enabled by default for sessions with external hosts, meaning Exchange first attempts to use TLS encryption for the session, but if a TLS connection can’t be established with the destination server, Exchange uses SMTP. You can also configure Domain Security to enforce mutual TLS with external organizations. For more information, see Understanding Domain Security.	TLS only protects the SMTP session between two SMTP hosts. In other words, it protects information in motion. It doesn't provide protection at the message-level or for information at rest. Unless the messages are encrypted by using another method, messages in the sender's and recipients' mailboxes remain unprotected. For e-mail sent outside the organization, you can require TLS only for the first hop. After a remote SMTP host outside your organization receives the message, it can relay it to another SMTP host over an unencrypted session. Because TLS is a transport layer technology, it can't provide control over what the recipient does with the message.
E-mail encryption	Users can use technologies such as S/MIME to encrypt messages.	Users decide whether a message gets encrypted. It also imposes additional costs of a public key infrastructure (PKI) deployment, with the accompanying overhead of certificate management for users and protection of private keys. Moreover, after a message is decrypted, there's no control over what the recipient can do with the information. Decrypted information can be copied, printed, or forwarded. By default, saved attachments aren't protected. Messages encrypted by using technologies such as S/MIME can't be accessed by your organization. The organization can't inspect message content, and therefore can't enforce messaging policies, scan messages for viruses or malicious content, or take any other action that requires accessing the content.

Finally, traditional solutions often lack of enforcement tools that apply uniform messaging policies to prevent information leakage. For example, a user sends a message containing sensitive information and marks it as company confidential and DO NOT FORWARD. However, after the message is delivered to the recipient, the sender or the organization no longer has control over the information. The recipient can willfully or inadvertently forward the message (by using features such as auto-forwarding rules) to external e-mail accounts, subjecting your organization to substantial information leakage risks.

Information Rights Management in Exchange 2010

In Exchange 2010, you can use Information Rights Management (IRM) features to apply persistent protection to messages and attachments. IRM uses Active Directory Rights Management Services (AD RMS), an information protection technology in Windows Server 2008. With the IRM features in Exchange 2010, your organization and your users can control the rights recipients have for e-mail message. IRM also helps allow or restrict recipient actions such as forwarding a message to other recipients, printing a message or attachment, or extracting message or attachment content by copying and pasting. IRM protection can be applied by users in Microsoft Outlook or Outlook Web App, or it can be based on your organization's messaging policies and applied by using transport protection rules or Outlook protection rules. Unlike other e-mail encryption solutions, IRM also allows your organization to decrypt protected content to enforce policy compliance.

AD RMS uses eXtensible Rights Markup Language (XrML)-based certificates and licenses to certify computers and users and to protect content. When content such as a document or a message is protected by using AD RMS, an XrML license containing the rights that authorized users have to the content is attached. To access IRM-protected content, AD RMS-enabled applications must procure a use license for the authorized user from the AD RMS cluster.

Note

In Exchange 2010, the Pre-licensing agent attaches a use license to messages protected using the AD RMS cluster in your organization. For more details, see Pre-licensing later in this topic.

Applications used to create content must be RMS-enabled to apply persistent protection to content using AD RMS. Microsoft Office applications, such as Microsoft Word, Microsoft Excel, and Microsoft PowerPoint are RMS-enabled and can be used to create protected content.

IRM helps you to do the following:

• Prevent an authorized recipient of IRM-protected content from forwarding, modifying, printing, faxing, saving, or cutting and pasting the content.
• Protect supported attachment file formats with the same level of protection as the message.
• Support expiration of IRM-protected messages and attachments so they can no longer be viewed after the specified period.
• Prevent IRM-protected content from being copied by using the Snipping Tool in Windows.

However, IRM can't prevent information being copied by using the following methods:

• Third-party screen capture programs
• Use of imaging devices such as cameras to photograph IRM-protected content displayed on the screen
• Users remembering or manually transcribing the information

To learn more about AD RMS, see Active Directory Rights Management Services.

AD RMS Rights Policy Templates

AD RMS uses XrML-based rights policy templates to allow compatible IRM-enabled applications to apply consistent protection policies. In Windows Server 2008, AD RMS server exposes a web service that can be used to enumerate and acquire templates. Exchange 2010 ships with the Do Not Forward template. When the Do Not Forward template is applied to a message, only the recipients addressed in the message can decrypt the message. The recipients can't forward the message to anyone else, copy content from the message, or print the message. You can create additional RMS templates on the AD RMS server in your organization to meet your IRM protection requirements.

IRM protection is applied by applying an AD RMS rights policy template. Using policy templates, you can control permissions that recipients have on a message. Actions such as replying, replying to all, forwarding, extracting information from a message or saving a message, printing a message, can be controlled by applying the appropriate rights policy template to the message.

For more information about rights policy templates, see AD RMS Rights Policy Template Considerations.

For more information about creating AD RMS rights policy templates, see AD RMS Rights Policy Templates Deployment Step-by-Step Guide.

Applying IRM Protection to Messages

In Exchange 2010, IRM protection can be applied to messages at the following stages:

1. Manually by Outlook users   Your Outlook users can IRM-protect messages with the AD RMS rights policy templates available to them. This process uses the IRM functionality in Outlook, not Exchange. However, your can use Exchange to access messages and you can take actions (such as applying transport rules) to enforce your organization's messaging policy. For more information about using IRM in Outlook, see Introduction to using IRM for e-mail messages.

2. Manually by Outlook Web App users   When you enable IRM in Outlook Web App, users can IRM-protect messages they send and view IRM-protected messages they receive. For more information about IRM in Outlook Web App, see Understanding Information Rights Management in Outlook Web App.

3. Automatically in Outlook 2010   You can create Outlook protection rules to automatically IRM-protect messages in Outlook 2010. Outlook protection rules are deployed automatically to Outlook 2010 clients, and IRM-protection is applied by Outlook 2010 when the user is composing a message. For more information about Outlook protection rules, see Understanding Outlook Protection Rules.

4. Automatically on Hub Transport servers   You can create Transport protection rules to automatically IRM-protect messages on Exchange 2010 Hub Transport servers. For more information about Transport protection rules, see Understanding Transport Protection Rules.

   Note

   IRM protection isn't applied again to messages that are already IRM-protected. For example, if a user IRM-protects a message in Outlook or Outlook Web App, IRM protection isn't applied to the message by using a Transport protection rule.

Supported Scenarios for IRM Protection

In Exchange 2010, IRM protection is supported in the following scenarios.

Scenario	IRM-protection supported?
Messages sent to mailbox users within your Exchange organization	Yes
Messages sent to distribution groups within your organization	Yes Note: If the distribution group includes recipients outside your Exchange organization, see "Messages sent to recipients outside your organization".
Messages sent to recipients outside your organization	No Note: Exchange 2010 doesn't include a solution for sending IRM-protected messages to external recipients. AD RMS offers solutions by using trust policies. You can configure a trust policy between your AD RMS cluster and Windows Live ID. For messages sent between two organizations, you can create a federated trust between the two Active Directory forests by using Active Directory Federation Services (AD FS). To learn more, see Understanding AD RMS Trust Policies.
Messages sent to distribution groups or distribution lists external to your Exchange organization	No Note: External distribution list or distribution group expansion doesn't occur within your Exchange organization. IRM-protected messages sent to external distribution groups contain a license for the group, but not for group members. Group members will be unable to access the message.

Decrypting IRM-Protected Messages to Enforce Messaging Policies

To enforce messaging policies and for regulatory compliance, you must be able to access encrypted message content. Furthermore, to meet e-discovery requirements due to litigation, regulatory audits, or internal investigations, you must also be able to search encrypted messages. To help with these tasks, Exchange 2010 includes the following IRM features:

1. Transport decryption   To apply messaging policies, transport agents such as the Transport Rules agent should have access to message content. Transport decryption allows transport agents installed on Exchange 2010 servers to access message content. For more information, see Understanding Transport Decryption.
2. Journal report decryption   To meet compliance or business requirements, organizations can use Journaling to preserve messaging content. The Journaling agent creates a journal report for messages subject to journaling and includes metadata about the message in the report. The original message is attached to the journal report. If the message in a journal report is IRM-protected, journal report decryption attaches a clear text copy of the message to the journal report. For more information, see Understanding Journal Report Decryption.
3. IRM decryption for Exchange Search   With IRM decryption for Exchange Search, Exchange Search can index content in IRM-protected messages. When a discovery manager users Multi-Mailbox Search to perform a discovery search, IRM-protected messages that have been indexed are returned in search results. For more information, see Understanding Exchange Search. For more information about Multi-Mailbox Search, see Understanding Multi-Mailbox Search.

To enable these decryption features, Exchange servers must have access to the message. This is accomplished by adding the Federated Delivery Mailbox, a system mailbox created by Exchange Setup, to the super users group on the AD RMS server. For details, see Add a Federated Delivery Mailbox to the AD RMS Super Users Group.

Pre-Licensing

To view IRM-protected messages and attachments, Exchange 2010 automatically attaches a pre-license to protected messages. This avoids the client having to make repeated trips to the AD RMS server to retrieve a use license, and also enables off-line viewing of IRM-protected messages and attachments. Pre-licensing also allows IRM-protected messages to be viewed in Outlook Web App. When you enable IRM features, pre-licensing is enabled by default.

IRM Agents

In Exchange 2010, IRM functionality is enabled on Hub Transport servers by using transport agents. IRM agents are installed by Exchange Setup on a Hub Transport server. You can't control IRM agents using the management tasks for transport agents.

Note

In Exchange 2010, IRM agents are built-in agents. Built-in agents aren't included in the list of agents returned by the Get-TransportAgent cmdlet. For more information, see Understanding Transport Agents.

The following table lists the IRM agents implemented on Hub Transport servers.

Agent	Event	Function
RMS Decryption agent	OnEndOfData (SMTP) & OnSubmittedMessage	Decrypts messages to allow access to transport agents.
Transport Rules agent	OnRoutedMessage	Flags messages that match rule conditions in a Transport protection rule to be IRM-protected by the RMS Encryption agent.
RMS Encryption agent	OnRoutedMessage	Applies IRM protection to messages flagged by the Transport Rules agent and re-encrypts transport decrypted messages.
Pre-Licensing agent	OnRoutedMessage	Attaches a pre-license to IRM-protected messages.
Journal Report Decryption agent	OnCategorizedMessage	Decrypts IRM-protected messages attached to journal reports, and embeds clear-text versions along with the original encrypted messages.

For more information about transport agents, see Understanding Transport Agents.

IRM Requirements

To implement IRM in your Exchange 2010 organization, your deployment must meet the following requirements:

Server	Requirement
AD RMS Cluster	Windows Server 2008 R2 Windows Server 2008 SP2 with the following hotfix. Service Connection Point (SCP)   Exchange 2010 and AD RMS-aware applications use the SCP registered in Active Directory to discover AD RMS cluster and URLs. AD RMS allows you to register the SCP from within AD RMS setup. If the account used to set up AD RMS isn't a member of the Enterprise Admins security group, SCP registration can be performed after setup. There is only one SCP for AD RMS in an Active Directory forest. Permissions   Exchange Servers group or individual Exchange servers must be assigned Read and Execute permissions to the AD RMS server certification pipeline (The default path is \inetpub\wwwroot\_wmcs\certification\ServerCertification.asmx on AD RMS servers). AD RMS SuperUsers   To enable transport decryption, journal report decryption, IRM in Outlook Web App, and IRM for Exchange Search, you must add the Federated Delivery Mailbox, a system mailbox created by Exchange 2010 Setup, to the super users group on the AD RMS cluster. For details, see Add a Federated Delivery Mailbox to the AD RMS Super Users Group.
Exchange Server	Exchange Server 2010 Recommended: This hotfix for .Net Framework 2.0 SP2
Outlook	Users can IRM-protect messages in Outlook. Outlook 2003 and later support AD RMS templates for IRM-protecting messages. Outlook protection rules are an Exchange 2010 and Outlook 2010 feature. Previous versions of Outlook don't support this feature.
Windows Mobile	Windows Mobile 6.0 or later. To enable IRM on a Windows Mobile device, the user must connect the device to computer running Windows 7, Windows Vista, or Windows XP, and then activate it using Windows Mobile Device Center or Exchange ActiveSync. To activate IRM, the computer to which the device is connected must have access to Active Directory domain controllers be able to locate the AD RMS cluster in your organization. For more information, see Overview of Information Rights Management. You must enable certification of mobile devices on the AD RMS cluster. For more information, see Enable Certification of Mobile Devices.

Note

AD RMScluster is the term used for an AD RMS deployment in an organization, including a single server deployment. AD RMS is a Web service. It doesn't require that you set up a Windows Server 2008 failover cluster. For high availability and load-balancing, you can deploy multiple AD RMS servers in the cluster and use Network Load Balancing.

Important

In a production environment, installing AD RMS and Exchange on the same server isn't supported.

Configuring and Testing IRM

You must use the Shell to configure IRM features in Exchange 2010. To configure individual IRM features, use the Set-IRMConfiguration cmdlet. You can enable or disable IRM for internal messages, enable or disable transport decryption, journal report decryption, IRM for Exchange Search, and IRM in Outlook Web App. For more information about configuring IRM features, see Managing Information Rights Management.

After you've set up an Exchange 2010 server, you can use the Test-IRMConfiguration cmdlet to perform end-to-end tests of your IRM deployment. These tests are useful to verify IRM functionality immediately after initial IRM configuration and on an ongoing basis. The cmdlet performs the following tests:

• Inspects IRM configuration for your Exchange 2010 organization
• Checks the AD RMS server for version and hotfix information
• Verifies whether an Exchange server can be activated for RMS by retrieving a Rights Account Certificate and Client Licensor Certificate (CLC)
• Acquires AD RMS rights policy templates from the AD RMS server
• Verifies that the specified sender can send IRM-protected messages
• Retrieves a super user use license for the specified recipient
• Acquires a pre-license for the specified recipient