Please login or register first to view this content.
A huge percentage of network intrusions are the result of malware, and the two primary sources of malware by a very high margin are email and the web.
This month’s email security group is, arguably, a dying breed. The idea of encrypting email to provide security is, of course, going nowhere…it is a solid concept and is here to stay. However, we see this capability morphing into functionality on more universal email gateways that cover both security and content management. In fact, in some cases, it is moving into a more universal gateway that includes web content management. We think this is, actually, a good idea in today’s internet environment.
Email is a ubiquitous – some might argue the most ubiquitous – internet functionality used by today’s individuals and businesses. Statistically, a huge percentage of network intrusions are the result of malware, and the two primary sources of malware by a very high margin are email and the web. It is difficult to separate the two, such as in phishing and spear-phishing. Managing these two primary sources of trouble makes a lot of sense.
The products that we looked at were focused on encryption. However, it is not difficult to imagine the functionality of these products moving into a more comprehensive appliance.
Functionally, these tools fit into two categories: encryption and certificate authorities. The encryption products have some challenges to overcome and they mostly address the hurdles in similar ways. First, there is the challenge of where to perform the encryption. While transport layer encryption is, arguably, more secure than application layer encryption, it also is more inconvenient to do. Transport layer encryption needs a compatible device at each end to perform encryption and un-encryption. Application layer encryption does not.
At the sending end, application encryption has a lot of possible flexibility due to its nature. For example, policy-based products easily could make determinations about which outgoing emails should and should not be encrypted. They might, for instance, have a policy that says any email containing a Social Security number will encrypt automatically – and transparently to the user – to protect the content. Without a policy being invoked, though, the email could go out as clear text. Protect that which needs to be protected and let the rest go. Just don’t make the user think about it.
When the message reaches the recipient there are some choices. One is to embed a link back to the clear text data in the message the recipient receives. He or she then clicks on the link, authenticates, and reads the message as webmail. Another choice is to attach an encrypted file to the message. The recipient clicks on the attachment, authenticates and the message opens. That can be a bit problematic on systems that don’t care much for attachments and routinely strip them off.
Selecting email encryption is really straightforward. First, decide whether application layer encryption is acceptable or if you require transport layer encryption. Next, look at recipient convenience and sender transparency. Products that require too much from users at either end will become support nightmares. Now, decide if your environment can tolerate the attachment approach or if an embedded link is your best bet. Embedded links are the primary approach taken by most organizations today.
There is a potential issue with the embedded link approach, though. Recipients are learning to avoid clicking on things in emails, so be sure that you can brand (customize) the message that comes with the email such that you can reassure the recipient that it is OK to click on the link.
Finally, make sure that your own internal users don’t have to pay attention to encryption. Why? They won’t. As the administrator, you need to do it for them. That means that your product needs a good policy engine. Making email encryption transparent at both ends is the way to secure email. If you can do that, you’ll have a solid, safe encryption scheme. And, perhaps most important, meeting regulatory requirements for privacy will get that much easier.
Mike Stephenson contributed to this Group Test.