Why E-mail Should Always be Considered Insecure

Introduction

Many people assume that e-mail messages are inherently private, and can only be seen by the recipient. This is because each e-mail account is password-protected, it seems to be accessible only from the recipient's computer or phone, and one doesn't ever see anyone else's e-mail unless looking over-the-shoulder. However, if your company's employees and contractors know anything about e-mail, it should be this:

E-mail is not a secure communications medium

and

An e-mail mailbox is not a secure storage system

Read on to find out why, what it means to you, and what to do about it.

Factors Contributing to Vulnerability

Here are the reasons e-mail is insecure:

• E-mail is susceptible to eavesdropping in transit. Transmissions are not necessarily encrypted. So even if every e-mail server that handles the transfer of your e-mail is trustworthy, anyone who controls or can access network equipment between the servers (legitimately or not) may be able to intercept and read your e-mail.
• Even when encrypted transmissions (TLS or SSL) are used, the encryption is not end-to-end. At best, it's only encrypted during transmission between each e-mail server it visits in the path it takes from your device to your recipient. This would foil someone monitoring communications equipment between e-mail servers, but the e-mail will reside unencrypted on each server it visits on its way to the recipient, at least temporarily, and will be subject to copying to permanent storage by anyone with sufficient access to that server.
• E-mail servers do not necessarily confirm the identity of the e-mail servers to which they connect to deliver messages. This means if a pirate successfully uses one of many techniques to impersonate an e-mail server to intercept inbound messages, the senders' servers won't know, and messages intended for those recipients will go to the pirate. E-mail works this way because a significant number of servers on the Internet are not capable of proving their identity. So if, for safety's sake, you configured your mail system to refuse to send a message if it cannot verify the identity of the recipient's server, your users would find that many messages would not be delivered.
• E-mail messages remain vulnerable to exposure long after delivery. A user's mailbox is a database that often grows very large, and it is typically saved for months or years and duplicated across mobile devices, computers, laptops, servers, network storage devices, and backup media. While these systems will generally be configured not to allow anyone to easily access them, the fact that copies of these messages are spread around so widely gives them what's called a broad attack surface. If any one of these devices is compromised, including by an insider who misuses his access, then your messages can be read. In addition, many messages you send or receive are most likely copied in transit and saved in the message logs of e-mail security and archiving systems run by your e-mail provider and/or your recipients', meaning a significant number of your messages are saved in countless databases over which you have no control, accessible by a significant number of people.
• Accidental exposure of information in e-mail by user action is more likely than with other forms of information users handle, such as shared documents. While an employee of a company can certainly accidentally expose a spreadsheet or document from a shared folder, the mechanism to do so requires more deliberate action, and has more technical controls and opportunities in place for the user to recognize a mistake, than with information in an e-mail. This is because:
• E-mail messages can't be classified, restricted, assigned permissions, or otherwise protected by an administrator a group file manager.
• Long e-mail conversations typically include all messages sent from the beginning of the conversation in each transmission, and, especially if the topic changes within the same thread, a user on the thread may forward it to a new recipient intending to share the most recent message or something recently attached, thereby unintentionally exposing something typed earlier in the thread that shouldn't have been forwarded.
• Because e-mail software is designed to facilitate communications, the name of virtually anyone a user has ever communicated with will pop up when addressing an e-mail, and it is not infrequent for a user to pick the wrong name due to inattention, causing new messages, forwards, and attachments to be more likely sent to someone who should not see it, as opposed to a file-sharing system that will have restrictions on who files can be shared with.

Potential Effects

Let's consider the possible fallout of failing to recognize the insecure nature of e-mail.

First, the most obvious problem with sending or receiving sensitive information via e-mail is the potential of damage to reputation, financial loss, and possibly even civil or criminal penalties if information is exposed, depending on the nature of that information.

If you pay attention to the news at all, you have heard of the many instances in which large and small companies, government officials, and other public figures have had their e-mails stolen and published, to great embarrassment and financial loss because of the information contained in them.

