A world-class enterprise mobility solution is a critical part of any organization’s IT strategy – period, end of sentence. When you look at what the enterprise mobility management solutions are built to do, they are built to protect the apps and data on those devices. The industry talks about Mobile Device Management, Mobile Application Management, Enterprise Mobility Management, etc. – and, no matter which acronym or segment is being discussed, the end-value ultimately comes down to protecting the corporate apps and data on a device. After all, supporting widespread device mobility isn’t very useful if everything on your devices is vulnerable.
The need for this kind of protection is a common topic of conversation with our enterprise customers since so much corporate data is cached on these devices – and we’re told over and over that the IT admins often have no control over the data (or where it goes next) once it’s on those devices. If you’ve seen this same lack of control in your own organization, I have good news.
In this post, I’ll examine something I touched upon earlier in this series in the Cloud-Device Convergence post: Multi-layered protection. I don’t know how to emphasize the value of this enough other than repeating it as often as I can; the layered protection that Microsoft is delivering in the Enterprise Mobility Suite is the only offering in the market that provides this comprehensive, multi-layered protection.
- Layer 1: Protecting at the device (MDM in Intune).
- Layer 2: Protecting at the app (MAM in Intune).
- Layer 3: Protecting at the file (Azure RMS).
- Layer 4: Protecting the identity and access (AAD Premium).
The other EMM vendors in the market are doing device and app protection, but they are completely missing file and identity protection.
The basic level of mobile device protection is for IT administrators to set policies that are applicable to the entire device. This is protection at the device level, and it is generally referred to as Mobile Device Management (MDM). For enterprise-grade device management, we have developed Intune to do the following:
- Enable common policies like Password policies and device encryption policies for all devices.
- ·Enable additional device restrictions like disabling Bluetooth, camera, or blocking document syncs to iCloud on an as-needed basis – all to strike a balance between security and user productivity.
- Take advantage of native capabilities of the underlying mobile operating system. For example, the iOS platform has a feature called “Open in Manage.” We recommend configuring this setting to restrict data from a managed app (Work apps) data to be opened only in other MDM managed apps.
In Q4 of 2014 we will update Intune and introduce a new feature called “Conditional Access Policy.” This feature will allow the administrator to grant access to O365 (e-mail and OneDrive for Business) or on-prem Exchange only if the device is managed by Intune and meets the compliance policy criteria specified by the IT administrator.
An example of this that I recently shared at Microsoft’s Worldwide Partner Conference (WPC) is conditional access to corporate e-mail. In this scenario, you can set a policy that a mobile device can only get corporate e-mail if the device has a power-on password, is encrypted, and is not jail broken. If any of these criteria are not met the flow of e-mail to the device stops and the user’s corporate inbox is emptied except for a single e-mail that informs the user that their device no longer meets the required corporate criteria. Helpfully, that single e-mail will instruct the user on how to bring their device back into compliance.
I used e-mail as an example in that demo, but the conditional access capabilities we’re delivering in Intune can be applied to other Office apps like the One Drive for Business app that accesses O365 services.
In addition to protecting at the device layer, most organizations are beginning to also provide protection at the app layer. This is usually referred to as Mobile Application Management (MAM). App protection enables organizations to apply security policies at the application layer, and this enables IT to protect the corporate apps and the corporate data being accessed and used in those apps (while leaving the user’s personal apps untouched).
Device protection is not a pre-requisite for app protection, but are often used together. For example, instead of requiring a PIN at the device level, an organization can choose to require a PIN only when the user launches an app that accesses corporate data. Our guidance is to protect at multiple layers and use both (plus the layers of protection I’ll detail below).
Application protection is usually done by either building the app with an SDK from an MAM vendor, or wrapping an existing app with the MAM vendor’s wrapper – either way the app is “invited” into a container that separates the corporate apps and data from the personal apps and data on the mobile device.
Over the coming months, we will be releasing both the SDK and app wrapper for Intune. Perhaps the most unique value that our SDK/wrapper offers – and which no other wrapper has – is that it empowers you to have your internal apps and the apps you are purchasing participate in the same container as the Microsoft Office apps running across Windows, iOS and Android. No other MDM/MAM solution will be able to manage the Office apps coming from Microsoft across the various platforms.
The Microsoft Office apps like Outlook, OneDrive, Word, PowerPoint, etc. provide the best productivity experience for end users across all of the mobile OS platforms. The upcoming versions of the Office apps will ship natively instrumented to be managed by Intune’s app management policies.
Those app management policies include:
- Restricting data leakage:
The following policy settings allow an IT administrator to control leakage of corporate data by restricting certain operations within the managed application:
- Allow/Block Copy/Paste
- Allow/Block Screen Capture
- Allow/Block Print
- Prevent file backup to unauthorized locations
- Restrict sharing of data between applications, e.g. data can be shared only between Intune data protection control-enlightened applications
- Enforce corporate data access requirements:
The following set of controls allow an IT administrator to require additional authentication when launching any application that access corporate data:
- Require a PIN for launching the app, e.g. the administrator can specify the PIN complexity and caching duration
- Require authentication using corporate credentials before launching the app
- Require compliance to device policies for launching the app, e.g. For example, if the device is jailbroken, the application will not launch
- Enforce encryption of app data at rest
- Application level selective wipe
When a device is lost/stolen, IT administrator can initiate a selective wipe in such a manner that only the corporate data within the Intune managed apps are deleted and all personal data is left untouched.
In addition to the above application level policy controls, Intune will also ship with a set of apps like a Secure browser, PDF viewer, image viewer, etc.
To further prevent data leakage, and IT Admin can use these new features (for example) to specify that attachments or URLs in e-mail can be opened only using these secure browser or viewers. This ensures that the same restrictions (like blocking copy/paste) works on those secure applications.
As I have mentioned several times before, the primary driver for an organization deploying an EMM solution is to protect the company data being accessed by and stored on mobile devices. The next layer of management you should be deploying is at the file level. To protect at the file level, you need something really special: Tools that embed the access privileges right in the file itself. In other words, the ability to make the file self-protecting.
To enable this level of file protection, we have developed Azure Rights Management Services (RMS). With Azure RMS, the File/Save action can grant access rights to the file and those rights can be written into the file itself. With these embedded access rights, even in the event that the file is accidentally sent to someone that shouldn’t have it (i.e. accidental data leakage), the person receiving that rogue file won’t be able to open it if you have not specifically named them in those embedded access rights. The file protects itself. Microsoft is unique in being able to provide this level of protection.
Azure RMS addresses the persistent and emerging security threats that all enterprises are grappling with – things like increasingly stringent regulatory policies (especially for sensitive medical data, or international business) and the continuing growth of BYOD and COIT. RMS-protected files can be sent to any devices or platform using Rights Management for Individuals, and we have already done the work to ensure the UX on these protected files is consistent.
Our goal (and I believe we’ve executed on it successfully) with RMS is straightforward:
- Support compatibility with virtually any file type
Regardless of the type of file you have, it can be protected.
- Choose your own platform
Regardless of the user’s device, a full-fledged RMS experience is available.
- Management flexibility
Admins have total control over the type of security and policy.
Like all of our cloud-based products, one of the biggest benefits of RMS is that it is continually receiving updates to improve its security features and refine the UX. For a mobile workforce, these ongoing updates are a huge value add.
For those of you who love architecture as much as I do, here’s what RMS looks like on
Whether your organization is already using cloud services (Office 365, for example, already supports RMS and includes exciting and powerful features such as Data Loss Prevention (DLP) functionality in Exchange and SharePoint), or if you’re considering doing so, there are a lot of ways for RMS to work for you. RMS features functionality from a fully cloud-based model, a hybrid model, or an on-prem model for organizations that simply cannot incorporate the cloud right now.
Identity protection/management is a massive topic, and it is one of the places where Microsoft really excels above and beyond anything else in the market (or on the horizon) from any of our competitors. This is the fourth layer of protection that we believe you should be actively implementing within your own organization.
Earlier in this series I wrote at length about Identity Management, and it is difficult to overstate just how valuable identity protection really is. The ability to govern the creation, publishing, and usage of SaaS apps (which can be used via single sign-on) is a major source of productivity, and this productivity is further extended due to the fact you can manage security from this same console (running in either Intune or SCCM).
We take identity protection so seriously that Azure AD (which is used for all the cloud-based authentication) is based on the rigorous Trustworthy Computing principals. In fact, our identity protection extends all the way down to passwords: Microsoft does not require you to store any user passwords in the cloud from the synchronized on-prem identities. Additionally, all access attempts are monitored and can be displayed via a simple set of reports that can track inconsistent access patterns (unknown source logins, multiple failed logins, logins from multiple geographies, etc.).
Reports like these put you in control and allow you to determine the best ways for your organization to manage access security, respond to potential threats, or make decisions about risk mitigation (like Multi-factor Authentication).
* * *
To see more about our protection solutions in action, check out this video from the Master of Mobility video series: