Email Security

As email continues to grow as a platform for business communication, the need for concomitant security is growing just as fast. While the bulk of email contains information that is not necessarily of competitive importance, keeping prying eyes away from critical messages is as important as keeping your competitors out of your filing cabinets.

  • E-Mail
By  Jon Tullett Published  July 5, 2001

Introduction|~||~||~|As email continues to grow as a platform for business communication, the need for concomitant security is growing just as fast. While the bulk of email contains information that is not necessarily of competitive importance, keeping prying eyes away from critical messages is as important as keeping your competitors out of your filing cabinets.

Privacy and secrecy are not the only factors to consider. Litigation is moving to accept electronic evidence and email, which increases the need to archive messages for long periods. A key component of email security is the long-term protection, keeping messages safe from damage during disaster recovery, and from tampering.

This applies internally as much as externally. Managers may need to keep certain information secure from employees, and it is well known that the majority of information theft (including gathering email content) is conducted by insiders. Although the circumstances may vary, internal email needs to be as secure as external messages.

But all the technology in the world won't help you without a carefully planned approach, says NCR consultant Mahmoud El Ali. "Some things you can solve by technical implementations, and some times you have to have a policy document. You can't solve every problem by implementing something [technical]. In fact before talking about PKI or any other solution, [an early] step should be development of a security policy document. Without developing the security document, anything you do will not be [effective].

"You have to build the base first, and then implement [technology that] can comply with the policy." El Ali counsels performing careful security audits and assessments before considering any deployment.

Although security experts complain of low awareness, and indeed Butler recently released research figures showing that less than 1% of US corporate email is secured, local awareness is growing, says El Ali, possibly even faster than elsewhere in the world. In the last couple of years there has been a lot of investment in infrastructure, "and now they want to use this infrastructure in a secure way. And they understand more now - when they talk security they aren't thinking just a couple of firewalls. They know that security is a practice."

El Ali expects to see at least tens of PKI projects completed in the UAE alone in the next few months, with secure messaging driving much of that. "This is the first advantage of going to PKI solutions - to secure your email connectivity. This is the first priority for going to PKI solutions."

So let's take it as read that we want to get a message from one place to another, as securely as possible. We also need to do it with a minimum of additional complexity. That condition is an important one. In hypothetical scenarios, security is relatively easy.

I can use a PC that is not connected to a network to generate a message protected by 1,000,000-bit public key encryption, copy that message onto disks, and then move it onto a network and send it to a recipient, who in turn copies it offline for viewing. Unless you are peering over my shoulder while I write it, that message is as secure ||**||Routing and identity|~||~||~|
So, keeping the basic structure of the mail system intact, lets look at the path of an email and what it is exposed to along the way. There are several steps involved, and each has its unique challenges.

Let's also talk about the concept of a message, and in particular about identity and digital signatures. In a world where business agreements are forged by email, it's essential to be sure that you can reliably ascertain the identity of a message's sender.

There have already been a number of high-profile cases in the US where insider-trading accusations and share manipulation have been accomplished by spoofed messages on public forums. In reverse, the same applies - you should ensure that anyone to whom you send a message knows that you are the real sender. Doing so establishes a level of trust, and any unsigned message from you is more likely to be discarded as false.

Digital signatures are the way to go here, and are easy to implement, either as part of a fully-fledged public key infrastructure (PKI), or on a case-by-case basis. We'll discuss PKI more later. Individual certificates come in two flavours: verified and unverified. A verified certificate means that a trusted third party (such as the UAE's Comtrust) has ensured that the certificate holder really is who they claim to be.

This doesn't mean an unverified certificate is necessarily less secure - in an intranet environment you can easily set up a certificate server and authorise all certificates yourself with no less certainty than a third party could. Either way, both provide a certificate which can be attached to an email, thereby positively identifying the sender.

This adds very little to the complexity of the mail, since the actual text is not altered. A recipient with a mail client unable to handle digital content will not be able to read the certificate, but will be able to read the content. Interoperability is maintained.

An extension of this idea is hashing, which provides a way to ensure that a message has not been tampered with en route. We'll get into more detail about hashing later.

Meanwhile, let's look at a buzzword that's taken the security world by storm - PKI. Also called a "trust hierarchy", PKI is chiefly targeted at authentication tasks, especially for e-commerce transactions, but is also well suited - within limits - to email security. Using a Public Key Infrastructure, the organization implements a certificate authority (CA) service which is responsible for issuing, maintaining and revoking certificates on behalf of its users. As a user, you can assume that if the CA says a certificate is OK, you can trust it. In turn, your CA can communicate with external agencies to inherit information about their certificate users.

Because the trust is hierarchical, users at each end of the different CAs can thus trust any communication based on their respective certificates. Typical tasks here include authentication using certificates to prove identity during transactions, and encryption where the certificates' public/private key pairs are used to encrypt data between two parties.

