Tag Archives: Office 365

Microsoft, encryption, and Office 365

So the gloves are starting to come off: Microsoft general counsel Brad Smith wrote a long blog post this morning discussing how Microsoft plans to protect its customers’ data from unlawful interception by “unauthorized government access”. He never specifically mentions NSA, GCHQ, et al, but clearly the Five Eyes partners are who he’s talking about. Many other news outlets have dissected Smith’s post in detail, so I wanted to focus on a couple of lesser-known aspects.

First is that Microsoft is promising to use perfect forward secrecy (PFS) when it encrypts communications links. Most link-encryption protocols, including IPsec and SSL, use a key exchange algorithm known as Diffie-Hellman to allow  the two endpoints can agree on a temporary session key by using their longer-term private/public key pairs. The session key is usually  be renegotiated for each conversation. If Eve the eavesdropper or Mallet the man-in-the-middle intercept the communications, they may be able to decrypt it if they can guess or obtain the session key. Without PFS, an attacker who can intercept and record a communication stream now and can guess or obtain the private key of either endpoint can decrypt the stream. Think of this like finding a message in a bottle written in an unknown language, then next year seeing Rosetta Stone begin to offer a course in the language. PFS protects an encrypted communication stream now from future attack by changing the way the session keys are generated and shared. Twitter, Google, and a number of other cloud companies have already deployed PFS (Google, in fact, started in 2011) so it is great to see Microsoft joining in this trend. (A topic for another day: under what conditions can on-premises Exchange and Lync use PFS? Paging Mark Smith…)

Second is that Microsoft is acknowledging that they use data-at-rest encryption, and will be using it more often. Probably more than any other vendor, Microsoft is responsible for democratizing disk encryption by including BitLocker in Windows Vista and its successors, then steadily improving it. (Yes, I know that TrueCrypt and PGP predated BitLocker, but their installed bases are tiny by comparison.) Back in 2011 I wrote about some of the tradeoffs in using BitLocker with Exchange, and I suspected that Microsoft was using BitLocker in their Office 365 data centers, a suspicion that was confirmed recently during a presentation by some of the Office 365 engineering team and, now, by Smith’s post. Having said that, data-at-rest encryption isn’t that wonderful in the context of Office 365 because the risk of an attacker (or even an insider) stealing data by stealing/copying physical disks from an Office 365 data center is already low. There are many layers of physical and procedural security that help keep this risk low, so encrypting the stored data on disk is of relatively low value compared to encrypting the links over which that data travels.

The third aspect is actually something that’s missing from Smith’s post, expressed as one word: Skype. Outlook.com, Office 365, SkyDrive, and Azure are all mentioned specifically as targets for improved encryption, but nothing about Skype? That seems like a telling omission, especially given Microsoft’s lack of prior transparency about interception of Skype communications. Given the PR benefits that the company undoubtedly expects from announcing how they’re going to strengthen security, the fact that Smith was silent on Skype indicates, at least to suspicious folks like me, that for  now they aren’t making any changes. Perhaps the newly-announced transparency centers will provide neutral third parties an opportunity to inspect the Skype source code to verify its integrity.

Finally, keep in mind that nothing discussed in Smith’s post addresses targeted operations where the attacker (or government agency, take your pick) mounts man-in-the-middle attacks (QUANTUM/FOXACID)  or infiltrates malware onto a specific target’s computer. That’s not necessarily a problem that Microsoft can solve on its own.

Leave a comment

Filed under Office 365, UC&C

The future of importing large quantities of Exchange data to Office 365?

It wouldn’t be accurate to say “you can’t”, but Microsoft doesn’t make it easy.

Whether you’re moving mailboxes or PST data to Office 365, your imports are throttled; that is, Microsoft imposes a limit on how fast you can move information into their data centers. The exact speed of your import process will vary according to a variety of factors, including what protocol (IMAP4, MAPI, or EWS) you’re using, what migration tool you’re using, and how many concurrent threads it can spin up, how busy the data center you’re importing into is, and the mix of item sizes in the mailboxes or PSTs you’re importing.