Next, consider that many web-based applications and cloud services allow users to reset passwords or otherwise verify their identity only by confirming they have received an e-mail sent by the system, making these logins no more secure than their e-mail. More advanced services offer options to require additional verification, but in the modern cloud era, where service providers aim to support millions of users, we can't expect the ease of employing e-mail for self-service password resets to go away soon, and your users may be inclined to skip using additional verification anyway, when possible, for their own convenience.

Intercepting e-mails or even taking control of an entire e-mail account to steal passwords is therefore a dangerous threat. To defend against this, for all web-based or cloud applications used by your employees, you must either disable the ability for passwords to be reset by e-mail alone, or require additional security, such as secret questions and/or two-factor authentication. If none of this is possible for a given online service, you should develop mitigation plans, such as restrictions on placing sensitive information within that service, or finding a more secure web application to perform the same function.

End-to-end encryption

Technological solutions exist for end-to-end encryption, meaning an e-mail, including attachments, is scrambled into utter jibberish before it leaves the sender's device, and will be delivered and stored in its encrypted form in the recipient's inbox. When properly implemented, the key for unencrypting the message will only reside on the recipient's device (and not even the server where the recipient's inbox is stored). This removes the possibility of anyone eavesdropping or intercepting your messages and being able to read them, including the administrator of the recipient's mail system.

However, this has always been difficult to implement, as it requires coordination between the sender and recipient to exchange encryption keys in a secure manner, in advance. So there is no easy way to set yourself up so every e-mail you send or receive will be encrypted. With sufficient investment, this can be accomplished for e-mails sent within a domain (that is, company internal messages), but certainly not for messages in or out of the company, which make up the majority of messages for the typical user. And it couldn't apply to automated inbound messages, such as an e-mailed password reset link from a cloud service.

Third-party services exist that claim to offer end-to-end encryption with little setup required. However, some such systems nominally encrypt e-mails, but do not provide much greater security than unencrypted e-mail. Specifically, these are systems where the sender posts a message to the third-party encryption service via a web browser, which then sends the recipient a regular e-mail with instructions on how to log in to the website to view the secured message. When the recipient logs in to the website, the message is unencrypted as it is accessed for display in the recipient's browser. The problem is, if the recipient's inbox or e-mails in transit are exposed or copied to an archive system, someone besides the intended recipient could easily see the notification e-mail and use the link and instructions there to log in to the website and view the secured message.

In addition, since the secured message itself remains within the service and the service manages the encryption key, an engineer with access to their servers may be able to decrypt and read the message. A larger provider will have internal controls and auditing to prevent or detect this, but this only means that you may get a notification of a privacy breach if someone reads your messages, which is never going to happen if you control your encryption keys on your own device.

Solutions

The most robust solution to these threats and vulnerabilities is to have a well-developed Information Security program, with emphasis on user training and awareness, and policies designed to mitigate the vulnerabilities with both operational procedures and implementation of technological protections.

Apart from that, here are some basic practices to help defend against some common vulnerabilities, some of which were referenced already above:

• Send sensitive information out-of-band. That is, if you need to provide a user name and password to someone, go ahead and send the link to the website and the user name via e-mail, but then send the password via text message, or call the recipient and give it to him over the phone.
• In all cases, and especially if creating an account for a user in one of the many systems that always sends the password via e-mail to the user, contact the user promptly by phone and ensure he received the e-mail, logs in promptly, and changes the password to his account.
• Set a policy that prohibits sending sensitive information by e-mail. What constitutes sensitive information, how to transmit it apart from e-mail, and how to monitor and control the prohibition will be determined during development of your Information Security program.
• Implement two-factor authentication where possible so that no sensitive transactions can be completed only by a user verifying that they can access a given e-mail address.

Epilogue

To get started implementing an Information Security program, or reviewing existing policies and procedures, visit J.D. Fox Exec for professional business management services.