Applying this to email is simple enough - a certificate can be used to digitally sign or encrypt a message. A mail server integrated with the PKI solution can do this on behalf of the user, reducing the possibility of human-error. All outgoing messages will be signed, and those with recipients whose public keys the server holds can be encrypted according to policies. Incoming messages can be decrypted by the server, since it holds the users' certificates, and attached certificates can be added to the database if they are trusted.

Because the server is encrypting the message as it leaves, this overcomes one of the niggles of client-side encryption too: when sending a message to multiple recipients, it must be handled differently, since each recipient's message must be coded with a different key. Having the server manage this task takes the complication away from the user.

Using PKI has its limitations, however. You can only exchange encrypted messages with people who are either within the PKI, or whose public keys you have obtained. Given the tiny adoption of PKI to date, most messages will fall outside this scope. Further steps need to be taken to protect the message.

Furthermore, server-based PKI will encrypt messages according to rules, but the delivery of the message to the end user may be unsafe depending on the implementation, since many existing standards use plaintext transmission.
||**||In transit|~||~||~|
First of all, lets look at the message in transit. Email messages are conveyed across the network using a variety of protocols including SMTP (Simple Mail Transfer Protocol) for communication between sender and server, and POP3 (Post Office Protocol version 3) between server and recipient. These two are the most common, but there are others, such as IMAP (Internet Message Access Protocol). In most cases, these protocols are quite old, dating back to a time when message security was not an issue. The email contents in each case are sent "in clear" - openly readable to anyone who cares to intercept the data stream.

On most corporate networks, any user with a technical bent can put his NIC in promiscuous mode and capture incoming and outgoing emails of every user on his segment.

To protect the mail in transit, secure versions of these protocols have been developed, but largely ignored. POP3 can easily be secured by SSH (Secure Shell), for example, or the message body by S/MIME. A secure version of the sending protocol, SMTPS, is also available. In most cases, deploying these has no impact on the user at all. Changing the protocol and configuring the mail client to use them requires a little backend work, but the fact is that very few companies ever bother.

Because POP3 is so pervasive, and assumed to be the de facto protocol that users will use, even ISPs rarely even offer secure mailbox access, let alone encourage or demand its use.

If the LAN segment of your email systems is not trusted - which amounts to saying "if you don't trust every employee to read every email - then you should consider deploying a secure transport mechanism for carrying unencrypted mail traffic.

Unfortunately, there is little you can do to ensure security between your mail server and a remote system. If the far side does not support an encrypted form of communication, the server-to-server component is likely to be vulnerable from the point your network touches the outside world. Economies of scale work in your favour here, though - the volume of email in transit between ISPs make it impractical for an attacker to single out your messages for attack, although it's a possibility you should consider. Encrypting the message body is the only real way to maintain security.

If encryption isn't possible, then you can at least make sure that the message makes it from sender to recipient unaltered, by a process called hashing. While the contents will still be easily read by anyone with access to the mail (such as a server administrator on a transit server, or a cracker conducting a man-in-the-middle attack), they will be unable to tamper with the message body without the recipient being alerted to that fact.

Hashing involves generating a unique code from the body of the message. A similar process is used to store passwords by operating systems. Although much smaller than the body text, the hash is very unlikely to be duplicated by another message, and even tiny changes to the body will result in substantial differences in the hashes.

Hashes are added in the same way (and usually at the same time) as a digital signature. The most common algorithm used is the US government-approved SHA1, but there are others, such as MD5, which is often used to check the contents of downloaded files.

So while it may not always be practical to fully encrypt your email, it is relatively straightforward to provide a guarantee of the sender's identity, and the integrity of the contents, both of which are important steps in conducting business electronically.

Aside from the actual transmission of the message, email security also extends to the message store, both locally and centrally. On the server, there is a twofold requirement - to protect the messages from intrusion, and to maintain the integrity of the message store. Across the globe there is a move to legally require messages to be archived for several years. Medium- and long-term archival needs to be factored in to the email equation. Backup is not too difficult, but needs to be protected no less carefully than the online store. If the archived data can be retrieved by an attacker, you may as well give them access to the production server too. There is also the behavioural angle - users cannot be relied upon to take appropriate steps to archive their mail, and usually delete messages from their account when retrieving them for viewing.

Assuming this will happen, the backend needs to be architected to ensure that users' are not restricted, but the original email is duplicated for archival regardless of what the user may do to it.

Locally, the message store is often the first target for an attacker. How many of your users run Microsoft Outlook, with no password on the personal folder (.pst) file? Unless they regularly clean up their folders, that will present an intruder with a solid chunk of valuable data. Attacking the message store is far easier than attacking the server.

