Support for internal and/or external users

As discussed in the second article in this series, the most important decisions to be made when planning an email encryption software product are whether encryption is needed for individual internal senders or not (as opposed to doing all encryption behind the scenes based on policy) and whether encryption is needed for external recipients or not.

Based on which direction the organization decides to go, it’s then critically important to ensure the email encryption software evaluated supports those decisions. So, for example, if the organization wants individual senders to be able to encrypt emails, it should only evaluate potential products that provide an encryption interface for end users. Similarly, if the organization wants external recipients to be supported, then only potential products that provide Web-based interfaces for external recipients should be considered.

Usability is also something that can’t be overlooked. Many email encryption products in the past have failed, not because they didn’t work, but because users found them too challenging or cumbersome. For instance, when earlier generations of email encryption products required users to trade keys before sending encrypted emails, users often sent the wrong keys (private keys instead of public keys), thus compromising their encryption. If email encryption is made optional and it’s inconvenient, users won’t use it; they’ll either send emails without encryption or they’ll use alternate email systems, file-sharing websites, or other means to exchange information with each other without using encryption.

Integration with existing email infrastructure

The ease of integration with the existing email infrastructure is an obvious, yet important, factor to consider when purchasing and deploying and email encryption.

On the mail server/gateway side of the equation, some email encryption software products only work with one or more particular email server brands. A similar problem exists on the client-side (assuming an organization wants individual clients to be able to encrypt emails). Some email encryption products are only compatible with one or a few client email flavors, such as Microsoft Outlook or Novell GroupWise. In addition, to make encryption available on the client-side, users may need to install an add-on for their email client or possibly a separate piece of software.

Consequently, it’s important to be aware of which email servers and email clients users run, and to make sure that either all the servers and clients are supported by the encryption product or that the organization can migrate all users from unsupported servers and clients to supported servers and clients, which is not something to be taken lightly in terms of effort and disruption.

Strength of cryptography

The details of cryptography are often hidden under the covers of email encryption products, but it’s important to get access to at least the major cryptography attributes: algorithms, key size, and certification statuses. Ideally, the product chosen should support the Advanced Encryption Standard (AES) algorithm with minimum 128-bit keys (preferably 256-bit keys) and be FIPS compliant. FIPS compliance is a certification that demonstrates that a cryptographic implementation has passed basic testing (not that the implementation is bug-free).

Another important cryptographic consideration is key management. Many email encryption implementations issue a new key for every email message. Others may issue a key pair per email address. In this case, it is important that the email encryption product provide the full cryptographic key management lifecycle, including regular key rotation.

File security

Email encryption software isn’t just about protecting email message bodies but also email file attachments. By default, attachments are encrypted as part of any email encryption product worth its salt. However, there are two special considerations involving attachments that merit investigation when evaluating products.

The first is the ability to transfer large files via email encryption software. Many email systems limit maximum email or attachment sizes, often at 10 or 20 megabytes. These limits are often inconvenient.

But because the encryption product is actually sending a link to the file, and not the file itself, the file is unaffected by the email system’s file attachment size limit. Some email encryption products support file sizes in gigabytes. This may provide a more usable product than other secure file transfer methods.

The second is the ability to have the encryption “stick” with a file even after the attachment has been separated from the email message. This typically involves the installation of an email client add-on or separate software tool that handles the encryption and decryption. Note that if files are leaving an organization’s boundaries, some sort of user or client provisioning for the external users will probably be necessary to allow them to decrypt the files.

Mobile workforces

With workforces increasingly going mobile, it’s more important than ever for an  email security product to support smartphones and tablets and telecommuters, including all flavors of the bring your own device (BYOD) phenomena. Generally, this is only a necessary consideration if an organization is allowing individual users to encrypt emails. Make sure all email encryption products evaluated provide support for the mobile devices and apps that will need to send and receive encrypted email within the organization.

Policy- and identity- based encryption

Most email encryption products tout that they use policy-based encryption or identity-based encryption.

Policy-based encryption refers to encrypting email messages and attachments based on a set of policies — for example, automatically encrypting all email messages sent by members of the human resources department or all email messages that appear to contain credit card numbers. Identity-based encryption (IBE) is when public/private key pairs are created based on a characteristic of a user, such as a user’s email address.

IBE allows encrypted messages to be sent to recipients without any previous key exchange. But to decrypt messages, each recipient must contact the sender’s infrastructure to get the private key. With email encryption products, this is typically done through a Web interface.

Policy-based encryption and IBE are not mutually exclusive, and it’s certainly possible for a product to use both of these forms of encryption, so they should not be thought of as either/or. Most vendors seem to state that they perform one or the other, but in reality, most email encryption vendors perform both types of encryption.

In terms of criteria, it is important to know if policy-based encryption and/or IBE is being used, and if either one is not being used, what architecture is being used instead of them.

Conclusion

Evaluating any security product for enterprise use can be challenging, and this is particularly true with cryptographic products. By relying on some basic criteria, various products can be compared with each other in an objective way. Even though there may be existing third-party comparisons of email encryption software products, such comparisons involve a lot of generalization, and they can’t possibly take an individual organization’s requirements, needs, and culture into account. It is, therefore, necessary that each organization perform its own evaluation of any email encryption software product it is considering. Note that most vendors make trial versions of their products available for download.

This article presents several criteria that are generally helpful to use when evaluating products. However, these criteria aren’t necessarily the only criteria that’s needed. Each organization may have additional requirements that merit inclusion in the list of criteria. Think of this article as a starting point for creating a personalized list of criteria evaluations.