Chapter 9: Compliance

The amount of information the world generates is constantly growing. Much of it ends up as email, with people regularly having mailboxes that are gigabytes in size. Of course, because of the history of Exchange storage, it is also the case that people have moved mail out of their mailbox and into PST files. When you couple this with ever-increasing regulation of business that affects the flow of information, you are faced with a significant challenge that needs to be addressed.

This chapter will take you through a discussion of compliance. We will introduce you to the regulations that businesses face, cover the conversations that you need to be having with your organization's legal department, discuss the policies that need to be set, and examine what Exchange functionality is available to implement those polices.

Overview of Messaging Compliance

Regulations

U.K. Data Protection Act The United Kingdom's Data Protection Act (DPA) specifies that “emails can be caught by the Act if they identify living individuals and are held, in automated form, in live, archive or back-up systems, or have been deleted from the live system but are still capable of recovery. They may also be caught if, despite having been deleted from the electronic system they are stored in paper form, in relevant filing systems.” (To be clear, “caught by the Act” indicates that the item falls under the jurisdiction of the DPA.)

For more information, see the following page:

http://www.dft.gov.uk/vca/data-protection-act-guidance-on-compliance.asp

Assuming that your email information comes under the Act, some of the important specifics are as follows:

Email is kept no longer than necessary.
Email is kept secure from unlawful or unauthorized processing or accidental loss or erasure.

This means considering the ability to remove data once it is no longer relevant and ensuring that the data is securely held. Also significantly, this means keeping that data safe and secure so that it is not leaked or transferred to others. Finally, you must also be able to provide data to the owner upon request.

U.S. Patriot Act This act gives the U.S. government various powers to safeguard national security. In particular, it allows the U.S. government to intercept all messages that are “relevant to an ongoing criminal investigation.” In essence, the Act provides the ability to require access to data via closed subpoena.

Like the DPA, this legislation is mostly concerned with the search and provision of data. However, it does have the interesting aspect of a potential clash between legislative bodies when concerning cloud-based systems run by U.S. firms.

For example, for the majority of the companies that we deal with regularly that fall within the jurisdiction of the European Union, any request under the U.S. Patriot Act needs to be viewed in the context of the EU Data Protection Directive, which is an example of a safe harbor law. This prohibits EU firms from transferring data overseas other than to countries that have signed up to meet the EU standards. The issue arises where certain national laws, like the U.S. Patriot Act, potentially overrule the agreement with the EU. This is of particular interest when considering a cloud-based service such as Office 365.

More and more often, we see an acceptance of the risk of the U.S. government requiring data, not least of which is because the United States has signed up for the EU safe harbor standards, and also because the benefits outweigh the risks. Finally, it is very often the case that were governments to require certain information, this could, in any case, be routed via the local security agencies that, particularly in the U.K., have good relations with comparable bodies in the U.S.

Freedom of Information Act Freedom of Information Act (FOIA) legislation is found in many countries including the U.S. and U.K. For example, the U.K. Freedom of Information Act 2000 provides access to data held by public bodies as follows: “Anyone can make a request for information, including members of the public, journalists, lawyers, businesses, charities and other organizations. An information request can also be made to any part of a public authority. You may have a designated information requests team to whom the public can make their requests. However, members of the public will often address their requests to staff they already have contact with, or who seem to know most about the subject of their request. When you receive a request you have a legal responsibility to identify that a request has been made and handle it accordingly. So staff who receive customer correspondence should be particularly alert to identifying potential requests. You normally have 20 working days to respond to a request.” The basic point here is that this is a regulation set up to allow the public as a whole (be it from journalists or directly) to gain access to data that will allow them to hold public organizations to account.

More information can be found on the following site:

http://www.ico.gov.uk/for_organisations/freedom_of_information/guide.aspx.

This regulation is all about being able to search for and provide information that is requested, within a prescribed time frame.

Health Insurance Portability and Accountability Act Health Insurance Portability and Accountability Act (HIPAA) is a U.S. law that applies to healthcare entities that governs the use, disclosure, and safeguarding of protected health information (PHI). This could be medical records or data relating to administrative or financial matters. It imposes requirements on covered entities to sign business associate agreements with their vendors that use and disclose PHI. In this case, the regulation is concerned with the protection and privacy of data, which in the case of email means ensuring suitable encryption of data both at rest and in transit. (Both of these topics are covered in Chapter 8, “Designing a Secure Exchange Solution.”) It also means preventing leakage of data, which is a topic we will cover shortly in this chapter.

For a great introduction to HIPAA and how it affects email, see the following site:

http://luxsci.com/blog/what-hipaa-says-about-email-security.html

Sarbanes-Oxley Act The Sarbanes-Oxley Act (SOX) is a U.S. law born out of the Enron scandal, and it is administered by the Securities and Exchange Commission (SEC). It has three guiding rules:

1. You must not destroy, falsify, or alter records.

2. An auditor must maintain all audit or review work papers for a period of five years from the end of the fiscal period in which the audit or review was concluded. (This has the potential to require both the auditor and, in practice, the auditee to maintain these records.)

3. The third rule defines the types of records that need to be stored, comprising all business records and communications, including electronic communications created, sent, or received in connection with an audit or review and which contain conclusions, opinions, analyses, or financial data relating to such an audit or review.

You can see how this regulation is concerned with data protection and immutability.

