"Are you the Key Master?" "I am the Key Master, are you the Gate Keeper?" Those aren't merely lines from the "Ghostbusters" movie, but the question IT has to ask more and more about protecting even encrypted data.
The goal of encryption is clear: To prevent unauthorized people from reading what they should not. Even if someone intercepts your messages or a cloud provider's engineer opens your data stores, that encrypted data should be worthless without the key. Encrypted data must have a key (aka a cypher) to be unlocked.
Thus, protecting those keys -- who has access to them -- is the biggest challenge in safeguarding that data. Although your technology provider may offer tools to encrypt your data, you might need to do more to protect those keys and perhaps even bring your own.
What Microsoft offers to safeguard your data
Office 365 offers multiple encryption tools:
- BitLocker (for AES encryption) for drive-level encryption (for data at rest)
- Content-level, per-file encryption for Skype for Business, SharePoint Online, and OneDrive for Business (also for data at rest)
- FIPS 140-2 Level 2 encryption for email (for data at rest)
- TLS (Transport Layer Security) for emails in transit between servers and SSL (Secure Sockets Layer) encryption for email in transit between the email client and server
- OME (O365 Message Encryption), which is built on Azure Rights Management (Azure RMS), for encrypting the email itself whether it is at rest or in transit, using transport-controlled cryptography and keys.
- S/MIME, for encrypting the email itself, using client-controlled cryptography and keys
It sounds like all our bases are covered, right? Yes, if your goal is security. However, privacy is another major concern with data stored in or moved via the cloud. If someone -- the police, a government, a competitor, a hacker, a spy -- has the key or can re-create it, that entity can read that data and any corporate or personal information contained within, even if they cause you no explicit harm.
To satisfy that need for customers to have more control over their own content, Microsoft offers several technologies. One is the Customer Lockbox feature, which basically makes it so that the only way a Microsoft engineer can gain access to customer data stored in Office 365 is by requesting permission. No permission? No access. (Keep in mind that Customer Lockbox is available only as part of an E5 license.)
Microsoft announced last year it's working on additional security features that build on the content-level encryption capabilities in Office 365, including the ability for customers to generate and control their own keys.
The case for BYOK
The ability to bring your own key (BYOK) is huge. Office 365 MVP Dan Holme said, "It's the Holy Grail for a service like Office 365. Effectively, it means that Microsoft itself cannot access your data at all. The customer holds the key." (This is the same approach BlackBerry has long taken in its BlackBerry Enterprise Service management server and that Apple takes on its iPhones and iPads, but not yet in its iCloud service.)
For some customers, that is an absolute must. For example, one forum request in the Spiceworks community says its compliance rules state, "Data owner must maintain complete control over the encryption keys at all times, and no personnel from the cloud service provider should have access to the keys."
Why would admins need or want to control their own keys? Fear of intrusion into organizational privacy is the answer. That fear has been exacerbated by former NSA contract Edward Snowden's spying revelations and the ongoing fights between Apple and the FBI and between Microsoft and the U.S. Justice Department over government access to customer data.
Those U.S. government actions, an effort in the United Kingdom to require government access to nearly all records, similar efforts in other countries, and a series of data breaches at technology providers all have eroded corporate trust that both their customers' and their own privacy is maintained.
According to Holme, BYOK would ensure the customer must also be subpoenaed, not merely the technology provider such as a cloud vendor. Why? Because the vendor doesn't have the key -- only the customer does. "This would ensure that customers are aware when and if their data must be turned over for legal reasons, and in theory would add enough political complexity to reduce the potential of that ever happening," Holme said.
But BYOK is not simple. As my colleague Mary Branscombe has explained, BYOK involves significant effort by the customer to provision and maintain. If you lose those self-provisioned keys, you're in a pickle: Your vendors cannot retrieve what they don't have. Although your vendors cannot give your keys to someone else, they can't give them to you, either.
One approach is to set up a key repository secured by a separate key. Microsoft does that for Windows 10 users via their Microsoft accounts. Apple has long done the same for OS X users with its FileVault encryption service. For enterprise users, Microsoft offers Azure Key Vault, which works with hardware security modules to safeguard your keys in the cloud. Again, you're still working with a single vendor to protect the keys to the data they hold. That may not be what you need.
You might want to transfer that responsibility to another vendor, to make it more complex for someone to get to those keys. For example, you'd have Microsoft hold your data, which is encrypted using keys you create and manage, but a cloud-based service stores copies of those keys in a key repository. Such vendors include CipherCloud and KeyNexus.
Right now, this is a theoretical option for Office 365, since it doesn't yet support BYOK. When it does, you'll have to weigh the value of that added privacy protection against the overhead of achieving it. I know some companies for which the cost will be worthwhile. Maybe it is for you, too.