In most cases, attacking the local message store simply means attacking the PC, so email security starts to overlap with basic desktop security. If I can install a Trojan such as Back Orifice or SubSeven on your PC, I have access to your email, and all your security mechanisms are for naught. Securing the desktops is a crucial component of secure communications, and often among the most difficult to achieve since it is so dependent on the activities of the user.
||**||Watch the content|~||~||~|
Lastly, email security also needs to extend to the content of the messages.

This covers a number of bases. Firstly, the obvious malicious message payloads - viruses and Trojans.

Protection against all such email-transmitted agents should be the responsibility of the mail service, not the user.

The mail server should be checking for dangerous content and taking action, and while the users should understand the dangers and be aware of the possibilities, a virus they are not exposed to is one they can't possibly execute.

Second, valuable data needs to be protected. Users may make a mistake and send sensitive corporate information in unencrypted form despite a company policy to the contrary. Mail scanners that are designed to detect and prevent such messages are viewed by many users as an invasion of privacy, but can avoid nasty situations later.

When considering email security, it's important to keep the big picture in mind. Unless you have identified a particular vulnerability in need of attention, there is little sense securing one component and leaving another unprotected. Track the path of a message throughout your organisation, and consider the full course of its life, and make sure you have the policies and technology to protect it at your acceptable comfort level for every stage of its existence.

Messaging security is not an easy task to confront, but with careful planning it can be done. If your organisation conducts any business by email at all, this is a field needing particular attention.

||**||Do you need encryption?|~||~||~|
There are certain costs involved in implementing and using encryption - in terms of development time, the degree to which data throughput is affected, increased complexity for users, and so on. Therefore, the decision of whether or not to use encryption isn't necessarily a "no-brainer."

Here are some pertinent questions you may wish to use as starting points in evaluating whether to use encryption:


  • Is this data really worth encrypting?

  • How many people need to have access to this information?

  • How quickly will the information become outdated (and therefore less sensitive)?

  • What do you consider an acceptable level of risk (of information compromise)?

  • If the data needs to be exchanged across a network, how secure is the network itself?

  • What are the possible repercussions of your secured data falling into the wrong hands (what's the worst that could happen)?

  • How valuable (in terms of time, money, or other values) is this information to you

  • How valuable could this information be to someone else?

  • What costs are involved, both in implementing and in using the desired encryption technology?

These are your considerations for the present. As software development tools progress, encryption objects will make built-in support for encryption become almost trivial. End users will find encryption becoming easier to use and more integrated into their software.

Remaining issues regarding encryption costs will probably centre more around the degree to which encryption impairs data throughput over networks. With current technology, the degree to which throughput is affected varies from little or negligible impact to extremely significant (factors of a thousand or more times slower than without in some cases!), with the primary determinant being the complexity (and presumably the effectiveness) of the algorithm being used.

It will be interesting to see whether using faster computers solves this problem or just elevates it to another level. (I would bet on the latter, since faster computers means faster ways to attack the algorithms as well.).
||**||Encryption methods|~||~||~|
In recent years, many advances have been made in cryptographic technology and various approaches have been taken. The different approaches achieve varying levels of strength against cracking.

Public-key encryption

Public-key encryption involves each party having two keys: one that is kept private to everyone but the owner and another that can be made public. Messages are then encrypted using the private key of the sender plus the public key of the intended recipient. On the other end, the data can only be successfully decrypted using the opposite pair of the sender's public key combined with the recipient's private key.

This type of encryption achieves its high level of security at the expense of speed. It takes several orders of magnitude longer to encrypt and decrypt using public-key technology than using certain other forms of encryption algorithms.

Symmetric-key encryption

Symmetric-key encryption requires using the same key for both encrypting and decrypting.

Obviously, this works only if the key used remains undisclosed to anyone but the sender and recipient.

This technique, while not as secure as public-key encryption, is significantly faster in operation - as much as a thousand or more times faster - than using the public-key technology. A disadvantage of the symmetric-key approach is that it requires that the key also be conveyed somehow from sender to recipient.

Combining public- and symmetric-key encryption

Because public-key algorithms provide extreme security (plus signatures) at the expense of speed, and symmetric algorithms provide speed at the expense of somewhat weaker security, another common approach is to use a combination of both techniques.

A symmetric encryption algorithm is used to encrypt the main body of plain text (or data), and then the symmetric key is encrypted using the stronger but slower public-key encryption. This public-key encrypted symmetric key can then be safely included along with the body of encrypted text (ciphertext), and allows the symmetric key to be retrieved by the recipient (or recipients) whose public keys were used to encrypt the sender's symmetric key. This combines the benefits of faster encryption for the bulk of the information, with stronger encryption to safeguard the enclosed symmetric key, and also provides the benefit of a digital signature.
||**||

Add a Comment

Your display name This field is mandatory

Your e-mail address This field is mandatory (Your e-mail address won't be published)

Security code