Payment Card Industry Data Security Standard The Payment Card Industry Data Security Standard (PCI-DSS) is a proprietary information security standard for those involved in handling cardholder information. The aim is to ensure that a minimum level of security is in place for those who store, process, and transmit cardholder data to prevent identity theft and card fraud. All transmissions must be audited, encrypted, and regularly tested. Often this involves using secured networks and isolating the data to certain systems.

In terms of email systems, PCI-DSS requires that this type of data either be encrypted or prevented from being sent over email in the first place. If this type of data is sent out over email, encryption is a must and so is careful protection with firewalls and malware safeguards to prevent infiltration that allows access to data.

Companies (Trading Disclosures) Regulations 2008 This U.K. regulation is derived from a European law on how businesses identify themselves. If your business is a private or public limited company or a Limited Liability Partnership, this regulation amends the Companies Act of 2006, and it requires all of your business emails (plus your letterhead and order forms) to include the following details in legible characters:

Your company's registered name (for example, XYZ Ltd.)
Your company registration number
Your place of registration (for example, Scotland, England, or Wales)
Your registered office address

Further information can be found in the PDF file found at the following address:

http://www.legislation.gov.uk/uksi/2008/495/pdfs/uksi_20080495_en.pdf

In Exchange terms, this means adding a footer or disclaimer to emails.

Having covered many of the major regulations that affect the flow of information, and having noted that the majority of them concern data privacy, retention, and provision, we shall now move on to look at how this affects the required policies.

Designing Your Policies

Regulations rarely spell out exactly what is required; that is, they are open to interpretation. This means that your organization needs to interpret the regulation appropriately and be able to show, in good faith, that it has made a reasonable effort to comply with the particular regulation. The fact that interpretation is involved opens up the potential for some rather extreme policies. It is at this point that an experienced consultant or architect needs to have the tough discussion that could very well save the organization money.

As an example, you may be able to bring up the fact that organization X in the same industry is doing things a little differently. It is very important that you challenge the status quo and present different possibilities. For example, keeping email forever, just because that is what has always been done, is going to cost your organization a significant amount of money. To this end, continue to push the legal team to make a decision. It is at this point where leveraging the senior sponsor of a project can make a difference. If you can convey accurately the complexity and cost implications of an open-ended, keep-everything-forever approach, you can often use the sponsor to guide the legal team into an appropriate response.

Typical Requirements

As you saw in the discussion of some of the most common regulations, they very often had the same effect on the operation of Exchange. These are not the only constraints on Exchange design, however. It is also necessary to manage the day-to-day operation of the platform. Therefore, you will likely have two major types of requirements in your compliance policy. The first set of requirements is driven by regulation and the second set is driven by day-to-day needs, such as the message size limit. It is important to understand that the legal team will drive one set of requirements and business sponsors will drive the other set of requirements.

What follows is an examination of the typical requirements you will need to consider when designing your compliance policy.

Retention of Data

You must weigh everything specified in the regulation and then consider your approach to whether it is better to retain data or not to retain data. Some organizations take the approach that all mail will be removed after one year no matter what. Other organizations delete all mail after thirty days unless it is specifically called out as a record and stored in a separate system. This is not an approach we would generally recommend, because it has a nasty habit of interfering with peoples' ability to do their jobs, becoming as irritating as the old need to manage mailboxes with small quotas. Other organizations must plan for very long data-retention cycles. Those building certain sensitive facilities with a long life may require access to those emails many decades into the future. In general, however, maintaining email for seven years for tax purposes is one of the more familiar requirements in the financial space.

Of course, you may require different retention periods for different types of users. For example, your standard policy might be to keep data for two years, but a specific regulated team might require a policy that provides for longer retention of data. You might also give users the ability to mark certain items specifically to allow them to be retained longer than the standard two years.

Once you have defined the retention periods and which groups are affected, you must be specific about the type of data required. Different archiving solutions can capture different levels of information. For example, are you required to capture all metadata related to messages, such as a point-in-time breakdown of members of distribution lists to whom the mail was sent? Or, is it a requirement to capture the BCC field of a mail? If so, then some form of envelope journaling is necessary. You may also be required to maintain visibility of Calendar and Notes entries in Exchange. Users have been known to attempt to get around ethical walls by leaving notes in shared calendars for the next shift to act upon.

Finally, you must define where data is to be held. For example, many organizations are desperately trying to reduce their reliance on PST files. You should consider making it part of your policy that all data should be held in Exchange because, for the lifetime of the product, there will always be a way to transfer data between versions. It also means that there are largely no blocking factors preventing upgrades that can occur when you have different third parties involved.

Ability to Retrieve Data

Having the data is one thing, but actually being able to get it back in a timely fashion is another. We've worked with customers who ended up with a mess when going back through ancient Exchange 5.5 database backup tapes to locate mail needed for a particular HR dispute. This underscores the importance of considering the length of time that you need to retain data. Once you have decided on a particular period, it makes a great deal of sense to maintain this data live and immutable if necessary. Given that Exchange can now make full use of up to 8 TB hard drives, keeping data live no longer means going back through ancient backup tapes, all stored in the wrong format.

Integrity/Immutability

Assuming that you can retrieve the data, you also often need to prove that it hasn't been tampered with. This is one area where companies often focus on a particular solution: write-once, read-many (WORM) media. In effect, regulations mostly state that it must be possible to prove the integrity of the data. Naturally, this can be done in several different ways through the use of both hardware and software. Exchange uses the software method by marking items as on hold. It then prevents updates to those items behind the scenes while letting users continue to work in the normal way. Any changes are captured, and a new version is created. Discovery teams then have full access to this history. Validation of data integrity can be provided through the provision of SHA-256 hashes for exported content, which can be checked using Electronic Discovery Reference Model (EDRM)-compatible software.

