The Microsoft Information Protection brings the classification, labeling, and protection capabilities of Azure Information Protection and Office 365 Security and Compliance Center in to a simple, lightweight, cross-platform software development kit that enables any application to read and apply MIP labels and protection.
In this release, we’re providing our first look at the components of the SDK and how your organization will be able to use each of them to make your own applications Microsoft Information Protection enabled and fully aware.
What is Microsoft Information Protection?
Back in February, over on the Enterprise Mobility + Security blog, we revealed details on the Microsoft Information Protection story and the work we’re doing to bring together Azure Information Protection and Office 365 labeling via Security and Compliance Center.
Microsoft Information Protection is the combination of AIP and the O365 labeling in Security and Compliance center, and the future integration around the labeling experience that will come as part of O365 and EMS. The videos below cover some of the changes we’re making as we work toward this goal.
Azure Information Protection: Unified labeling, on-prem scanning and protection across platforms
Preparing for GDPR: Compliance management and information protection capabilities in Microsoft 365
As the classification, labeling, and protection experience becomes native across the Office 365 experience, your organization and users will begin to demand that the ease-of-use they experience in their Office applications and services carry over to 3rd party and line-of-business applications. As our customers and partners, you’ll be able to use the MIP SDK to make classification, labeling, and protection in these applications easier than ever.
File, Policy, and Protection APIs
The MIP SDK is made up of three separate APIs: File API, Policy API, and Protection API.
Policy API
The Policy API exists to allow developers to perform label-driven actions in their applications. The typical consumer of this API will be an application owner. This API doesn’t apply a label to a document or take any action at all. Rather, it informs the application of the available labels for the current user and what actions should be taken when that label is applied. It’s up to the software engineer to code the appropriate behavior in the application and to write those changes to the output file.
For example, if I’m a software developer at a company writing a CAD/CAM application, I would leverage the Policy API to:
Display the labels available to the authenticated user.
Calculate the actions to take when a label is selected, either by a user or programmatically.
Calculate the actions to take when a label is
Protection API
The Protection API enables developers to read and write Azure Information Protection rights-managed streams. The API can be used to read encrypted input and decrypt to reason over the contents in plaintext, or to take plaintext output from a system and encrypt it in an AIP rights-managed format.
We believe that organizations using RMS SDK 2.1 or 4.2 will be able to fully replace that functionality with the Protection API capabilities from the MIP SDK.
File API
Last, but certainly not least, is the File API. The file API provides an easy-to-use method of performing several file related tasks for well-known file formats. By simply passing in a label ID, the API can apply a label, content marking, and protection to a list of supported formats. Additionally, labels can be fetched from the service, read from a file, deleted or changed, and justification provided when downgrading the label.
The File API isn’t truly independent. Rather, it provides an abstraction of the previous APIs so that developers don’t need to worry about handling policy actions or protection actions; the File API, based on the labels that are present, knows exactly what to apply and how to apply it to the supported file types.
Use Cases
Before embarking on any journey with a new SDK, we understand that it’s important to have solid use cases and business justification. We’ve been mulling over the various use cases for the SDK for quite a long time. You’ll be able to use some of our ideas below to kickstart discussions in your own business.
From the standpoint or Microsoft and the MIP SDK team, our #1 goal with the SDK is this:
Mcafee Microsoft Information Protection will enable our third-party ISV ecosystem to build native support for MIP classification, labeling, and protection in to their applications.
One of the most common questions we hear on the Information Protection teams is:
“When will Microsoft support application or service X with MIP?”
It’s extraordinarily difficult to build a solution that works across many applications, in a scalable, fast, user friendly, and most important, transparent manner. We believe that the best MIP CLP experience is a native application experience. We’ll be announcing several partnerships with security ISVs this week at RSA Conference and as we approach GA. These partners are already committed to building support for MIP in to their applications and services.
File API Use Cases
We believe that, for most tasks, organizations will build functionality that leverages the File API. Because the API can be used to read, apply, or remove labels and protection, without having to worry about modifying the file contents in your own code, it’ll be the simplest, most common approach to using the SDK. Here are some examples of File API use cases:
You’re a software engineer at a financial services institution. You want to be sure that data from your LOB applications, typically exported in Excel format, are labeled on export based on the contents. File API can be used to list available labels then to apply the appropriate label to a supported file format.
Your company develops a cloud access security broker (CASB). Your customers ask for the ability to apply MIP labels to Microsoft Office and PDF documents. The File API would enable you to display a list of configured labels, then allow your customers to build rules which would apply the desired label. File API, taking in the label ID, would handle the rest for files meeting the customer’s criteria.
Your company provides a service-based data loss prevention solution and/or a CASB that monitors SaaS applications for file activity. To reduce the risk of data loss or exposure where data is protected with MIP, your service must be able to scan the contents of protected files. Using File API for the supported formats, when the service is a privileged user, you can remove protection, scan the contents for restricted or sensitive content, discard the plaintext result, and apply a service rule to report on or remediate the risk if found.
