Companies have been trying to protect their electronic intellectual property for as long as the first email and word processing systems appeared. It’s easier than ever before for people to share information with (literally) the world, a thought that makes CIOs wince when they consider how documents and messages leaving their organization might contain secrets of all shapes and sizes.
Office 365 comes with a number of features to help tenants control the inadvertent dissemination of information. Data Loss Prevention policies can be deployed to help remind users of the right way to deal with sensitive information. Office 365 Message Encryption (OME) can be used to secure email traffic to external domains, and Azure Rights Management (RMS) templates can be created and applied to messages and documents to secure their content. It’s relatively easy for the IT department to make the necessary changes to Office 365 to put policies, rules, and templates in place. The question is whether anyone will use the technology. Often users are blissfully unaware of the need to protect information and even when they are informed, they might forget or ignore what’s expected of them.
Microsoft thinks they have a way to make the process of protecting information easier for all concerned. Azure Information Protection, now in public preview and slated to be part of the new Enterprise Mobility and Security (EMS) plans, allows existing RMS templates to be applied to protect content generated by Word, Excel, PowerPoint, and Outlook (2010 to 2016) automatically based on a simple classification scheme defined in an Azure protection policy.
Table 1 describes the features of the two plans (P1 and P2) that will be available for Azure Information Protection. Both plans allow tenants to define classification labels together with associated actions as described later. The big difference in the P2 plan is the addition of automatic classification of files based on their content. We’ll explore that aspect too, but I won’t go into the last element, which is the support for hybrid RMS templates where some are managed by Microsoft in the service and others remain on-premises or under the control of the tenant using the Bring-Your-Own-Key (BYOK) capability. Hybrid support is not yet available.
P1 (EMS E3 plan)
Insert visual indications into files (headers, footers, watermark)
Application of RMS templates
P2 (EMS E5 plan)
Automatic classification of documents based on content
Table 1: Features of the Azure Information Protection plans
The big idea
The idea behind information protection is simple. Users are asked to classify information when they create or modify content by selecting the most appropriate label for the file. Behind the scenes, applications check the policy defined for the tenant and, if necessary, actions dictated by the policy for a specific classification are taken. Classification occurs through an explicit user choice or (with the P2 plan) if specific content exists in a file. Actions include applying visual indications to documents or applying an RMS template to protect the content. The classification information travels with the document, including if it is sent outside the tenant, and if an RMS template is applied, the restrictions defined in that template dictate what recipients can do with the information. If necessary, access to protected documents can be revoked through the Azure Rights Management portal, all of which is designed to deliver what Microsoft refers to as “safe sharing”.
Of course, you can achieve the same protection by creating a set of RMS templates in your Office 365 tenant and publishing them. Users can then apply the templates using the features built into applications like OWA or the Rights Management sharing application for Windows, which enables a “Share Protected” option in the Office desktop applications and a “Protect with RMS” option in File Explorer. The current Rights Management sharing app will be replaced by the Azure Information Protection app when the product is released.
However, the downside of simply making RMS apps and templates available is that this approach requires users to make a conscious decision about when they should apply protection to files and messages on an ongoing basis. Azure Information Protection aims to make the protection easier and more automatic by incorporating it into the normal creation or modification process for documents and messages.
Creating a protection policy
Two fundamental steps are necessary to use Azure Information Protection. (A quick start tutorial is available online.) First, you have to download and install the client on workstations for use with the desktop Office applications (Azure Information Protection doesn’t work with the browser versions of the Office apps or OWA). I used a Windows 10 workstation configured with the click-to-run version of Office 2016. Second, you have to define a protection policy through the Azure management portal. You’ll need to configure RMS for your Office 365 tenant if you want to apply RMS templates through the protection policy. Azure Information Protection provides a default policy to start you off with a set of classification labels (Personal, Public, Internal, Confidential, and Secret) that will allow you to test a number of simple scenarios. The labels are ordered according to their sensitivity. Naturally, you can amend the policy to meet your needs.
As I had already configured my tenant for RMS, I reviewed the default protection policy through the management portal (Figure 1) before making some changes. Initially, just to see how things worked, I added a new label called “Office 365 Book Source” to apply to source documents for the “Office 365 for IT Pros” eBook, which are very confidential material in my eyes.
Figure 1: Azure Information Protection management portal
I associated one of the RMS templates available in the tenant with the new classification label and updated one of the default labels (Secret) with another template. I then choose that all documents and messages should have a classification label and selected the “Personal” label as the default. Finally, I changed the tooltip text to make it more appropriate to my tenant. After saving the policy, I published it to make the new policy available to clients. The preview version only supports labels in a single language (English in my case). Multilingual support will come in the final version.
Interestingly, the “Secret” label provided in the default information policy has two sub-classifications (“All Company” and “My Group”). The intention here is to show how a single label might have different templates and rules defined for it depending on the target audience. In this instance, a file classified as Secret but intended for the entire company might have a template that allows people to read but not print the information while one marked for sharing with a specific team might have a more liberal template assigned.
To test the effectiveness of the policy, I started Word and opened an existing document. After the Azure Information Protection client is loaded on a PC, every time an Office application starts, it checks to see if an updated policy is available. If one is, it is downloaded and applied. Offline access works because the policy file is downloaded to %localappdata%\microsoft\msip\Policy.msip. As with all offline checks, a potential danger might exist that the policy is outdated when applied. However, given that a protection policy is unlikely to change all that often, this should not be a major concern.
When Word opened the document, the influence of the protection policy was immediately obvious as a new information protection bar was in place with the default label (Personal) selected and the Sensitivity tooltip visible. Clicking the pencil icon revealed the full set of labels that could be applied to the document (Figure 2). The labels defined in the policy are shown in the order of increasing sensitivity from left to right in the information protection bar.
Figure 2: The protection policy shows up in Word 2016
Making policies easy for users
Making security complex is a quick way to turn users off. With this in mind, it’s best to limit the number of classification labels used in an information protection policy. If you define more than four or five, you might run into display difficulties on small screens. And anyway, if you offer too many choices to users, the chances are that they will make a mistake and misclassify something important. For this reason, it’s best to settle on a small number of easily understood classifications that meet the vast majority of labelling requirements for the business. And if you need to differentiate to meet the needs of a specific department, you can always deploy sub-classifications for labels.
The user can opt to remove an existing classification or replace it with one of the available set. However, if the protection policy requires that all documents are classified, the user will be prompted to select a label before they can exit and save the file (Figure 3). This might seem a tad irritating, but it’s something that you become accustomed to very quickly. As you can see, substantial screen width is required to display six classification labels, which proves the worth of simplifying the set. In this case, I might ask myself whether I really need the new label I created and if I could not just use the Secret classification instead. In passing, the downward arrow shown in the Secret label indicates that multiple options exist for this classification.
Figure 3: Prompting the user to apply a label to comply with policy
If the policy requires users to provide justification when they lower the classification of a file (for example, from Confidential to Personal), the prompt shown in Figure 4 is displayed to gather information about why they took this action. Downgrades are currently recorded as Windows events in the Application log (look for event ID 1000 with source Microsoft Azure Protection). It’s not really satisfactory to record any event relating to the protection of confidential information in a repository belonging to an individual PC. Fortunately, the Azure Information Protection team agrees and soon these events will be logged in the service, where they can be reviewed and reported upon by administrators.
Figure 4: Prompt when a classification is lowered
Extending the protection policy
Moving on, I decided to expand the protection policy to apply further actions for some of the labels used to protect more confidential information. Figure 5 shows some of the actions that are possible to define:
- Text for a tooltip to explain the type of information that should be classified with the label.
- The color shown for the label.
- The RMS template that will be applied to the file when it is saved.
- Whether a header should be added to files classified with the label and if so, the text, font size, color, and alignment of the header.
- Whether a footer should be added.
- (not shown on screen) Whether a watermark should be added and if so, the watermark text, its size, color, and alignment (horizontal or vertical).
A section to enter notes for administrator use is also available to allow information such as who last updated the policy, when they updated the policy, and for what reason the change was made.
Figure 5: Defining actions for a classification label
The effects of the visual indications defined for a classification label are what you’d expect with Word, Excel, and PowerPoint all displaying headers, footers, and watermarks. Messages sent with Outlook (Figure 6) show the effect of the classification after the message is sent. In this case, the watermark doesn’t appear but the defined header and footer are in place and the right RMS template has been assigned.
As you’d expect, if you remove a label that requires specific actions or replace it with a different label, the header, footer, watermark, and RMS template defined by the previous classification are removed and replaced by whatever is defined for the new label.
Figure 6: An email sent after classification was applied
Through its work on Data Loss Prevention, Microsoft has a lot of experience defining and detecting sensitive data types in Office documents and messages. Some of that knowledge is used in the automatic classification feature of Azure Information Protection, where rules can be defined to scan for different kinds of sensitive data that might appear in files. In the preview, the built-in sensitive data types are SWIFT (banking) codes, credit card numbers, ABA routing numbers (for U.S. banks), U.S. social security numbers, and international bank account numbers (IBAN). DLP for Exchange and SharePoint supports many other sensitive data types, so this is an area that you can expect to expand in the future. The reuse of common definitions for sensitive data types across multiple applications is a good thing.
If sensitive data is found in the content, the user can be prompted to apply an appropriate label to classify the content or a system-determined classification can be applied without user intervention.
Automatic classification can also be performed based on a text phrase to allow for situations where you might want to protect all documents related to a specific topic. For example, if you have a team working on the secret merger project called “Project X”, you could create a rule to look for “Project X” in the text and apply a classification based on that.
To add an automatic classification rule, select the label that you want to use and go to the “Configure conditions for automatically applying this label” section and click “Add a new condition”. You can then select from one of the built-in sensitive data types or you can add your own custom condition. Figure 6 shows how a custom condition is defined. As you can see, I also added a check for credit card numbers. When you are finished adding conditions, save the label and publish the policy.
Figure 7: Automatic classification rule
To test, open a new Word document and type in words matching the custom condition or the selected sensitive data type. Nothing happens until you save the file, but when you do, Azure Information Protection will apply the selected classification (Figure 8). This mechanism works well for Word, Excel, and PowerPoint but it doesn’t work with Outlook, possibly because of the acknowledged lack of integration with Exchange Online at this point.
Figure 8: A Word document is automatically classified as Confidential
There’s enough in the Azure Information Protection preview to make it of interest to anyone concerned with the question of how best to protect and preserve a company’s intellectual property, especially when the Office application suite is used to generate files. The answer isn’t quite so good for non-Office files such as PDFs.
Before they ship the final release, no doubt Microsoft will address gaps like multilingual support, the lack of a mobile client, no integration with Exchange Online and SharePoint Online (and applications like Office 365 Groups), lack of hybrid support, no SDK, no support for Office for Mac, and clarity about auditing of user actions. Many of these features are already being worked on. It just remains to be seen when they will be delivered.
Follow Tony on Twitter @12Knocksinna.
Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.