Security of Data

Of course, by retaining all of this data, you must take care to protect it. It is all too common to hear about data leakage, which can be extremely costly financially while damaging the reputation of an organization at the same time. Security is covered in depth in Chapter 8, where we discuss auditing and rights management. However, we will also touch on a few security-related elements in this chapter, particularly concerning data loss protection.

Identification of Your Organization

Another aspect of regulation covers the need to identify your organization. Thus, it is a common requirement that all business communications, including email, show your company information such as name, address, and registration details. This is usually covered as an email footer or disclaimer.

General Good Practice

As mentioned in the introduction to this section, policy requirements are not only driven by regulation. You must also cover some of the more mundane aspects of a mail system, such as whether or not personal email use is allowed and whether mail size limits exist. While these are not very exciting, they will form part of the consideration around your design.

Compliance Policy

Once you have decided on the elements that need to be contained within the compliance policy, you need to prepare the document that will then be communicated. In many situations, this document will need to be signed in some form by the staff. This may be a function of their terms of employment or as an additional procedure. The key point about this type of document is that it needs to be clear and concise so that users fully understand what they are signing.

Exec Summary

Give a quick introduction to the policy and what it covers, that is, email security and compliance. Cover the goals of the policy.

Roles and Responsibilities

Cover which groups are responsible for the policy and what they need to do to implement it.

Coverage

State to whom the policy applies. Be specific about different organizational units, systems, and employees. Explicitly call out any exceptions to the policy in this section.

Actual Policies

This part of the document is where you must define the policies. This will be the largest section, and it will form the guidance for your design. Make sure to cover all aspects of email compliance, including not only the regulatory issues and your responses to them that you may face (encryption, data retention/deletion, and so on) but also more mundane matters, such as personal use of email and mail size limits.

Processes

Cover the actual steps to be taken to put the policy into action in this section—how it will be enforced and how it will measure compliance. You may consider making this section an appendix in order to keep the user-readable material concise.

Consequences for Violation

As with any policy, you need to define a clear set of responses should it be violated. Here you should cover the consequences of the first, second, and third violations.

Revision Date

Define when the policy will be reevaluated and checked in order to determine if it is still meeting the relevant regulations.

Appendices

Compliance Solutions

Company A

Company A is a small business in an unregulated industry with 250 employees that needs to protect itself from occasional HR issues. The company has had HR disputes in the past and, when moving to Exchange Server 2013, it wants to take the appropriate steps to avoid such troubles going forward.

The thought process for such a company could go in several different directions. First, it could move its current mail system to the cloud with Office 365. This, of course, would be the subject of all the usual cloud decision framework elements, covered in the Microsoft Technical Fit Assessment, available at the following location:

http://www.microsoft.com/en-us/download/details.aspx?id=21538

Because it does not operate in a regulated industry, the major challenge for a small organization like Company A is bandwidth availability. Assuming that the cloud is a suitable solution, then Company A would migrate its messaging system to Office 365. From a compliance perspective, this makes matters very simple. As a starting point, it now has a much larger mailbox, which means that use of PST files can be prevented and that all data can be brought into Exchange Online.

For more information on planning for Office 2013 GPOs, see the following article:

http://technet.microsoft.com/en-us/library/cc179077.aspx

Given the size of the company, it is likely that the Microsoft Exchange PST Capture tool can be utilized to move the data. For more information about the details of the PST Capture tool, see the following article:

http://technet.microsoft.com/en-us/library/hh781036(v=exchg.141).aspx

Once the data is moved, Company A needs to consider data retention. Users tend to keep everything, so it makes sense to implement some basic retention policies. By default, Office 365 has a selection of policies in place, as can be seen in the following article:

http://technet.microsoft.com/en-US/library/dd297955(v=exchg.150).aspx

This article provides a very useful rundown of the technology behind retention policies and how to implement them. What is important is that the majority of tags are of the personal type. There are two retention policy tags and one default policy tag. Only the two retention policy tags are set to delete data automatically. These remove objects from the deleted items and junk mail folders after 30 days. Nonetheless, they do allow those objects to be recovered through the deleted items recovery area. Therefore, if you wanted to implement a default two-year retention policy that will delete all mail over two years in age, you would need to create a new retention tag, as shown in the following graphic, and then assign it to the policy. The following page lists procedures for setup and management of tags and policies:

http://technet.microsoft.com/en-US/library/jj150558(v=exchg.150).aspx

Having set up the system to allow mail to be retained, it is important to know how this mail can be located when the need arises. There are three possibilities for searching Exchange data. First, you can search via the SharePoint eDiscovery portal. This is not available, however, if you have not either installed SharePoint or you do not have a SharePoint subscription if using Office 365. The second option is through the use of PowerShell. While PowerShell is extremely flexible, it is also rather complex. This leaves the third and standard option of searching through the Exchange Admin Center. To allow a discovery officer to search Exchange data, you must make sure that they have the relevant RBAC role. In this case, membership in the Discovery Management role group is required. For a full breakdown of the discovery search capabilities of Exchange, see the article found at the following URL:

http://technet.microsoft.com/en-us/library/dd298021(v=exchg.150).aspx

