I used to think it was. After all the amazing things you read on the O365 Trust Center, you all but think it is Fort Knox (well, at least one part of it is right Bill Baer?)
Let me go back to that title. "O365 is not secure…once you start adding users". Last week I blogged about a security oversight in O365's partner sharing feature. Basically what this means is that once you accept an invitation from a partner (aka a "user"), you become just another customer in their "customer management" portal. You can read more about this feature here:
http://blogs.office.com/2014/01/28/introducing-the-new-office-365-partner-admin-center/
Do you know who else they have as customers and who is accessing your data and when? No. They don't really have any logs to tell you when a partner is accessing your portal for accountability. Nor do you know who on the backend is working on your O365 deployment project. Just too many unknowns to say it is secure.
O365/Azure Apps
But that's not the focus of this post. A few weeks ago, O365 released the O365 APIs for Exchange (Mail, Contacts, Events and Files). All of this piggybacks on Azure Active Directory for authorization utilizing the Consent Framework. The Azure AD platform allows you to build an application that can make calls to Azure Active Directory or your O365 data. The permissions of the consent framework can allow an application to read the current mail item, all your mails items, your contacts, your calendar…your files.
As a simple example, one of the more impressive abilities is to create a Mail App. You can do this using Visual Studio 2013 and creating an App for Office project. This isn't going to be a developer post so I'm not going to show you any code, but simply talk about the importance of "Mail Apps" and your users.
Once you have a Mail app created, you can deploy it to your O365 instance, or even post it in the Office store. You can find a small set of mail apps in the following link (these have been publicly deployed to the office store, but you can have rogue apps that simply are registered somewhere in Azure AD and users give them ad hoc permissions):
http://office.microsoft.com/en-us/store/apps-for-outlook-FX102804983.aspx?app=outlook.exe
Many of these are poorly designed (for example, the LinkedIn app is a total disaster, the cert is locally generated and not even a public CA). In some cases, you may find the deployment endpoint isn't even available so the app install fails. If you were to install one of these apps, you will find that they simply request access to the "current" mail item. This is the preferred scenario if you were to use these apps. In some cases however, you may find that the app is given "carte blanche" to your entire mail inbox.
So back to users and mail apps. When you are in your Outlook, your users will ultimately find the settings icon and this nice menu item called "Manage Apps":
Clicking on this, they will be taken to the "Exchange" app center. This is where you see administrator installed apps and user installed apps:
This is JUST for Exchange. This has nothing to do with the bigger picture of Azure AD Apps and the consent framework. There are some governance controls implemented in the Exchange app architecture, however, when it comes to Azure AD and your tenant, the story hasn't been written yet. This goes back to the premise of this blog post. All it takes to make your highly secure O365 environment to be unsecure is:
- A user
- An App
- A click
The permissions given to that app can now comprise the integrity of your entire system. When on-premise, you at least had the ability to prevent incoming requests using your router and DMZ. In this instance, O365 doesn't have any of that, so once permissions have been given, that's all folks. So what hacking scenario might come up?
- Hacker builds an Azure app, puts your company name and logo on it
- Hacker does some social engineering to find out your name, title, work phone number and other information
- Hacker asks you to install the app and because it has your logo and company info, your user thinks nothing of it and clicks "trust"
- Hacker can now gain access to an access token that can be used to download all your email and your my site files
If you are in defense or government, you know hacking enemy number one is China. For those of you that think that insensitive to say, you haven't watched the traffic logs with the FBI and CIA as it happens, almost on a daily basis. But the US is not a good guy when it comes to that stuff either, so all is fair in love and war.
O365/Azure App Governance
It is my suggestion, that you disable the ability for users to add apps. It simply creates security holes that equate to users writing company checks that can't be cashed. So, with that recommendation, can I provide you the steps to deny a user the ability for users to add apps" in your tenant, *sure*, thanks to some recently surfaced info (see below) [:D] (thanks to @richdizz, @jthake and @Matthias1o1) In terms of Exchange, there are some user roles in Exchange that you can "remove" to prevent users from deploying apps, these roles are enabled by default:
————————
[UPDATE 6-5-2014] After this post the following was brought to my attention from the O365 team. It is a non-UI based way to disable all user consent, thanks to the O365 team for pushing this content out!:
————————
Even with the above update, what is still not available to us is an Azure AD UI (to make it more apparent of the risk) that allows me to
disable apps, and/or designate a "safe/white list" of apps that my users *can* utilize in Exchange or Azure AD.
Just for kicks, I have created a UserVoice suggestion that more advanced App Governance features (such as a UI and white list) be added to Azure AD and O365, you can vote for it here:
My God, What Have You Done?
So, this brings up an interesting point. Last night at the SanSpug.org meeting I announced that we have moved to Auth0.com as our auth mechanism as it provides the most flexibility and telemetry data. One person asked, what is telemetry data? I said every time you login, I get data about you (first name, last name, email, blah blah). It freaked out half the group. Only one person was educated enough to know which of the supported auth systems had the least amount of data being sent. So again, this brings up that interesting point I started this paragraph with…do you know what apps you have simply just clicked on the "authorize" button just so you could use the app? I bet you don't, my god, what have you done? Think about all those apps across all your services (facebook, twitter, liveid, google, etc). So in an effort to help you understand just how bad this is going to get with O365, based on how bad it has gotten in a general sense, here is the links to where you can check what you have authorized for each of the major platforms:
Facebook:
https://www.facebook.com/settings?tab=applications
Twitter:
https://twitter.com/settings/applications
Google:
https://security.google.com/settings/security/permissions?pli=1
LiveID:
https://account.live.com/consent/Manage
eBay:
http://cgi6.ebay.com/ws/eBayISAPI.dll?ManageESubscriptions
Yammer:
https://www.yammer.com/YOURDOMAIN/account/applications
SharePoint:
I suppose you could say that this page (http://youweburl/_layouts/15/viewlsts.aspx) is as close as it gets? At a farm level, in O365:
https://yourdomain-admin.sharepoint.com/_layouts/15/TA_AllAppPrincipals.aspx
On-premises:
http://centraladminurl/_admin/AllAppPrincipals.aspx
Azure AD:
Back to the question…"My god, what have you done?" After clicking on all those links, I'm sure you have an idea of just how bad the problem has gotten. Some of you might be surprised to find out that your Hotmail/Outlook.com email and OneDrive (consumer) files have probably already been downloaded and analyzed by that cool app you gave permissions too. Most of you that read my blogs are the cream of the intellectual crop. You understand what that "Trust" dialog means. For the rest of the population, not so much. The meaning of the word "Trust" has been eroded by fancy graphics and the promise of a simple functionality at the expensive of selling your data soul to the app provider. That all being said, its time for enterprise solutions to have a "white list" to keep users from eroding the meaning of "Trust", to anyone's dog or cat. One last thing on O365, no matter how secure you make the back end, its the front end that matters.
CJG