Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
    
Or maybe it's you who won't get why they cling on to their email. Before you talk them out of using their daily use tool that just happens to work for them, have you sat down with them to ensure you can provide equally good an alternative? And mind you, there's a step from "convenient" to "usable" and then another all the way to "enjoyable" ;) Also, rather than insist that you're right and they're wrong, do you have an informed strategy to bring about change? There might be plenty of better ones than showing people wrong. ;) –  Steve DL Oct 5 at 23:49
    
We had an organisational psychologist telling us about how to implement change strategies in corporations, recommending mindtools.com/pages/article/newPPM_82.htm as a starting point. Just keep in mind that you're taking something important away from them for very relative and hard to understand benefits. You must have a strategy to make your alternative seem profitable and to make it fit in practice. –  Steve DL Oct 5 at 23:53

4 Answers 4

up vote 3 down vote accepted

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.

share|improve this answer

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).

share|improve this answer
1  
I think you meant "never send sensitive information in clear text". –  Ed Brannin Oct 5 at 20:27

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.

share|improve this answer
    
"Nobody will know the difference" is a bit of a misnomer. While the difference might not be obvious, if there are signs to make someone suspicious of the origin of the email, the trace headers (especially when compared to other emails from the same alleged sender) will provide fairly conclusive evidence to at least whether the same ISP was used to send both emails. (Now, a lot of the time these days, that ISP is actually Gmail, which by itself doesn't tell you much of anything...) –  Michael Kjörling Dec 15 at 15:30

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.

share|improve this answer
1  
I'd like to mention the integrity issue, emails can be made to look like they came from virtually anywhere. –  Adnan Feb 1 '13 at 16:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.