For procedures regarding the management of eDiscovery capabilities, the following page is useful:

http://technet.microsoft.com/en-us/library/dd298014(v=exchg.150).aspx

Finally, as all companies must, you will have to identify yourself in email. To do so, you can use a simple transport rule. Exchange 2013 has a new interface for configuring transport rules, and it has an out-of-the-box option for adding a disclaimer. Open EAC and navigate to the Mail Flow/Rules sections. Select the plus icon and, on the drop-down menu shown in the following graphic, select Apply Disclaimers.

You are next presented with a group of options. First, give the disclaimer a name. You may create several names for different parts of the organization if you wish. You must be specific about when you want the disclaimer to apply, which in this case is when the mail is sent to a recipient outside the organization. Finally, specify the disclaimer text and a fallback option if, for some reason, the disclaimer can't be applied. As you can see in the following graphic, there are many other possibilities. These are covered in depth in the articles associated with these sites:

http://technet.microsoft.com/en-us/library/dd351127.aspx

http://technet.microsoft.com/en-us/library/aa998315.aspx

http://technet.microsoft.com/en-us/library/bb124352(v=exchg.141).aspx

Should Company A decide to stay with an on-premises solution, then deployment of Exchange 2013 would allow it to use large, cost-effective hard drives deployed directly in the servers. It could provide high availability by replicating the data and then implementing the same type of policies, as it would have for Office 365. Of course, the company would have to consider backups, but for a small number of users—even if these users have 25+ GB mailboxes—this should not be a major issue for a basic backup-to-disk system.

Organization B

Organization B is a governmental body that is required to provide data to the public via the Freedom of Information Act. Public-sector organizations generally work with sensitive data, which is classified at certain levels. More information about these levels in the U.K. can be found at the following URL which requires downloading. Similar examples exist for all major jurisdictions:

http://www.cesg.gov.uk/publications/Documents/business_impact_tables.pdf

Organization B is particularly determined to ensure that data is not leaked from the organization. Over the years, a large collection of PSTs has grown, because PSTs provided the only way possible to keep mailboxes small.

As with Company A, when considering the design of an Exchange compliance policy for Organization B, you have options regarding on-premises and cloud-based deployments.

With the recent announcement that Office 365 has received IL2 accreditation in the U.K., it is now open for use in many public-sector and government organizations, as discussed in the following article:

http://blogs.msdn.com/b/msbluelight/archive/2013/02/06/microsoft-office-365-receives-g-cloud-il2-accreditation-from-cabinet-office-for-use-across-the-uk-public-sector.aspx

Given that Organization B works with data that requires higher levels of security, it has decided to stay with an on-premises deployment of Exchange 2013. Also, for a different reason—that is, HR disputes versus Freedom of Information Act requests—the key requirement of being able to search and provide data to relevant parties is the same as for Company A. Thus, it is worth noting here that you should give thought to the interface chosen to perform searches.

As mentioned previously, the two GUI-based tools for searching are the EAC and the eDiscovery portal in SharePoint. While the EAC tool provides access to search, previews results, and then exports them to a discovery mailbox, the SharePoint portal is far more advanced. It provides a full case-management system, allowing different cases to be separated and permissions to be applied as needed to different discovery officers. It also provides real-time updates in search statistics and an improved export mechanism. Therefore, Organization B should weigh the frequency and complexity of it search requirements in order to choose the correct search mechanism.

Organization B also faces another very common issue: dealing with the accumulation of PST files. Many government organizations have outsourced mail platform delivery. To this end, they are often stuck behind the times in terms of design and delivery of messaging best practices, simply because of the sheer increase in contractual charges. This means that, up to this point, Organization B has had small mailbox quotas of 100 MB for a standard user and up to 750 MB for senior leadership. These size limits caused the growth of PSTs as users fought to remain within quota while retaining the data needed to do their jobs.

At this stage, Organization B is renegotiating its outsourcing agreements, which puts it in a position to dictate new terms. It has opted for a new storage platform, which is scaled to provide large 10 GB mailboxes for all users. This will enable Organization B to bring all of the data from the PST files back into Exchange. The major benefits of this approach are that users will no longer have to manage their quota constantly, data will not be exported out of Exchange, and backup challenges will be removed. Of course, it also means that all of the old data is now searchable and manageable through the use of Message Records Management policies.

Before beginning the process of importing all of the old data, Organization B will need to consider the age of the data and its importance to the organization. It may well be that some people have very old data. It is often the case that an organization will decide to put a reasonable limit on the data imported—five years, for example. This is what Organization B has decided. As discussed further at the end of this scenario, communication is key when making this change to avoid a user backlash. Decisions surrounding the amount of old mail to be imported will also need to be tied into the sizing discussion for the platform as a whole.

Once you have determined which PST data will be brought into the Exchange mailboxes, you have to decide how to get the data migrated. This can be harder than it sounds. You may be dealing with a huge amount of email that has the potential to overload both the network and Exchange if handled incorrectly. Generally, the first step is to migrate the user to their new mailbox. This makes a large mailbox available to them. Then it makes sense to turn off the ability to write new data to existing PST files and to prevent the creation of new ones. This turns the existing PSTs into an archive of old data with no possibility for modification by the user. This change is made using Group Policy in Active Directory. As a starting point, review the following article to understand Office 2013 Group Policies:

Group Policies are widely used in almost all organizations, so make sure that you discuss this with your Active Directory specialists. When you've decided on the best approach for application, download the Group Policy Administrative Template files from the following website:

http://technet.microsoft.com/en-us/library/cc179176.aspx

Once you download and install the template files, you will find a spreadsheet called office2013grouppolicyandoctsettings.xlsx. In this spreadsheet, you will see details of all of the policies that can be applied. The particular policies in which you are interested are found in the outlk15.admx template. These policies are described here:

Prevent users from adding PSTs to Outlook profiles and/or prevent using Sharing-Exclusive PSTs.

By default, users can add PSTs to their Outlook profiles and can use Sharing-Exclusive PSTs for storing SharePoint lists and Internet calendars. You can use this setting to limit a user's ability to store mail in a decentralized fashion. You can also block the use of PSTs completely, but be aware that blocking all PST files disables Outlook features such as SharePoint lists and Internet calendars. If instead you allow only Sharing-Exclusive PSTs to be added to user profiles, PST use is still limited but the Outlook features that rely on special PSTs are not disabled. The setting that allows Sharing-Exclusive PSTs to be added blocks users from creating new folders in the Sharing-Exclusive PST, copying existing mail folders from their default store to the PST, and copying individual mail items to the root of the PST.

Prevent users from adding new content to existing PST files.

This setting prevents users from adding any new content to PST files linked to their profiles.

Having prevented the creation of new PSTs and the addition of data to old ones, you can now consider the migration of old data into the Exchange mailboxes. Following are several approaches for accomplishing this:

Ask the users to use Outlook to import PST data into their new mailbox. We have seen this work occasionally or perhaps as a supplemental method. However, it is mostly an option in smaller organizations where there are relatively savvy users and where those users have bought into the change. Challenges occur because this can tie up Outlook clients for lengthy periods of time and because, as an administrator, you have no control over the bandwidth used or the logs created on the Exchange server. There may be a massive spike of imports that could overload the system, so this needs to be managed carefully with a communication plan.

Ask users to disconnect PSTs from Outlook and copy them to a central location. Then use PowerShell to import. The first issue here is again trusting end users to do as they are requested. Next, it is important to implement a suitable naming convention. Otherwise, identification and automation of the process of getting the PSTs imported will be a challenge. This method does give you more control over the import process, which means proper scheduling can be applied to prevent overload of Exchange. PSTs are all copied over the network at a time selected by individual users. For more information about the process required, review the following article:

http://www.microsoft.com/en-us/download/details.aspx?id=35554

Use a specialist tool designed specifically to migrate PSTs into Exchange. As with many administrative tasks, various specialist tools can ease the migration process as compared to the use of built-in or PowerShell-based automation. The task of PST migration is no different. Microsoft provides the Microsoft Exchange PST Capture tool, which is designed to search out and copy PST data from across the network into Exchange on-premises or online. Additional information about this tool can be found in the following articles:

http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/microsoft-pst-capture-tool-part1.html

http://technet.microsoft.com/en-us/library/hh781036(v=exchg.141).aspx

The Microsoft Exchange PST Capture tool offers various features, including an agent that needs to be installed on client PCs to allow non-specifically defined PSTs to be located.

The agent will allow the local PC and any attached drives to be searched for PSTs. It will also allow PSTs to be imported directly to the primary mailbox or to an archive mailbox. Of course, there are some limitations with a free tool. The Microsoft Exchange PST Capture tool only looks at the file owner to determine the ownership of the PST. It doesn't open up the PST and discovery sender and recipient information to better analyze the true owner. Therefore, you would need to assign PSTs manually to their true owner if they are not detected correctly. Another issue is that it can't use the Volume Shadow Copy Service (VSS) to capture PSTs open in Outlook. Perhaps the most important issue here is that the PST Capture tool does not allow data meeting a certain date range to be imported. This highlights the attention to detail required when evaluating whether a tool meets your requirements. The PST Capture tool will import all data from the PSTs chosen for import. In our scenario, where you want to import only data that is less than five years old, this is a showstopper.

You must therefore look elsewhere for a specialist tool. In the past, we have used a couple of products from TransVault. This company specializes in data migrations from various archive storage systems. TransVault Insight provides an enterprise-ready PST capture-and-migration solution that can overcome the issues described for the free Microsoft tool.

In this instance, you would weigh the cost of the tools versus the need to meet the requirements. It may be possible to automate some date range options using PowerShell, so if that was the only issue causing the move to a third-party tool, you may decide to use the free Microsoft tool for the bulk of the newer PSTs and then use PowerShell to automate the migration of the older ones.

As with any migration of large quantities of data, always carry out suitable benchmarking to ensure that you understand both the demands on the system (network, storage, and performance) and also the likely time that the migration will take so that you can appropriately inform users when their data will be available.

The final major requirement in this scenario is the need to protect Organization B from potential data leakage. Exchange 2013 is the first version of Exchange to include a Data Loss Prevention (DLP) system in the box. For an overview of the system, read the following article:

http://technet.microsoft.com/en-us/library/jj150527%28v=exchg.150%29.aspx

There have been a variety of third-party tools designed to carry out this task. However, since this demand has previously only been met in Organization B using the limited capabilities of older Exchange versions, we will investigate the integrated solution so as to hold to the principle of simplicity of management, integration, and design. DLP is an Enterprise Client Access License feature of Exchange, so you'll need to consider the cost of the solution in your recommendation.

Obviously, the most important element of the DLP solution is to decide what constitutes information that you need to protect. Most public-sector organizations use some form of protective marking scheme, such as the one detailed here:

