Microsoft Office 365 Message Encryption: A Critical Challenge
Microsoft Office 365, Microsoft’s enterprise cloud offering, provides excellent default email and file security, but many customers require additional encryption and data protection capabilities to meet regulatory, compliance, or privacy needs. Email remains the most common method of business communication: It’s where companies create, house, and share their most valuable information. So when unauthorized third parties go searching for corporate data, they know exactly where to look.
By entrusting Microsoft with their email, businesses and governments solve key infrastructure and collaboration problems, but they often require additional capabilities to help with other encryption-related issues, such as:
According to the information technology research and advisory company Gartner, organizations face several challenges when evaluating email encryption solutions:
As such, Gartner suggests that successful email encryption solutions should adhere to the following principles:
With these privacy and security concerns in mind, it’s essential that Microsoft organizations understand the encryption options available to them, how these solutions work, and when it makes sense to deploy them.
Understanding Office 365 Encryption Options
To meet advanced data protection and encryption requirements, most Office 365 customers rely on one of the following:
Native Office 365 Encrypted Email
Default Outlook desktop and Outlook Web App (OWA) encryption protects emails as much as possible. These Office 365 email clients encrypt messages both when they’re stored (data at rest) and when they’re being sent (data in motion). Like most cloud email providers, Microsoft uses Transport Layer Security (TLS) to encrypt emails in transit. But TLS depends on both the sender’s and recipient’s email provider, so it won’t work in some situations.
TLS is a type of point-to-point encryption; when you send an email from Outlook or OWA, your mail client contacts Microsoft’s server and creates a secure connection. The message is encrypted, sent to the server, and decrypted. The server repeats the process with the next server, until it reaches your recipient’s server.
If both parties use Outlook or OWA’s default encryption, the risk of your message being compromised is very low. However, if your recipient’s email service doesn’t use TLS, messages won’t be encrypted. Even if both parties use TLS, the message could pass through a hacked or improperly configured server outside of the Office 365 network, allowing a 3rd party to decipher and read it.
In addition to these default options, Microsoft offers its own email security add-on, Azure Rights Management (RMS), which can be purchased for an additional fee on top of a customer’s Office 365 subscription. Azure RMS encompasses two product offerings:
Azure RMS processes email security policies at the network level, after messages have left the sender’s Outlook or OWA inbox and are received by Microsoft’s Office 365 mail servers. Messages are encrypted in transit via TLS until they reach Microsoft’s servers, at which point
Microsoft stores the customer’s unencrypted content on a hosted portal to ensure that email will be protected for all recipients – even those whose email servers do not have TLS configured.
As with Outlook and OWA’s native TLS, Microsoft can access the unencrypted content shared by Azure RMS customers, which makes it more difficult to meet certain data residency, privacy, and compliance (CJIS, EAR, etc.) requirements in Office 365.
Sending with Microsoft Azure RMS relies on customers to build policies that match a particular text string, such as “encrypt,” in the subject line or message body in order to activate encryption. If users forget to utilize keyword triggers, their emails may be sent without encryption.
Recipients who have already configured Azure RMS onto their email servers can read Azure RMS messages transparently. If recipients do not have Azure RMS configured, they will receive an email containing an HTML attachment and instructions on how to download it.
If their organization security policies permit them to download the attachment, recipients will then have the option of creating a new Microsoft account, signing in with their existing Microsoft account, or accessing a one-time email code. After authenticating, recipients can view and reply to the decrypted message in a web reader that is hosted on Microsoft’s servers.
Via AIP, Azure RMS customers can add some control permissions to individual emails – such as message expirations and forwarding control – but only recipients at other Microsoft organizations can read messages sent with them, which poses a risk when sharing externally. As a result, most Azure RMS customers can only use control capabilities after confirming that each of their recipients has the technical requirements needed to view AIP-protected messages.
Azure RMS can be difficult for administrators to deploy, but it provides a seamless experience when sharing with recipients whose organizations also use Office 365 Message Encryption. It meets some Microsoft security use cases, but does not offer client-side encryption or control, and as a result, many privacy and regulatory requirements may not be covered.
Since certain protected-messages can only be read by other Microsoft customers, Azure RMS does not satisfy many organizations’ ease of use and cross-platform accessibility expectations for enterprise-grade encryption. As a result, most Office 365 customers rely on third party security vendors to fill in the gaps that Microsoft’s native tools have been unable to fill.
Portal-Based Encryption: The Legacy Email Security Approach
Has your bank or doctor every sent you an email that required you to create a new account and leave your inbox to view? If so, you likely have experience with portal-based email encryption – a legacy approach offered by most third party Office 365 security vendors in the market.
With portal-based encryption, an administrator identifies certain keywords or other message criteria that trigger encryption when detected. Recipients are notified by email, and can then establish a user ID and password to access their content separately from their Outlook or OWA inboxes via web portals.
Like Azure RMS, portal-based encryption takes place exclusively at the server level, after emails have already left the sender’s device and made it to the cloud. This architecture adds additional security by requiring new usernames and passwords to access sensitive content, but – as with Azure RMS – unencrypted plaintext is sent via TLS connection, giving intermediate providers access to this unprotected content.
This distinction means that portal providers manage the encryption keys protecting customer content and could have access to unencrypted versions of emails and attachments sent through their systems. This architecture introduces additional security risks and does meet the requirements of certain regulations like ITAR and CJIS, which mandate that no intermediate party can ever have access to unencrypted content.
What’s more, most portal-based encryption providers do not offer any email access control features, so senders and administrators have no way to audit and manage where their emails travel after leaving the organization.
The only way to restrict third party access to your Office 365 data, while also maintaining the ability to control this data wherever it travels, is via object-level email encryption technology that incorporates client-side encryption and customer-managed keys.
Virtru Data Protection for Microsoft Office 365
Virtru protects emails and attachments using object-level, or data-centric, encryption. This means that data is encrypted the moment it is created, and it remains encrypted no matter where it travels.
Like regular Outlook and OWA messages, content is transmitted and stored on Microsoft’s (or any recipient’s mail provider’s) servers, but in encrypted form. The encryption keys that protect these emails are stored on Virtru’s servers, and access to them is always managed by the customer.
Since protected content and encryption keys are stored separately, neither Microsoft nor Virtru – nor any other cloud provider – can access unencrypted customer content.
In addition to its Network Data Protection option, which encrypts data at the server-side no matter from where it’s shared, Virtru provides client-side encryption – a powerful form of encryption that Azure RMS and portal-based vendors do not offer. This means that, unlike Azure RMS and portal-based vendors, Virtru can encrypt your Outlook and OWA messages on your computer before they ever reach the cloud. Until Virtru-protected emails and files reach their destination, they remain encrypted, meaning that Microsoft and other intermediary third-party providers can never access unencrypted messages.
Virtru integrates encryption directly into the sender experience in major browsers, email clients, and devices with minimal disruption or change to the way users work. With a simple toggle in Microsoft Outlook or OWA, senders can decide on-demand which messages and files to encrypt, and they can indicate which messages were sent out with encryption.
For recipients, Virtru uses existing platform credentials to enable recipients to decrypt and consume messages and content, so there’s no need to create new passwords like there is when using portals. This decryption can occur using either federated identity authentication (OAuth, OpenID, SAML) or using an email confirmation loop. In all instances, Virtru provides recipients with two authentication options:
Just like sending and reading, Virtru configuration is also straightforward. Individuals can download the client-side plugins directly from Virtru’s website, or administrators can push them out directly to their end-users.
Once configured, Virtru offers a centralized dashboard from which administrators can view active Virtru users, track where end-user emails travel and control access, and configure data loss prevention (DLP) rules to detect and automatically encrypt sensitive information.
Since Virtru offers client-side DLP in addition to network level scanning, customers can enable DLP policies that do not require Virtru to access customer plaintext, which is sometimes necessary for regulatory and business privacy requirements. Azure RMS and most portal providers also offer DLP functionality, but these vendors can only scan end-user content at the network level, which means that customers must give these third parties the ability to scan their unencrypted content to identify policy indicators.
Virtru also offers a Customer Key Server (CKS) feature that enables organizations to maintain complete and exclusive access to the encryption keys that protect their data. The CKS adds public key encryption to Virtru’s standard SaaS product, so that the encryption keys hosted on Virtru’s servers are encrypted by additional keys that only the customer can access.
As a result, Virtru customers can choose where their encryption keys are stored, either in the cloud or on a physical device.
Since Virtru offers a more modern, object-level architecture than Azure RMS and the portal providers’ legacy network-centric approaches, it allows users and administrators to exercise granular, persistent control of emails and files across different platforms.
While Azure RMS does not offer the ability to add information protection capabilities to emails
that leave Microsoft’s systems, Virtru allows both senders and administrators to manage access to encryption keys. As a result, customers can apply the following control capabilities for their messages even after they’ve been read:
Virtru’s integration directly into existing email platforms provides a user experience that mirrors Outlook and OWA. The combination of client-side encryption with customer-managed keys provides enhanced levels of privacy and control that enables organizations to protect data even when it leaves the Microsoft ecosystem.
In particular, the following capabilities allow Virtru to meet most privacy and regulatory requirements for Office 365 organizations:
Looking to add an extra layer of protection to your Office 365 encrypted email? Let’s chat.
Contact us to learn more about our partnership opportunities.