Hello – me again.
Because there’s been such a surge of questions and interest concerning “secure email”, I want to take a few moments to capture some relatively important details about this.
From recent reviews of several Office 365/Exchange Online (EOL) business environments, specifically bi-directional transmission of external email and communication practices, it was discovered (unbeknownst to the business) an inordinate number of unsecured communications, containing sensitive information, were found being sent and received outside the organization (between vendors, business partners, etc.) – specifically sensitive legal, human resources, purchasing, etc. information. However, before getting nervous or calling in the troops, let’s put this into the proper perspective.
The security challenge, referred to herein, occurs when an email leaves the business destined for another (external) business. To put a “not-so-techie-spin” on this – sensitive email typically becomes a security matter, or concern, the moment it’s sent to an external recipient. This data could include social security numbers, purchasing history, legal matters, etc.
Without jumping head-on into discussions concerning internal emails; this wouldn’t “typically” be a matter of concern. However, where concern does exist, several remediation methods can be employed to address internal transmission of sensitive information (e.g. message signing and encryption, transport rules, etc.).
If sufficient reason does exist, emails can be signed, encrypted and secured to ensure end-to-end security, thus providing controls over who can open, forward and print messages. However, when one is utilizing a SaaS based email solution like Office 365/EOL, email remains sufficiently secure within the confines of the business.
If you or a business partner using Office 365/EOL, sends email between your businesses, it is already encrypted utilizing opportunistic TLS. No configuration is really needed. This is very good news for those who presently have their business on Office 365/EOL. (click for more information)
However, in some cases, businesses managing their own email systems ought to take advantage of this particular feature by enabling and making it available to your customers, business partners, etc.
There exists many articles or consultants who can help with, clarify or implement these security elements. This article though doesn’t cover the necessary “per se” steps. The purpose of this is to increase the awareness, advantages and benefits of why a business might undergo this effort. Simply put, the real benefit to enabling secure email is knowing all communications sent between your organization and another will not be subject to prying eyes or eaves dropping.
Businesses today have many partners and external entities. The first step is to make a list identifying those where sensitive information enforcement is required. The next step is to launch an initiative to secure these communication channels without impacting production. Although only lightly touched above, other methods can be employed to further secure email transmissions.
To reiterate, as mentioned above, opportunistic TLS is enabled (by default) for all Office 365/EOL customers. Meaning, email which traverses between EOL customers is fully encrypted. This can be validated by analyzing message header information. This is also of particular interest because customers looking to enable or provide TLS communications, who currently reside on Office 365/Exchange Online, already have this feature. This is certainly a plus point. Another plus point is most major SaaS based email provides, such a gMail, offer (TLS) secure transmission of email.
Unless specifically configured, businesses who manage their own mail services, which do not reside on Office 365/EOL, typically do not have this feature enabled. This could include a Lotus Notes deployment, Exchange on-premises implementation, Iron Port (SPAM/Malware inoculation, SMTP relay), etc.
What does this mean? It means simply there is an opportunity to make these more secure. The good news is, it can be readily enabled with very little effort.
TLS Integration: Notifications
There are a few other facets one ought to analyze and inspect when transitioning a business to a SaaS email service (such as Office 365/EOL). For instance, most businesses need to maintain some form of internal alerting or notifications via email. Or perhaps your business maintains an internal database which performs weekly email batches for clients. Most often, this can include lower forms of sensitive information (e.g. Server names, IP Address, customer billing information, etc.). An SMTP relay server is designated for this very purpose – for transmitting internal emails to your EOL or other environments. Minimally, one ought to look into enabling and certainly validating TLS is enabled and functioning between your on premises and EOL tenant. This by default is not enabled.
For businesses who wish to enable TLS (or encrypted) email for their managed email system, one would need to purchase an x509 certificate from a reputable provider, such as Go-Daddy, Network Solutions, etc. The DNS “hostname” would need to be registered with your DNS provider, and likewise would need to match the subject name on your purchased x509 certificate. There are also other various certificate requirements that must be met. One could also leverage certificate wildcards or subject alternate names (SAN) if utilizing multiple email servers. As far as the configuration of your managed email server, one would need to refer to your vendor provided the documentation of how to implement TLS.
Additionally, where appropriate, your internet facing email services (whether Lotus Notes, Exchange or an SMTP relay) ought to be made available in a secure fashion being placed in secure location, opening only those needed communication ports (e.g. inside a DMZ, in a secure location on Azure or Amazon Web Services, etc.).
On Office 365/EOL, if your business is implementing secure TLS with an external entity (e.g. partner), a bit of configuration is required. One would need to implement inbound, and likewise outbound connectors with the appropriate restrictions to negotiate (or enforce) with the remote SMTP server.
Anyway, I hope this overview helps.
Shawn May, Principal Architect