http://protectivemarking.co.uk/images/downloads/gpms.pdf

Thus, you have ready-made categories that users are familiar with to assign to documents and emails. When dealing with email, categorizations are used to represent the different levels of restriction. Outlook provides the ability to apply categories manually. However, if this process needs to be mandatory for each mail sent, as it is in many of the more security-conscious firms, then a third-party add-in, such as those provided by Boldon James, needs to be implemented. Categorizations have existed for quite some time, but some of the actions that can now be taken in Exchange when sensitive data is detected are vastly improved.

Some of the requirements in this area may be as follows:

Route a mail to a manager or compliance officer for validation/moderation.
Route mail of a specific classification that is destined for a specific location over a special connector, which will then apply Transport Layer Security.
Apply a special amendment to the header of the message that will then trigger a separate encryption system farther down the chain.
Block a mail from being sent externally.
Block a mail from being sent at all.

There may also be special situations where you want to ensure that users are not using the wrong categorization. In such cases, the major improvement in Exchange 2013 is that there are various built-in ways to detect sensitive data types. As mentioned in the “Exchange Functionality” section, there are 47 data classifications built into Exchange. You can use these classifications and extend them further to operate as a means of double-checking that suitable classifications have been applied to mail. They can also be used to capture any special cases, such as mail about a specific project. The following graphic shows the interface where you can configure rules based on sensitive data types. As you can see, it is just another transport rule.

Naturally, a big part of the DLP solution is what happens when an incident is detected. Exchange provides auditing capabilities that enable notification of both the end user and the compliance team. In Outlook 2013, Exchange can provide warnings called Policy Tips to users, as shown in the following graphic, where detection of credit card information has been made.

You can elect to have users manually click to override a Policy Tip, either with a single click or by forcing them to enter a business justification. All of these elements are captured, and they become part of the audit report that can be sent to a compliance team. A sample report is shown in the following graphic.

These audit mails are structured in a regular fashion, as shown in the following article:

http://technet.microsoft.com/en-us/library/jj150534(v=exchg.150).aspx

It is possible to extend the capability of the solution further than just sending a mail to a mailbox for manual processing. For example, based on the coverage of EWS in Chapter 11, “ Extending Exchange,” it is possible to set up a reporting app that takes further action on various audit logs.

The DLP system in Exchange 2013 is the initial version. As such, it has areas that can be improved. For example, it is not possible to tie into external databases, perhaps to validate certain IDs.

Equally, it is currently not possible to implement fingerprinting of documents, a process whereby a checksum is run on sensitive documents and then fed into the DLP system. Any document matching the checksum can then be matched as a sensitive data type. That being said, this solution will fit many scenarios, and it is a huge step forward from the basic capabilities Organization B had implemented in previous versions of Exchange, based on simple transport rules.

One final note is that DLP in Exchange is also extensible, so you can build additional templates and classifications to fit your needs better. More information on the required processes can be found in the following article:

http://technet.microsoft.com/en-us/library/jj674310(v=exchg.150).aspx

Company C

Company C is a global banking organization that has offices in Hong Kong, London, and New York as well as numerous retail branches worldwide. It has to address strict regulatory compliance issues, and it already has a third-party archiving system in place.

A major financial firm is likely to be using a broad range of systems, so let's assume that SharePoint and Lync are already deployed. We will also assume that there is a storage strategy in place, which predominantly makes use of managed SAN storage.

It is clear that many of the conversations already covered in the previous scenarios will also be applicable here. For example, the use of retention tags and policies to provide a mechanism for keeping data for a certain time period also applies to Company C. A DLP mechanism provided by a third party is also in place. In situations where a major component is already deployed, a review of the requirements, as described by the design document, is often a useful prompt to reevaluate whether new functionality in the Exchange platform will meet those requirements.

Obviously, change for the sake of change is not necessarily sensible, so you should undertake these reviews systematically and with an open mind. In Company C's case, it makes sense to stick with the existing solution, because it is deeply embedded in its processes and it offers certain niche functionality, particularly around built-in workflow as opposed to needing to develop this functionality anew for Exchange 2013. Finally, as with Company A, a suitable disclaimer will be added to mail using transport rules in each jurisdiction.

As with all of the other organizations, there is the discussion about whether or not to use cloud-based services. While financial organizations have been reluctant to place their data in a public cloud infrastructure, that mentality is evolving. For example, the Dutch financial services firm Robeco recently moved its infrastructure to Office 365 after an agreement with the Dutch National Bank on regulation, as detailed in the case study at the following URL:

http://www.microsoft.com/casestudies/Microsoft-Office-365/Robeco/Financial-services-provider-Robeco-leaps-from-the-stone-age-to-the-21st-century-with-cloud-solution/710000002301

In the case of Company C, it elected to deploy a hybrid cloud-based solution. For the first time, all branch users will be given email and portal access based on Office 365. Highly regulated traders will be retained on the on-premises servers for the time being.

The key requirements in this scenario include the following:

Consideration of the archiving system in light of the new functionality in Exchange, SharePoint, and Lync
Dealing with the storage of data for a subset of users in an immutable fashion as required by regulators
Searching for data and providing it to counsel on a large scale

We will start by considering the archiving situation, because it has a direct impact on the other requirements. The third-party archiving system that is in place currently would need to be upgraded to work with Exchange 2013. As covered in the introduction to this case study, this means that it is an ideal time to explore whether things could be simplified through the use of new native Exchange features. As in Exchange 2010, Exchange 2013 continues to provide an archive mailbox, which is a secondary mailbox for users. Data can be moved by policy or be moved manually to the archive, and it can be accessed only when the client is connected to the server; that is, when it is online.

The existing archiving platform has been used both as a platform for discovery of data in Exchange and SharePoint and as long-term immutable storage via integration with specialist WORM storage. It can also be used as a method for keeping the size of a mailbox relatively small, given the reliance on expensive SAN storage. Recalling the discussion in Chapter 5, “Designing a Successful Exchange Storage Solution,” the Exchange team won the argument about using the SAN storage and was granted an exception to use much cheaper direct attached storage. This has the added benefit of providing much more space for mailboxes. Thus, there is a reduction in the need to archive solely to keep mailboxes small. Exchange 2013 provides support for mailboxes of up to 100 GB in size, so even the heaviest email users are likely to be able to maintain data for seven years and not hit their quota. Also, given the improvements in keeping the data in Exchange, from Exchange 2007 to Exchange 2010 and Exchange 2013, it makes sense given that future versions are likely to improve this capability even further and hard disk drives will continue to grow in size while becoming less costly to purchase.

The company will also be moving to Outlook 2013, which means that it will have control over the amount of mail synchronized down to each client machine OST file, as shown in the following graphic.

http://technet.microsoft.com/en-us/library/ff637980(v=exchg.150).aspx#scenarios

From a client perspective, a benefit of moving to a single, large mailbox approach is that the ability to search for data from any client—mobile, desktop, or browser—is simplified to using native tools. This means that there is no longer a need to integrate with add-ons for OWA or Outlook.

The client archive is the simplest area to move into Exchange, because its primary goal was to keep the mailbox small, which is no longer an issue with Exchange 2013. The next major consideration is the journal. This is used to ensure that copies of all items that pass through transport are held in a secure, immutable location. Journal objects are placed in one or more mailboxes that are specially secured on separate servers because of the sensitive nature of the content and the workload that this approach generates. The third-party system monitors these mailboxes and regularly pulls data out into its own system. One of the challenges of this approach is that items that do not pass through transport, like Notes or Calendar entries, are not captured. This leaves a potential loophole to be exploited. Another challenge is the level of resources dedicated to special mailbox servers. While journaling still exists in Exchange 2013, there are other ways to maintain records for the long term without special servers and without removing data from Exchange.

The new method for retaining data immutably for various periods of time is called In-Place Hold. There are various options available, which allow significant flexibility:

Indefinite hold is similar to the Litigation hold feature you may be familiar with from Exchange 2010. This ensures that all items from mailboxes are held indefinitely.
Query-based hold again holds all items indefinitely. However, the items to be held are based on a query that you specify.
Finally Time-based hold is used to capture all of the data for a specific time. In a financial setting, we store data for all of our mailboxes for seven years.

For more information on In-Place Hold, including the method through which it achieves immutability, check out the following article:

http://technet.microsoft.com/en-us/library/ff637980(v=exchg.150).aspx#scenarios

It is likely that automation of Hold applications will be carried out through PowerShell as part of the mailbox provisioning process. For more information on configuration see the article at the following address. Pay particular attention to the ItemHoldPeriod parameter:

http://technet.microsoft.com/en-us/library/dd298064(v=exchg.150).aspx

There are a couple of downsides to not using journaling, because the In-Place Hold feature does not capture the Distribution List membership at the point of receipt as the journal would. It also doesn't capture the BCC field. However, inbound mail arrives in mailboxes and thus can be located. The use of the BCC field will show up in the Sent Items field of a mailbox. While not a perfect match for existing functionality, the move to this retention method means that the third-party archiving system can be retired, thus allowing significant savings. Another benefit, which helps tip the balance, is that with the 2013 releases of SharePoint, Lync, and Exchange, the process of data retention can be extended across the platform. SharePoint can integrate with Exchange to provide the search portal, which we will discuss shortly, and Lync can make use of the immutable storage area in the Exchange mailbox to store its own communication records, thus providing a unified approach. For more information about Lync archiving integration to Exchange, see the following blog post, or read Chapter 17 of Mastering Microsoft Lync Server 2013 (Wiley, 2013):

http://blogs.technet.com/b/nexthop/archive/2012/07/23/integrating-exchange-2013-preview-and-lync-server-2013-preview.aspx

As with any other business decision, there is a tradeoff between risk and reward. In this case, the proposed solution is deemed suitable.

Removing the third-party archive naturally leads to the discussion of getting data from A to B. There are currently no native Microsoft tools available to carry out this type of migration, other than resorting to PSTs. It may be possible for the archive solution to repopulate items into individual mailboxes. However, this usually causes a problem due to storage on the existing mail platform not being sized appropriately. Also, given that the archive system is the system of record, it is very important that a complete audit trail be maintained. To this end, we have observed several companies working with another of the TransVault products, TransVault Migrator, to get data into Exchange or Office 365 with a complete audit trail.

Before completing the discussion of data retention, we must cover the one outstanding major element that the third-party system was providing, that is, search. Given the complexity of searches carried out and the sheer number of difference cases, we will opt for the Case Management system provided by the SharePoint eDiscovery portal.

