Latest posts by Kyle Beckman (see all)
- Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
- Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
- Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016
In December 2014, Microsoft acquired Acompli, a software company that made mobile email apps for iOS and Android. Shortly after the acquisition, Acompli was rebranded to Outlook for iOS and Android as the successor to the OWA apps for iOS and Android. Microsoft has said that the OWA apps will be replaced by the new Acompli/Outlook app when features such as the ability to view Information Rights Management protected mail and Apps for Outlook are available in the new app. After those features are added to Outlook for iOS and Android, I’m sure we’ll see a formal announcement about end of support for OWA.
The writing is on the wall: the OWA app is going away and the new Outlook app is the app that will be supported moving forward.
Shortly after the release of the new Outlook app, a blog post started circulating about how the Outlook app would break your company’s security that advocated blocking the app. Specifically, the cited security concerns are the file sharing capabilities (connectivity to OneDrive [consumer], Dropbox, Box, and Google Drive), shared Exchange ActiveSync ID and device type, and credential storage. Let’s dig into each one of those.
As of the publication of this article, the Outlook app for iOS and Android allows a user to connect to OneDrive (consumer), Dropbox, Box, or Google Drive.
The risk with allowing an end user to connect to any of these services is that users can easily save email attachments from their corporate email account into one of these services, outside the control of corporate IT. You might think that this is a huge nightmare for protecting company data—especially if you’re dealing in credit card numbers, social security numbers, or other personally identifiable information (PII).
Here’s the problem: how much control do you have over that now? The proliferation of cloud services has made blocking them at the border nearly impossible—especially when those are the services that people want to use or if they have to work with other organizations (such as customers) that do use these services. Even if you block every one of these services at the corporate network border, employees will bring in USB drives, access them when off the corporate network on a laptop, or find other creative ways around the security measures.
What’s the solution? Microsoft’s solution to protecting data is Rights Management Service (RMS). It is available in both an on-premises version (Active Directory Rights Management Services [AD RMS]) and a cloud version (Azure Rights Management [Azure RMS]). RMS protects the file itself based on its content and rules that the organization writes. If a file is protected by RMS and saved to a public folder on a cloud storage location, only the authorized employees in the organization can open the file. With AD RMS or Azure RMS in place, IT doesn’t need to care where files get saved because they’re protected regardless of storage location.
Shared Exchange ActiveSync ID and device type
The Outlook for iOS and Android app depends on a back-end cloud service to check for mail and send push notifications to the device. Because of this architecture, Outlook for iOS and Android will always show up as one device with one ActiveSync ID regardless of the number of devices an end user has connected.
The obvious risk here is that, if an end user loses his/her device, you can’t identify it because all of the devices appear as a single device. And, unfortunately, there’s not a good answer for that. If a remote wipe becomes necessary, the Outlook app is going to be wiped on every device the end user has connected.
But, that’s also the benefit of this architecture in my book: only the Outlook for iOS and Android app gets wiped out. In a BYOD environment, this is a good thing. The remote wipe doesn’t reset the device back to a factory condition; it selectively wipes the Outlook app and all data in the Outlook cloud service. The worst-case scenario is that the user has to set up the Outlook app again.
In the original release of the Outlook app for iOS and Android, authentications against Office 365 Exchange used basic authentication. This could mean your credentials were stored in a Microsoft–run cloud service that resided inside Amazon Web Services.
As of a June 2015 update, Office 365 Exchange now uses OAuth in the Outlook app, removing the possibility that Office 365 credentials will be stored. The new authentication procedure uses Active Directory Authentication Library (ADAL)–based authentication. Accounts with a cloud-based username/password are directed to an Office 365 sign-in page; accounts with an Active Directory Federation Services (ADFS)–based username/password are directed to the ADFS sign-in page. Office 365 Exchange joins Outlook.com, OneDrive, Dropbox, Box, and Gmail as services that use OAuth within the Outlook app.
As of the publication of this article, Yahoo, iCloud, and on-premises Exchange Server do not support OAuth. For these services, the Outlook app does store your credential in encrypted form in the Outlook cloud service. A random AES-128 key (called a device key) is generated during the first run of the app. When a user logs in to a non-OAuth service, the username, password, and device key are transmitted to the Outlook cloud service via a TLS encrypted connection. The cloud service verifies the password and then encrypts the password with the device key. The device key is then wiped from memory, never having been stored on disk. When a user checks for mail, the device key is sent to the cloud service and used to decrypt the encrypted password. After the Outlook cloud service has checked for mail, the device key is wiped from memory again.
If you’re using Office 365 Exchange, the move to OAuth in the Outlook app removes the concern about stored credentials. However, if you’re running on-premises Exchange, the storage of user credentials (even in encrypted form) is a risk that your security department will have to consider.
One additional risk in the current architecture is the use of Amazon Web Services to run the Outlook cloud service. Microsoft has said that a “coming IT control” is the move of the cloud service from Amazon Web Services to Microsoft Azure, but the company has not offered a timeline for when the move will be made. The current iteration of the Outlook web service does meet Category A of the Compliance Framework for Office 365, which does not include EU Model Clauses (EUMC), HIPAA Business Associate Agreement, or FedRAMP, just to name a few. I hope the move to Azure will clear up many of these current limitations.
What about your organization? Have you disabled Outlook for iOS and Android? Do you plan on enabling it at some point in the future? Let us know what you think in the comments.