How IT Workers Can Encrypt and Secure Emails

Preserving the confidentiality of emails is one of the most complex issues IT security professionals face. This might come as a surprise, since email has been around for more than 30 years, but several false starts have prevented the widespread adoption of a standard method for securely exchanging messages.

The two security challenges that affect the exchange of confidential information over email most are: securing client/server communications and securing the transmission of messages as they travel over the Internet.

Here’s how IT workers can address both of these issues in a cost-effective and user-friendly fashion.

Securing the Email Client

The first challenge in securing emails is to protect the communication between an organization’s email server and the client software used by staff to send and receive messages. Once this channel is locked down, workers can prevent eavesdroppers using the same wireless network in a hotel or coffee shop from snooping on their emails.

There are three major email client types to consider when designing client security: web-based email access, thick-client email and email clients on mobile devices.

Organizations that host web-based email access, such as Microsoft Exchange’s Outlook Web App feature, allow users to send and receive email through their web browser. In this case, the connection between the client and server must be secured using Transport Layer Security (TLS), which is provided through the Hypertext Transfer Protocol Secure (HTTPS).

There’s a little more work to do when it comes to traditional thick-client email software, such as Microsoft Outlook, Mac OS X’s Mail and Mozilla Thunderbird, or the email clients embedded in mobile devices. These software packages must be configured to use encrypted protocols to connect to the email server.

In some cases, the server may support an HTTPS connection, similar to that used for web-based email access. Other servers, however, rely on the Internet Message Access Protocol (IMAP) and/or Post Office Protocol v3 (POP3) to receive messages and the Simple Mail Transfer Protocol (SMTP) for sending messages. Clients using a combination of IMAP, POP and/or SMTP must be configured to use TLS to secure those communications.

In all of these cases, IT workers should configure the server to support secure communication between client and server and disable all unencrypted communications. By doing so, users will adopt secure connection technologies by default, which will help companies avoid disclosing sensitive information through accidental misconfiguration.

Establishing Secure Message Transmission with S/MIME

Encrypting the client/server communication is important, but only covers one leg in the communications chain. Messages containing confidential information being sent outside your organization must use message-level encryption to prevent eavesdropping as it travels across the Internet and through the recipient’s server.

There are several approaches to encrypting messages: S/MIME, attachment encryption and secure email gateways.

The Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol uses digital certificates to provide end-to-end encryption for email messages. S/MIME has been around since 1996, but it’s failed to gain widespread adoption for a number of reasons.

First, it’s cumbersome for both users and administrators to configure S/MIME and manage the digital certificates necessary for it to work. Second, not all email clients support S/MIME, and encrypted messages sent to individuals without S/MIME-compatible clients may cause confusion. Finally, web-based email systems generally do not support S/MIME.

Establishing Secure Message Transmission with File-Level Encryption

One popular alternative that puts control firmly in the hands of users is to use file-level encryption products to secure sensitive data stored in attachments. This may involve a ZIP compression utility that offers password-protected encryption features or the native password encryption functionality found in many popular productivity applications, such as Microsoft Office and Adobe Acrobat.

There are challenges to this approach, however, since it relies on the user to recognize when encryption is required and to correctly configure encryption options. It also only protects the contents of encrypted file attachments and does not protect any confidential information that may appear in the body of the message.

Lastly, it requires the secure exchange of a password over the telephone or by other offline means. No security is added, for example, if a user sends an email with an encrypted attachment that reads, “The password for the attached file is ‘apple.’”

Establishing Secure Message Transmission with Secure Gateways

As an alternative to S/MIME, many organizations are turning to the use of secure email gateway products that provide both user-configured and administrator-configured security options. These products evaluate a message for confidential content, either identified as such by the sender or triggered by business rules.

For example, IT workers might create a business rule stating, “All messages to members of our board of directors are confidential and must be protected with encryption technology.”

The gateway can then make a secure gateway-to-gateway connection if the recipient organization has a trusted secure email gateway or, for other recipients, hold the message on the gateway for the user to retrieve via a web browser over a secure connection. Users retrieving messages are prompted to provide a password or authenticate in another fashion.

Minimizing the Burden

Mail administrators and security professionals have had email encryption technology in their toolkits for many years, but the immaturity and complexity of those solutions have prevented their adoption in the enterprise.

Modern alternatives, such as secure messaging gateways and file encryption software, offer more user-friendly approaches that protect sensitive information from eavesdroppers with minimal burden on the message sender and recipient.