The problem with this throttling is that it’s largely opaque. Although Microsoft publishes “observed data,” my own observations have shown that migration throughput can vary widely based on these factors and a bunch of others besides, possibly including the phase of the moon and whether you have recently said anything disparaging about Microsoft anywhere on the Internet.

Recently I had a customer who wanted to migrate 30TB of PST data to Exchange Online Personal Archives. While this might sound ridiculous, it makes perfect sense given that Office 365 E4 plans include an unlimited-size Personal Archive for each mailbox. That’s a hard deal to beat… if you can figure out how to get the data in. At one point, in a fit of frustration we asked Microsoft whether we could just send them a bunch of disk drives containing the PSTs. “Of course not,” they said (with “silly boy” being the unspoken coda to that phrase). But it turns out that Azure is now providing bulk import of data by sending disks to them: the Windows Azure Import/Export Service is now in preview. With any luck, we’ll see a similar service from Office 365 in the not-too-distant future. And when it happens, remember, Andy Tanenbaum had the idea first.

3 Comments

Filed under Office 365, UC&C

Office 365 PhotoSync and the third-party market for Office 365

Office 365 has its own thriving MVP community, and fellow MVP Loryan Strant sent me an announcement of a new product he’s developed for Office 365: PhotoSync. The purpose behind the tool is to ease the process of managing user photos in enterprises by providing a better tool for managing user photos. There are tools that provide similiar functionality for on-premises deployments, of course, but this tool’s unique approach (or perhaps unique marketing, as I haven’t tried it myself) is to focus on the fact that many Office 365 deployments will use directory synchronization to get directory information from the on-premises deployment to Office 365.

Using a shared hosted service means accepting some compromises; for example, Microsoft greatly limits subscribers’ ability to customize SharePoint or to configure various aspects of Exchange such as database and DAG settings. This might seem to limit the possibilities for developing software products to supplement Office 365. I think it’s a healthy sign that third parties such as Loryan are developing add-ons and utilities for use with Office 365, although I suspect that only the most agile organizations will be able to identify opportunities and exploit them fast enough to keep up with the cadence of feature and service updates that Microsoft seems to be aiming for.

More on PhotoSync in the future…

1 Comment

Filed under Office 365

Keeping up: Office 365 OnRamp changes

Microsoft Exchange Server 2013 Inside Out: Clients, Connectivity, and UM (colloquially known as “the book”) is now in production! I’ve reviewed all the page proofs, corrected the few composition and layout mistakes I found, and returned the proofs to the editorial staff so they can turn PDFs into paper. It’s pretty exciting, although thanks to my tardiness the book won’t be ready in time to be sold at Exchange Connections (about which, more tomorrow.) However, I’ve been assured that Tony’s book on Mailbox and HA will be available there.

About a month ago, I wrote this in the Office 365 chapter:

One of the difficulties inherent in writing about cloud services is that they can change rapidly and often. The screen shots of Office 365 in this chapter reflect its appearance and function as of late 2013, but it’s likely that some of the underlying Office 365 code will change, so don’t be surprised if what you see on screen doesn’t exactly match what you read here.

As if to reinforce that point, today Microsoft has changed the OnRamp tool that you use to assess your organizational readiness for Office 365. The readiness review portion of the tool seems to have disappeared, leaving the checklist portion (which is similar in intent to the Exchange Deployment Assistant, another topic covered in the chapter). I haven’t found where the readiness review went, but I’m fairly sure it still exists somewhere in the maze of Office 365 tools.

The moral of this story? Although Microsoft likes to mock Google’s habit of suddenly introducing changes to end users without warning, they are starting to develop the same habit, except it mostly affects administrators. I hope this particular change was just a slip and not a harbinger of the way toolset changes will be handled in the future. (The secondary moral: man, it’s going to be a challenge to keep up with Office 365 updates in anything I write in the future!)

Leave a comment

Filed under UC&C