We covered the majority of steps required to get SharePoint and Exchange talking to each other in Chapter 10, “Collaborating with Exchange.” Following is a group of links that provide good information about the processes required for setup of discovery search. The first URL is to the SharePoint TechNet site, and it contains a listing of the relevant information in the correct order and links to all other relevant locations. The next URL provides a suitable overview of features that can be found in the SharePoint eDiscovery Center.

http://technet.microsoft.com/en-us/library/fp161514(office.15).aspx

http://technet.microsoft.com/en-us/library/fp161513(v=office.15).aspx

The eDiscovery Center in SharePoint shown in the graphic here allows members of the Discovery Management RBAC role to search for and retrieve data from Exchange, just as they would by using the EAC, as discussed with Company A. The added capabilities for returning data from SharePoint mean that this offers a one-stop shop for data discovery and retention, because queried data can also be put on hold. Interestingly, Time-based hold is not configurable from the SharePoint eDiscovery Center. This must be configured from PowerShell or through EAC.

When you enter the eDiscovery Center, as shown in the following graphic, you will likely create a new case. This essentially creates a new SharePoint site under the main eDiscovery Center.

Permissions can be applied and basic details about the case can be provided, as shown in the following graphic.

Once the case is created, you'll see the simple dashboard shown in the following graphic, which provides a quick and easy view of the sources (eDiscovery Sets) and the queries. You also get basic statistics on the case.

We begin by creating an eDiscovery Set, as shown in the following graphic. This combination of sources can be SharePoint sites or Exchange mailboxes and basic queries that will get us to a starting point of data to refine further.

Throughout this process, you are presented with statistics. It is easy to set up the basic filters around date, sender/author, and domain. At this point, you can also choose to put this data on hold. Finally, you can also preview the data in order to be sure that you are retrieving what is needed.

The key thing to remember throughout the discovery process is that you will likely start with a huge data set, but what you really need is the minimal amount of data relevant to the case in order to hand it over to counsel. It is not uncommon to have to search hundreds of mailboxes. This will return gigabytes of data, which if handed over to counsel would increase costs astronomically. Therefore, you go through a process of filtering the data using the new Keyword Query Language (KQL). For more information about KQL, see the following article:

http://msdn.microsoft.com/en-us/library/ee558911.aspx

Once you have the basic sources you need, you then go on to create complex and detailed search queries using KQL, starting from the case summary page shown in the following graphic. When creating the search query, you are constantly provided with statistics, real-time updates, and filters to further refine the data set, as shown in the graphic. You can see that there are tabs to show Exchange and SharePoint data in different views. In this case, you are looking at SharePoint data. Hovering over one of the items located at any time will give you a quick preview, and clicking the item opens it either in a browser (for a site or email) or in one of the Office Web Apps, if a document.

Once you have filtered the data down as much as required, you are ready to complete the process by exporting the data. An export is carried out based on a query set. When you go to create a new export, you will be prompted for a query to base it on. This will open the query, as shown in the graphic, and if you move to the bottom-right of the window, you will find the Export button. Once you click this button, you will be able to configure the export including naming it, selecting options for de-duplication of data, and including object versions and objects that are not searchable, such as those protected with S/MIME encryption, as shown in the following graphic.

Finally, after clicking OK, you see a screen that allows you to either start the export of all of the results or simply generate a report of the results, as shown in the following graphic. Either choice launches the browser app shown in the next graphic, which prompts you for a location to save the results and then completes the export.

The top half of next graphic shows the results, which include the reports. If only the reports are downloaded, then you'll see the files in the bottom half of the graphic.

Upon drilling into the results, you can see that they are provided with a manifest file that conforms to EDRM standards. This manifest file, as shown in the following graphic, contains detailed information about all of the actions taken to accomplish the search. Significantly, it is provided in a standard format so that it can be imported into existing toolsets used by legal teams. Equally important is the fact that it contains an SHA-256 hash of each document, which suitable software (that many legal teams already use) can read and use to prove that the document has remained unchanged during the export process.

For more information about the EDRM standards, browse to the following address:

http://www.edrm.net/

The topic of oversight has not been covered in any of these case studies, because we already covered several aspects of Exchange that also contribute to maintaining compliance in Chapter 8, “Designing a Secure Exchange Solution.” In particular, the ability to audit not only mailbox access but also administrative actions means that you constantly have a log of all that goes on within the system. Ensuring that you are making regular audits and checking programmatically that those people who should have access actually do have it to the broader roles, such as Discovery, is critical to avoiding accidental or deliberate compliance breaches.

Overall, the move to large, cheap storage and away from the third-party archive systems translates to a simpler experience for users and administrators and a general reduction in operating costs. It does require migration of data from the old archive system, which nevertheless has a cost attached to it. However, in the long term, it sets up an easy migration to future versions of Exchange or to Office 365 because the data is now in a standard format.

Overview of Messaging Compliance

Regulations

Designing Your Policies

Discussions with the Legal Department

Typical Requirements

Retention of Data

Ability to Retrieve Data

Integrity/Immutability

Security of Data

Identification of Your Organization

General Good Practice

Compliance Policy

Exec Summary

Roles and Responsibilities

Coverage

Actual Policies

Processes

Consequences for Violation

Revision Date

Appendices

Compliance Solutions

Exchange Functionality

Journaling

Transport Rules

Data Loss Prevention

Information Rights Management

Message Records Management

In-Place Archiving

In-Place Hold

eDiscovery

Administrator Audit Logging

Mailbox Audit Logging

Exchange 2013 Compliance Scenarios

Communication

Summary