Good, simple list of reasons that email is inherently insecure

Question

I've been searching for a while, trying to find a good get of information about the inherent risks of transmitting sensitive data via email. I'm really looking for a comprehensive list of all the vulnerabilities from an outside source that we can use as part of our "IT Security 101 for non-IT business leaders" training initiative. (I did search both here and on Google first. On Google, I keep getting lengthy articles, and I found good bits and pieces here as well as in my Google searches, but not a full list like I'm looking for.)

The background is that I have various people in the business side that just don't get it. They insist on using email and refuse to accept the fact that it's just not secure.

In my current dilemma, we're implementing SSRS for reporting, and we are expecting people to view the reports on the SSRS site. The reason is that most of the reports we deal with contain sensitive data of one form or another, and we just don't want these reports sent via email. State regulations where we operate identify PID as a last name, first initial or name, and any other form of identifying information, such as an address, SSN, account #, email, etc. The state laws also stipulate that a breach leaking 500 or more records containing such PID has to be reported to the state.

Many of the reports do contain PID by this definition, and most have well over 500 records. So IMO a single report picked up by a sniffer, or accidentally sent to the wrong person is a reportable breach - not something we want to deal with.

However, we have certain upper level management that seems to think that the rules don't apply to them, mostly because they don't understand how real the risk is. The good news is that we're making headway in changing their minds. The bad news is that their eyes glaze over when we get too technical. Also, they don't want to just take our word for it.

Examples I can think of:

• Sniffers can be used to read emails as they are moving across the network.
• Email gets sent through many servers between the sender and the recipient. Any one of those servers could be intercepting and saving that email.

I'm not too concerned about the list being too technical - We can us analogies that the business will understand to explain the technical concepts. I'm more interested in a list that's got all the risks.

Answer 1

If you want an analogy, read this.

As for the list of vulnerabilities:

• Emails can be sniffed in transit, since they are not encrypted (some sites will opportunistically employ encryption for transit, but this is not reliably activated).
• Emails will be stored on physical disks in the servers which are involved in the operation: the sender's email server, the recipient's email server, and any server "in between". Physical disks can be sniffed when decommissioned or through backup tapes. Bored interns in the facilities managing these servers could simply have a look.
• It is easy to make emails go to the wrong machine by altering the DNS.
• There are viruses which routinely inspect emails received by infected machines, in search for passwords, credit card data or other juicy information.

The whole email system just assumes that everybody is honest and nice and trustworthy. It is surprising (but morally encouraging) that it works at all.

Answer 2

The simple and deepest answer is that SMTP (Simple Mail Tranfer Protocol), which handles the sending of mail from client to mail server and between mail servers (other protocols such as POP3 and IMAP are typically used to retrieve mail nowadays), was originally designed for use in the ARPANET, which operated in a time when anyone who could use it had a security clearance in the first place. As such, SMTP fails at all of the four key aspects of information security, because when it was designed whose concerns were handled by alternate means, and the protocol has never been updated to attempt to do so.

• Confidentiality: SMTP e-mails, by default, are not encrypted during transport or at any other time. Anyone can read them while they are being transmitted along an unencrypted channel, or while they are stored on either party's mail servers awaiting retrieval.
• Integrity: SMTP provides no more error checking than the transport layer protocol used to send it. That is woefully inadequate when you want to ensure that nobody has tampered with the message; TCP is designed to help ensure that the network itself didn't cause data corruption or loss; it's trivial to change the contents of TCP packets enroute if you have control of one of the network nodes along which they're sent.
• Authenticity: SMTP has no means to verify that the listed sender is actually the person who sent it. Someone halfway across the world can create an e-mail with your address in the "From" field and nobody will know the difference.
• Non-Repudiation: Because you can't verify that the person listed as the sender actually sent it, or that the e-mail itself is the original content sent by that sender, that person can very cogently deny that what you received is what they sent, or that they ever sent you an e-mail in the first place.

The addition of the SSL/TLS security handshake into SMTP, creating SMTPS, provides confidentiality on the first leg of the trip (from your computer to your "home" e-mail server). That's all; you can't enforce confidentiality along any other leg of the trip, and the other three aspects of InfoSec are unaffected.

Answer 3

One of the main reasons I don't like using e-mail for transporting any sensitive information is simply because once the e-mail with sensitive information has left your organization, you've instantly lost any control you may have had over it.

For example

• User has sensitive e-mails in their inbox, just sitting there. If account is compromised you now have free reign over any e-mail with all sorts of sensitive information
• You no longer have any knowledge whether or not that receiving user will forward the e-mail to parties that should not receive that information
• You now have two potential points for compromise - servers that have sent the e-mails and servers that have received the e-mails. You place a lot of trust in the admins of those servers and you just hope they aren't snoopy and look at information they shouldn't be seeing
• You have no governance over retention rules or archiving practices on the receiving side. Documents that should have limited lifespans can potentially live forever on a server with no archiving or deletion practices

I would almost always recommend an alternative solution to sending sensitive information via e-mail for the reasons I've listed above.

Answer 4

What insecure could mean?

• Confidentiality -> Yes, mail is insecure, but you could use an encryption layer (like PGP) when needed.
• Efficiently -> No: mail is one of the simplest and safest way to transmit information to specific persons.

Don't forget that security have many vectors. The perennity and efficiency are important security vectors too.

Analogy

Mail system network work likely in the same way than real post:

• once could write anything in a paper letter
• add toxical material to paper
• faking sender address
• faking enveloppe sender address
• encapsulating in another enveloppe to send through another citie's post office.

All this is very unsecure, but anyway, everybody continue to exchange by real post.

When people harm agaisnt post security, it's more about the fact a letter may be loose than other...

The main difference is the cost of sending one mail. This implie more junk but nothing else.

So my point of vue is to say smtp is a well worked protocol, very sercurised about what's original goal.

About confidentiality

Like sending sensitive informations through real post. Having to do such kind of things implie subsequent securisation efforts.

So simply: Never send sensitive information in clear text.

Use another way to exchange keys and valid fingerprints, in order of preference: meetings, phone, fax, sms (with care).