Policy Based Email Encryption Best Practices
Email encryption is the process of converting plain text (the original message and attachments) to cipher text, and serves two functions: (1) maintain confidentiality (2) establish non-reputability – that is, the sender cannot disclaim the contents of the message. Policy-based encryption is about 
enforcing encryption according to a policy defined by the organization, automatically encrypting and decrypting email based on specific considerations. When considering policy-based email encryption, there are best practices that an organization can follow for policy-based email encryption, and I’ve outlined a few in this column, specifically around Transport Layer Security, S/MIME Gateway Encryption, End-to-end Encryption and No-Client-Side-Software-Required solutions. The column highlights some of the more common technologies and how they address different use cases.
The first step in deploying policy-based encryption is to define the requirements of the policy, because the requirements will drive the specific technologies deployed.
Companies should answer the following questions before choosing an encryption technology:
• Must a receiver be able to prove that a certain end-user sent a message?
• Must I secure the contents from the moment it is sent by a user all the way to the recipient?
• Must I only secure the contents while it is in transit to its destination?
• Must I secure the email’s headers as well as the contents of the message?
• Must I establish the identity of the remote server that I am talking to?
• Are the recipients on public servers and therefore the message must be received and stored as cipher text?
• When receiving encrypted email, do I decrypt it or delivery the cipher text to the end user?
• Must I scan inbound encrypted messages for viruses?
• Do I need to archive plain text?
• Do I need to recover plain text if the recipient leaves the organization?
Transport Layer Security (TLS)
TLS is an Internet standard extension to SMTP. It is universally supported in mail transfer agents (MTAs). With TLS, an SSL encrypted tunnel is negotiated between the SMTP client and the SMTP server similar to SSL between a web browser and web server. It requires at least one side of the connection have an X.509 certificate. Both the SMTP client and the SMTP server may enforce some policy associated with TLS, for example, cipher strength, and whether the certificate presented verifies. Because the certificate can be verified, TLS can be used as an authentication method as well as an encryption method. TLS is simple to implement, all you need is a certificate. The drawback is that it only secures the email from eavesdropping during transmission across the network. Furthermore, there is no way to make sure that TLS is used during every hop the email makes as it is routed from server to server until delivery to the recipient’s mailbox.
S/MIME Gateway Encryption
S/MIME Gateway (SMG) encryption is not an Internet standard, but many email products support it and interoperate. The purpose of SMG is to allow two organizations to establish encrypted links with each other by exchanging organizational keys (certificates) and having the email servers automatically encrypt and decrypt messages between the organizations. The advantage of S/MIME Gateway over TLS is that regardless of any intermediate SMTP hop, such as an anti-spam cloud filtering service, the email is secured, because it is converted to an S/MIME cipher text email message. The disadvantage of S/MIME gateway is that unlike TLS, the email headers and subject are not encrypted and may be read by an intermediary and it cannot used to authenticate a connection. Therefore in some use cases both TLS and S/MIME Gateway might need to be used.
Deployment of S/MIME Gateway requires a key exchange between the two parties establishing the encrypted link. This adds an administrative overhead. Notice that because the encryption is server-to-server and not end-user-to-end-user, S/MIME Gateway encryption does not provide non-reputability, nor is the email ultimately delivered into the recipient’s mailbox as cipher text. It is used mainly for business-to-business communication.
End-to-end Encryption
End-to-end encryption is the most secure means of encryption and can provide non-reputability. Most modern email clients have the Internet standard S/MIME encryption built in. Other end-to-end encryption solutions require a plug-in or other software to use. The technologies do not necessarily interoperate – i.e., S/MIME and PGP are not compatible.
These schemes require a key exchange between end users in order to use them. Once the key exchange has been done, the users may be able to exchange email that cannot be read or modified. These encryption schemes are very complex to deploy and manage for an entire organization. They require deploying desktop software (special desktop solutions are required to enforce encryption policy on the desktop), creating and maintaining a public key infrastructure for sharing keys, and they also introduce problems in email management such as archiving email messages in plain text and virus scanning email. Because key exchanges are required, end-to-end encryption is not useful for securing ad hoc email communications in a business-to-consumer environment.
No-client-side-software-required
Solutions Numerous companies have offered encryption solutions for simplifying the business-to-consumer challenge. The sender does not have to have a public key in order to encrypt email to a recipient, nor does a recipient need any special software in order to open and read an encrypted email. These schemes usually work through a web-based process obviating the need for any client-side software. Policy is enforced in the mail server. They can be deployed as either an on-premises or cloud-based solution and are an excellent compromise between security and usability. They generally meet regulatory standards for protecting privacy, such as HIPAA and FERPA.
In the end, companies that take into consideration their defined requirements combined with these best practices for policy based email encryption will be able to best determine which types of email encryption need to be deployed. For example, the table below summarizes how each technology fits the use case requirements:
