2 December 2013 - by Thom Hooker
Securing your data, Part 2 - Tips & tricks from an email expert
In the first installment of this two-part blog, I wrote about how it is possible to stop sensitive data leaving your organisation. Thanks to Data Loss Prevention (DLP) technologies such as SMX's SmartRules® DLP engine, it is now possible to have a high level of comfort that your sensitive data is not leaving your site via email. How about when you want to send sensitive data over unsecured networks? Again, there are tricks and techniques you can employ to enable this.
The first thing to understand is everything you send over the network is susceptible to interception unless you take steps to secure it. This includes things like emails, web browsing, texts (SMS) and phone calls which probably encompasses all of the communication tools you use every day. Obviously the most secure step would be to not send emails, not visit any websites and don't make any phone calls or send any texts; however this isn't practical for most people. The good news is there are steps you can take to protect yourself while using these communication tools.
Securing your email
Most people don't realise that when your email client (e.g. Outlook) or smartphone connects to your company's mail server (or your ISP's mail server for that matter) to send or receive email, your credentials (i.e. your username and password) are sent across the network in plain text. That is, your username and password are not encrypted in any way and can be 'sniffed' (or read) by anyone on the same physical network as you. This stems from the fact that in the early days of networks and the Internet everything was sent in the clear (i.e. unencrypted). As more and more people started using the Internet, encryption technologies were invented to secure this data but for many years the default setting for mail clients (such as Outlook) was to disable encryption by default. This meant most people were unknowingly sending their username and password across potentially hostile networks. This includes the network at your workplace – anyone with a curious nature can download any number of network sniffing tools and with only a modicum of skill start sniffing your local network for password strings. Now you understand why security experts have been telling us for years to use different passwords for different services – if your Internet banking password is the same as your email password...
Luckily most providers, including SMX, support the use of encryption technologies to secure not only the transmission of your password but also the content of your emails and attachments. To enable encryption you need to configure your mail client (such as Outlook) to use the encryption scheme supported by your provider. There are two techniques in common use today for securing the connection to your mail server: SSL/TLS and STARTTLS. Both techniques can be used for sending (SMTP) and receiving (IMAP or POP3) email. They utilise the same underlying technology (SSL, which stands for Secure Sockets Layer; AKA TLS, which stands for Transport Layer Security – the same encryption securing your Internet banking) and encrypt the connection between your mail client and the mail server. Note that this is known as session encryption and allows you to securely send or receive plain text (i.e. unencrypted) emails. So only the connection is encrypted with this technique, not the actual email itself or any attachments. The main difference between SSL/TLS and STARTTLS is that SSL/TLS attempts to establish a secure session with your mail server at the outset of the connection (and has a dedicated TCP/IP port allocated to this secure service, so only secure sessions are seen on this port) whereas STARTTLS connects to the mail server over the standard plain text port and attempts to upgrade the session to TLS. Both methods work equally well, some admins prefer having a dedicated port for secure sessions (so you know mail is being transmitted securely), others prefer to have one port and allow people to upgrade the session to TLS depending on preference.
The benefit of turning on encryption for sending and receiving email is that your credentials are immediately secured and the transmission of emails between you and your mail server is also secured two security wins in one easy step. Another point to bear in mind is that your emails have been written in plain text, so once you've sent your emails to your mail server (MTA in tech speak, which stands for Mail Transfer Agent) over a secure channel using TLS your MTA may well send your email out via an unsecured channel. This is because the standard protocol for sending email between servers, SMTP (which stands for Simple Mail Transfer Protocol), was created in the early days of the Internet and security wasn't built into the protocol back then. As you'd expect there are steps you can take here to protect the delivery stage between MTAs.
The industry standard method for encrypting emails sent between mail servers (MTAs) is TLS. This is almost identical to the STARTTLS method outlined above for mail clients to use, whereby the sending MTA connects to the receiving MTA over an unsecured TCP/IP session and attempts to upgrade the session to be TLS secured. This method relies on both MTAs supporting TLS (obviously) and the sending MTA cannot be certain the receiving MTA supports TLS encryption until the sending MTA connects to the receiving MTA. If the session fails to be upgraded to TLS then the sending MTA will either continue sending the email in the clear (if it's configured in opportunistic TLS mode) or will stop attempting to send and return the original email to the sender (if the MTA is configured in what is known as TLS enforcement mode – the MTA must send the email over a TLS secured channel, if it can't establish a TLS-secured session it must return the email to the sender). Note that none of these methods described so far include any non-repudiation techniques to authenticate the purported sender of an email – they are merely techniques to secure the session that the email is sent over, nothing more and nothing less.
The other method that can be employed to encrypt emails (and which also handily includes non-repudiation) is end-to-end encryption, which sounds scary and complicated but isn't. It basically entails the sender encrypting an email using digital certificates (as part of a PKI – Public Key Infrastructure – strategy) on their own computer before it is sent over the wire. Once the email is encrypted it can (in theory) be transmitted over unsecured networks without risk. Thanks to the magic of PKI (which I won't detail here as it deserves its own article) only the intended recipient (and the sender of course) can decrypt the encrypted email. This means at all stages of the email's life, from the sender's "Sent" folder through transmission over the Internet and into the recipient's Inbox, the email is encrypted. Even "at rest" (i.e. on the recipient's hard drive) the email remains encrypted, so this data is extremely safe.
There are of course provisos about using end-to-end encryption tech (both parties must have exchanged public keys being the biggest hurdle to widespread adoption) but if you want to implement end-to-end encryption of your emails then tools such as PGP (commercial) or GnuPG (open source) are the applications to take a look at, both of which have plug-ins for common mail clients.
Even though email is my area of expertise, there are a couple of tools I'd like to point you at for general security on the web.
Firstly, wouldn't you like a nice simple search engine that didn't track you and returned actual search results not the results it thinks you'd like? If this is you then check out DuckDuckGo, the search engine with no tracking and no "filter bubble".
Secondly, for the paranoid among us, or if you just want to obscure your tracks on the 'net, you can't go past Tor, The Onion Router. In a nutshell, Tor works by sending your data via multiple relays so that no observer at a single point can tell where your data is going to or coming from – each relay along the path only knows which relay it received the data from and which relay it's sending it to. The Tor Browser Bundle provides a really simple way to use Tor without installing any software (it can run standalone on a USB stick).
In conclusion, even though we now know that "they" really do have the capability to spy on our emails and browsing habits there are encryption tools and technologies available that can give you back that sense of privacy.