This episode was recorded at the Continental Hotel in Budapest, where Tony and I were joined by Office 365 MVPs Alan Byrne and Vasil Michev. We explore the wonders of the Spectre/Meltdown vulnerability and learn how it affects– or doesn’t affect– Exchange and Office 365 administrators– and we finally have a name for our “point/counterpoint” segment. Tune in to find out what it is.
Tag Archives: security
Happy New Year! To start the year off right, let’s talk about security. More to the point, let’s talk about Office 365 security.
One of the ways I often talk about Office 365 to customers is this: any time you move to a hosted service, you’re placing a bet that your hosting provider can do something better or cheaper than you do. Maybe they’ll deliver better uptime than you can afford to provide, or they’ll offer global reach, or some feature or function that you don’t currently have. As with any other bet, you have to carefully evaluate the odds and your counterparty (the person offering the bet). One of the big arguments in favor of Office 365 has been its security: Microsoft has invested a huge amount of money in physical and logical security for Office 365. Tie this in with the huge investment (several billion dollars and counting) brought about by Trustworthy Computing and you can see why Microsoft is eager to tout the security of their products: they have made huge strides over the last ten years. (Sadly, many other vendors are still as bad as they were back in 2005… let that thought sink in for a few minutes.)
In December, Microsoft released a patch, MS13-104, which every organization using Office 365 should immediately deploy. Microsoft rated this bulletin as “important” using their severity scale. While I understand that the “critical” severity is usually reserved for flaws that could allow remote code execution, I think this is just as bad because it allows an attacker to silently steal every document you have in a SharePoint Online document library.
Keep this tab open, then open a new tab and use it to start figuring out how to patch your clients ASAP if you’re using SharePoint Online. Then you can come back.
I won’t repeat the excellent analysis performed by Adallom Security, the folks who reported the flaw to Microsoft in May 2013. That’s right: they reported in May 2013, and the patch was issued in December 2013. That’s a minimum of 7 months of days-of-risk, which is bad enough without considering how long this flaw was being exploited before Adallom found it. However, I do want to make a couple of additional points.
First, they wrote their post before the recent spate of disclosures surrounding the NSA’s Targeted Access Operations (TAO) team and their catalog of exploits. There is of course no evidence that NSA developed or was using this particular exploit, but this is exactly the kind of silent, virtually undetectable attack that is the specialty of nation-states. The fact that Adallom’s customer is a large, high-profile enterprise is potentially bad news for Office 365 sales efforts, given that those customers are already a little leery of cloud services because of a perceived lack of security controls.
Second, this exploit apparently doesn’t work against Exchange Online or Lync Online, but that hasn’t been proven conclusively. Don’t hold off patching Office 2013 just because you aren’t using SharePoint Online.
Third, it seems to me that this kind of flaw is the natural consequence of breaking new ground. Seamlessly tying together on-premises and cloud services through a complex desktop suite is something that no other software company has even attempted: the major Office 365 competitors, such as Box.net and Google, don’t offer traditional desktop productivity apps, preferring instead to run inside the browser, where the design patterns and potential vulnerabilities of authentication are much better understood. So I don’t think of this as sloppiness necessarily on Microsoft’s part: sometimes in complex systems, people make mistakes. 210+ days-of-risk makes me a little nervous though.
My overall takeaway: if you have truly sensitive data that you want to protect, putting it in the cloud is not necessarily any more risky than keeping it on-premises. That may seem counterintuitive, but an entity that is determined to get your data has many potential avenues of attack, and my experience tells me that the vast majority of sites have a number of local vulnerabilities (such as poor patching practices, poor intrusion detection, or inattention to basic security practices) that put them at higher risk than a relatively esoteric, hard-to-exploit flaw like this one. if you don’t believe me, just look at the number of sites hit by Cryptolocker and various banking-related Trojans. Put another way, you don’t need to worry about defending yourself against NSA if you can’t even manage to defend yourself against script kiddies.
Now go forth and patch!