Requirement Evaluation
Numerous business concerns, such as the HIPAA security rules requiring encryption of sensitive health information passing across public networks, have made secure e-mail a concern for businesses. However, the plethora of programs, applications, and services promising to secure your e-mail can make evaluating the options overwhelming. A thorough evaluation starts be breaking the problem down into specific requirements that then can become the basis for comparing the choices. Such a list should include:
- Ease of Use,
- User Scope,
- Security,
- Sender Controls,
- Infrastructure.
Ease of Use: If the secure e-mail system is too difficult for end-users, it will decrease productivity across the organization and encourage users to find ways to avoid using the secure system. IT saw this in the 1990s when huge numbers of users turned off the security software on their desktops because it destroyed system performance, leaving companies open to malware and other security exposures. A secure e-mail system is only effective if it is used. Some questions to consider:
- Does the solution encrypt and decrypt with minimal commands or interaction? End-users should see little or no functional difference between encrypted e-mail and non-encrypted email.
- Does the system should operate across multiple platforms? Today’s employees may use desktop systems, laptops, tablets, or smartphones, or a combination of any of those.
- Does the solution impede in any way, the functionality of existing calendaring, tasks, or contact features? Depending on your organization, these features should be considered as they have become essential to most users.
User Scope: This requirement covers a couple of concepts, beginning with consideration of the user base. Does the solution provide easily received e-mail for the entire receiving audience? Issues receiving e-mails not only can be a source of frustration, but also may generate a high level of support calls. Does the solution lock you into certain kinds of clients or devices? This is a significant consideration that merits quantifying and analysis.
Security: The evaluation of security features for a given solution should consider methods of authentication and non-repudiation. The basic question is: When you receive the e-mail, are you assured that it is from the individual identified in the e-mail as the sender? Does that e-mail present a valid source of proof of an interaction in a given scenario? If that e-mail is intercepted, can an intruder easily read it? Consider whether the solution provides partial security or provides end-to-end protection.
Sender Control: E-mail is typically released from the sender’s control when it is sent from his client. From then on it can be copied, manipulated, stored, deleted, or forwarded by the recipient. You should evaluate whether the proposed solution provides for retention of control over the content of e-mail messages. For example, can an erroneous e-mail be shredded before it is read? Can a sender require a receipt without the recipient having to take action? Can access to the e-mail be restricted? Can the sender specify when an e-mail must be read? A given organization may or may not have use for these types of features, but any that may prove valuable should be considered in the evaluation.
Infrastructure: How would the solution be implemented and how would it interface with the existing infrastructure? This may seem obvious, but it is very easy to forget this issue when focused on evaluating other aspects of the solution.
For example, if the solution requires a significant Web element and a portion of the user base has limited connectivity, then such a solution would require significant infrastructure upgrades and considerations. If the solution asks for significantly more powerful endpoint devices than are currently in use, then you should include the cost of upgrading user hardware in the overall analysis. The impact of these issues is highly dependent on the specifics of each potential implementation. Therefore, they are not included in the general evaluations of various solution types below.
Evaluations
The most common secure e-mail solutions can be grouped in four categories: Public key, password-based, Web-based and key-server. Each has its own strengths and weaknesses. The following evaluation can serve as a starting point for your own examination of specific secure e-mail choices.
Public Key Solutions: Two of the most common public key solutions for security are Pretty Good Privacy (PGP) and Secure Multipurpose Internet Mail Extensions (S/MIME). These solutions rely on each user having a cryptographic key pair, made up of a public key and a private key. Typically, the user maintains the private key securely on his or her computer. The public key is made widely available for all recipients to access. The rating this technology is as follows:
- Ease of use: Public Key solutions are generally somewhat difficult to use. When used in conjunction with digital certificates, it requires that each end-user understand both digital certificates and keys. This may not be a practical solution, depending on your user base and could generate a major increase in support calls and complaints.
- User Scope: Public key solutions leave a lot to be desired. At best, only a small subset of e-mail users have digital certificates. Also PGP and S/MIME so not operate well together. Even S/MIME has different versions that are not always friendly with each other.
- Security: Public key solutions are usually highly secure. Senders use a highly secure private key to encrypt messages. These solutions work well with digital certificates that can provide strong authentication and nonrepudiation. Despite the drawbacks of managing keys and interfacing with other users, this combination provides the strongest security implementation available.
- Sender control: Based on the fact that an e-mail recipient receives the decryption key for the given message, there is virtually no sender control after a message is sent.
Password solutions: The sender of the e-mail encrypts the message using a password. The recipient enters the same password to decrypt. This simple method when simply implemented is rather sound, but obviously does not scale. Analysis:
- Ease of use: For established senders and recipients, these are simple programs to use. Although not simple operations, password entry in general is a well-known control and requires little education. Failures are often caused by lack of proper maintenance. Someone must provide the recipients with the password – often by phone – which can be time-consuming. Also, with each sender using different passwords, password management at the receiving end quickly becomes impossibly complex as the number of users grows, making this solution unscalable.
- User Scope: This is another field where password solutions fall short. Because each recipient needs a password from each sender, the systems reach is limited by an organization’s ability to deliver appropriate passwords to all its recipients and for those recipients to keep those passwords organized and secure simultaneously. This is not an enterprise solution.
- Security: Password-protected e-mail relies on the user password for encryption. The password is either the encryption key or part of the encryption key. Based on that, the encryption is susceptible to all the weakness of poorly chosen passwords.
- Sender control: Password-protected e-mail provides no sender control. Since the fixed passwords serves as the key to encryption, the recipient can do as he or she wishes with the message.
Web-based solutions: These are somewhat different in that the e-mail content is not included in a message. The recipient receives a message containing a link to a server where the message content is stored. He or she then retrieves the content via a secure Web connection, possibly after some sort of validation or registration.
- Ease of Use: Web-based solutions are relatively easy to use. The requirements to retrieve the message are generally simple, but it is obviously not a transparent system.
- User Scope: Being web-based, the scope of delivery of this solution is wide-reaching, with rare exception.
- Security: There is no guarantee that the service offers the best end-to-end security. Messages may be stored or transferred in clear text or left unencrypted the server. In the event of a physical breach at the service site, e-mails may be compromised.
- Sender Control: This approach offers the greatest sender control. The sender has ample opportunity to make corrections, deletions, or changes before a receiver retrieves the email.
Key-server based solutions: In this approach, keys are assigned to a specific message rather than individuals. A recipient receives a message, retrieves a key from a server – generally using some method of authentication - and uses the key to decrypt the message.
- Ease of Use: This is an easy mechanism to employ on the user side. Generally the work goes on behind the scenes and is invisible to the user.
- User Scope: The software that operates the encryption and key generation can be maintained by the sender alone, and can be accessed by most users. The maintenance of the authentication features will be more difficult.
- Security: As with public key mechanisms, the security features of key server solutions are strong. Each message is encrypted with a one-time use key. The difficulty comes in authenticating users. This mechanism separates user authentication from message delivery, which may have applications for some organizations.
- Sender Controls: Some sender controls are retained in this solution, including the ability to monitor when a message is accessed and destroy messages up until the recipient actually accessed it.
Action Item: Choose the solution that is for you. This evaluation and these requirements will hopefully provide an initial basis and formulate the right questions in evaluating your e-mail encryption solution options. Stick to common-sense questions, technological understanding and this experience-based approach for the right enterprise ready solution for your organization.
Footnotes: