Disclaimer

This “Email Security Whitepaper” is Copyright  2003 and 2004 by the HIPAA Collaborative of Wisconsin (“HIPAA COW”). It may be freely redistributed in its entirety provided that this copyright notice is not removed. It may not be sold for profit or used in commercial documents without the written permission of the copyright holder. This “Email Security Whitepaper” is provided “as is” without any express or implied warranty. This “Email Security Whitepaper” is for educational purposes only and does not constitute legal advice. If you require legal advice, you should consult with an attorney. HIPAA COW has not yet addressed all state pre-emption issues related to Email Security.

DRAFT

E-mail Security

for the

Health Care Industry:

A Proposal for Collaboration in Wisconsin

Draft Version 2.1

January 13, 2005

Version 1.0 addressed the need for secure E-mail, defined business requirements, discussed four approaches, and identified sample products. Version 2.0 adds a proposal for a collaborative, standards-based approach to secure E-mail between organizations in Wisconsin. Version 2.1 includes an additional product summary.

Proposal for Wisconsin Collaboration on Secure Messaging Gateways

Introduction

Within the past ten years, we have experienced a significant change to the way that we communicate. We send electronic messages, referred to as e-mail, to communicate with friends and family and for business purposes. E-mail is an abbreviation for the term electronic mail, a way of transferring information electronically. E-mail users can send messages to others by specifying E-mail addresses. The message will travel from the sender’s computer through an internal computer network or for final delivery via the Internet.

Is E-mail Secure?

E-mail may be an efficient and cost effective way of transmitting data, but how secure is this method of information distribution? Many e-mail messages contain information that could be regarded as sensitive by either the sender or the receiver. In the case of the health care industry, messages may even include Electronic Protected Health Information (ePHI). ePHI is defined as being individually identifiable information that is maintained in any form by a health plan, clearinghouse, or provider and related to health condition, treatment, or payment.

The Health Insurance Portability and Accountability Act (HIPAA) requires health care institutions to comply with information privacy and security standards. Many of these institutions have drafted policies that forbid the transmission of protected health information via e-mail. Other institutions which have local area networks have permitted the transmission of protected health information, but only to other employees on the institution’s local computer network. While neither the HIPAA privacy nor security rule expressly requires it, most security professionals believe secure Internet e-mail is a reasonable step for a health care institution to take in order to abide by the HIPAA requirement to “ensure the integrity and confidentiality” of ePHI.

What Risks Exist?

The most likely risk is that someone could mistakenly send information to the wrong individual. This risk can be best addressed through properly communicated policies and a thorough training program. Health care institutions have invested time and money on information privacy awareness for employees for good reason.

Though a much slighter risk, e-mail sent over the Internet has the possibility of being read by others in addition to the intended recipients, especially at relay points. Some of the inherent risk of unencrypted e-mail is described below.

Internet e-mail is sent to relay servers, saved for a period of time on the local drive, then sent to the final server of its intended recipient. Since the messages are sent unencrypted, they are also stored unencrypted on the relay server. Anyone with access to the relay server has the capability of reading the e-mail.

Some relay servers store copies of the messages even after they have been sent off to the final recipient. Again, anyone with access to the relay server could read the message. If the message is stored on the system, it could remain in storage for months or years before someone actually reads the message. If the messages were encrypted, however, an unauthorized user would not be able to read the messages.

Relay servers are also targets of intruders trying to break into other networks. The SMTP service which is used by a majority of mail programs is always listed on the SANS/FBI Top Twenty List as a favorite target of hackers. Intruders breaking into a relay server have the ability to read any messages that are stored on the system. Again, if the messages were encrypted, they could not be read.

E-mail traverses the Internet through infrastructure equipment (routers, switches, hubs, etc). Often an e-mail will flow through multiple network devices before reaching its final recipient. Any e-mail that is sent unencrypted may be monitored while in transit. Encrypted messages are not able to be read.

E-mail that is unencrypted could be intercepted, read, and altered at the junctures mentioned. Motivated intruders could intercept the message and alter it before it reaches its final destination. They could add or remove items in the message and then alter the original sender’s headers. A person replying to the altered e-mail would actually be replying to the intruder; the original sender would never receive the reply. The result is compromised critical protected health information. As previously mentioned, encrypting the contents of the e-mail could prevent this.

What Are The Business Requirements For Secure Internet E-mail?

Encryption

Secure e-mail basically means e-mail that is encrypted at a sufficiently robust level, usually at least 128 bits. Most e-mail systems can encrypt e-mail in transit and at rest within the given system. Encryption is a mathematical way to scramble (encrypt) and unscramble (decrypt) digital information. Encryption helps ensure confidentiality

and privacy of information. Strong encryption (128-bit key length or greater) provides sufficient assurance that e-mail transmitted over the Internet will not be disclosed to unauthorized third parties. Encryption strength is relative and a function of key size and

encryption method. The bigger the number the longer it will take to crack the encryption code. For example, a 40-bit key can be cracked in a matter of hours, while a 128-bit key will take approximately 149 trillion years to crack, according to the National Institute of

Standards and Technology.[1]

B2B Focus

The focus of this paper is organizations rather than individuals. The primary business use of Internet E-mail today is between organizations; thus the most pressing need is for a business-to-business (B2B) solution. Business-to-consumer (or client) (B2C) use of

E-mail is growing but currently less common. There is also greater immediate pressure for secure B2B E-mail because B2C privacy concerns can be at least temporarily addressed by obtaining client authorization for the use of E-mail. The requirements and preferred solutions for these two kinds of use vary. Any solution for secure Internet

e-mail should first meet the B2B requirements but not be inconsistent with supporting B2C needs.

E-mail System Integration

Most organizations have a legacy commitment to their e-mail systems and the messages within them. E-mail systems are not going away anytime soon. The secure Internet
e-mail solution should recognize this commitment and work seamlessly with these existing systems.

Simplicity of Use

The e-mail system integration requirement dovetails with another requirement: use of secure Internet E-mail should be transparent to the user. The effective interoperability of most e-mail systems today has accustomed users to a high ease-of-use standard. Sending, receiving, reading, and storing secure Internet e-mail should be done through the organization’s current e-mail system with minimal complexity and training for the user and little need for desktop support.

Enforcement

The secure Internet e-mail solution should help ensure that e-mail that should be secure actually is. Rather than rely solely on the user at the desktop to always remember and to make correct decisions about selecting the secure option for individual e-mail, some products can manage encryption based on who the recipient or sender is or based on other business rules.

Continued Protection From E-mail-Borne Threats

It is nearly impossible to conduct virus checking or content filtering on encrypted e-mail. Some secure e-mail solutions interfere with these key activities.

Record Management

Most e-mail systems store e-mail on the user’s desktop and/or the organization’s servers. The organization thus controls the retention and disposition of these important records. Not all secure Internet e-mail solutions support this control. Some vendor solutions store sent e-mail on their servers, and sometimes recipients have no control over received

e-mail. Also, some solutions encrypt in such a way that organizations cannot access stored e-mail of current or previous employees.

Collaboration

Among HIPAA security and privacy requirements, secure Internet e-mail is especially challenging because an organization cannot implement it alone. Secure Internet e-mail by its nature requires collaboration between sending and receiving parties. Every organization has multiple such parties. Solving secure Internet e-mail requires collaboration among business partners. Regional voluntary organizations formed to help covered entities comply with HIPAA, like the HIPAA Collaborative of Wisconsin (HIPAA COW), are well situated to promote such collaboration.

Choice

One outcome of collaboration could be agreement for all members to use the same product. This would be one approach to solving a continuing problem of limited interoperability of vendor secure Internet e-mail solutions. A better approach is to encourage purchaser choice via competition among multiple vendors with interoperability based on standards. Whether through the HIPAA security rule or otherwise, the federal government does not appear to be establishing a standard. Voluntary standards through vendor and purchaser collaboration will hopefully provide the needed interoperability.

Future Requirements

The immediate requirement of secure Internet e-mail for HIPAA compliance is encryption to avoid impermissible disclosure of ePHI. Some vendor solutions for secure Internet e-mail provide capabilities for other requirements to which organizations will need to attend in the future. One is authentication of sender and receiver of secure Internet e-mail. Related functions are digital signatures, proof of receipt, and non-repudiation (eliminating the ability to deny the identified party sent a valid message).

Is there a solid technology foundation?

Public key cryptography is a well-established technology that uses private and public “keys” to encrypt and decrypt information. For example, if X wants to send Y an encrypted e-mail, X first obtains Y’s public key. X encrypts his or her message with this public key and sends the encrypted e-mail to Y. Y decrypts the e-mail using his or her own private key. X needs to obtain a public key from everyone to whom he or she wants to send an encrypted e-mail. Y has to do the same. After awhile, these keys expire. There has to be a source for valid keys. This technology is sometimes called PKI for Public Key Infrastructure—all the technology and administration involved in distributing and managing valid public keys.

This technology works well and is supported by most major e-mail systems today (with some vendor interoperability issues). It also addresses the identification, digital signature and nonrepudiation requirements. Most observers believe PKI will be the long-term solution for secure Internet e-mail. Multipurpose Internet Mail Extensions (MIME) is the standard that allows interoperability between e-mail systems. S/MIME (Secure MIME) is a standard on top of MIME that allows interoperability for secure e-mail using PKI technology. The State of Wisconsin has adopted S/MIME as a draft standard for secure e-mail for its agencies.

The main reason S/MIME and PKI have not been widely adopted is the complexity of administering the keys. As implemented in e-mail systems, keys are managed by the individual users at their desktops. Most users find the process confusing. Managing revoked and expiring certificates (which contain the keys and support the “trust model” needed to ensure that a public key belongs to whom it says it does) is a significant task for individuals and organizations.

What approaches are there?

There are four principal approaches to securing Internet e-mail.


A.End-to-end (desktop) encryption

This approach uses S/MIME or other standards such as Pretty Good Privacy (PGP). Each individual user has a digital certificate/key. The e-mail is encrypted at the sending desktop and remains encrypted until it is decrypted at the receiving desktop. Technically this can work well, but it has several disadvantages.

  • Managing the keys is burdensome.
  • Keys are no more secure than the desktops through which they are administered.
  • Because users can store e-mail encrypted with their personal key, management can lose control over these records, finding it extremely difficult if not impossible to decrypt messages deleted by employees or to access e-mail of separated employees.
  • It is nearly impossible to conduct virus or content filtering on encrypted messages.

The Wisconsin Department of Health and Family Services (DHFS) is currently piloting S/MIME desktop encryption with a few Medicaid HMOs. It is using GroupWise version 6 desktop clients to encrypt and decrypt e-mail. A few additional HMOs that wanted to pilot could not because their e-mail system versions were too old or did not support S/MIME at all. Due to the small number of users in each organization and the small number of organizations that are involved, the key management burden on users has been acceptable. Once keys are exchanged, sending and receiving secure e-mail is little different from those that are unencrypted.

Other communities, including the Commonwealth of Massachusetts and the New Zealand government, have attempted pilots of desktop S/MIME and have abandoned intentions to use the technology for broad-based deployment.

Below is a short list of the many commercial products available that implement this approach to secure e-mail:

DespatchBox

CipherPackPro

Encryptek

MailMarshal Secure

Omniva

ShyFile

ZipLip

ZixMail


B. Gateway-to-gateway (domain or server level) encryption

This approach uses similar technology to desktop encryption but performs the encryption and decryption at a server rather than at a desktop client. Rather than assign each user a digital certificate/key, the keys are assigned at an organizational level. This has several differences from the desktop approach.

  • There are radically fewer keys to manage.
  • Users are not burdened with key management.
  • Messages are encrypted over the Internet between organizations but can be decrypted within the organization.
  • E-mail is stored on the servers of sending and receiving organizations and remains under their control.
  • Management retains control over its records.
  • Virus checking and content filtering are possible.
  • Applications can use gateways to send or receive messages.
  • “Trust” is established at the organizational rather than the individual level.

This approach can work seamlessly with legacy e-mail systems—the user sends, receives, manages e-mail within their e-mail client. Administration is simpler, user burden is reduced, and organizational control over e-mail is retained. A major potential drawback is that identification occurs at the organization level rather than specific to individuals. For most business purposes, however, establishing “trust” at the organizational level should be sufficient. With this approach, business partners trust each other to manage their internal affairs such that specific users within each organization are reliably identified with means other than unique digital certificates (e.g., e-mail addresses).

New Zealand’s SEE Mail initiative is a gateway encryption environment deployed in over 40 agencies, and Massachusetts has completed a pilot program that demonstrated the potential of this approach.

A number of commercial products employ encryption of e-mail at the server level with some being deployed on an internal server, others on a third-party gateway. A few of these are listed below.

MailX3

A-Lock

HushMail

IronMail

Tovaris SecureMail Gateway

ZipLip

C. Secure Web Mail

In this approach, the sender posts a sensitive message to a secure Web site using an encrypted transmission.[2] An unencrypted e-mail that points to an obscure URL is then sent to the recipient. The recipient accesses the sensitive message at the URL using a secured session. The recipient uses an ID and password to access the secure session. The password is provided through a separate contact such as a telephone call or through self-registration by the recipient.

This approach has the following advantages and disadvantages:

  • The recipient only needs a Web browser and Internet access.
  • Users and organizations do not need to manage keys (beyond those used for session security).
  • Messages cannot be sent, read, or managed through existing E-mail systems.
  • The message resides on the provider’s server and

can be removed at any time by the sender.

in many systems cannot be downloaded, stored, or managed by the recipient except by cutting and pasting the text or saving the HTML page.

  • Users must manage IDs and passwords for each partner with whom they conduct e-mail this way.
  • Strong user identification, nonrepudiation and proof of receipt may be less rigorously supported.
  • Cannot perform virus scanning and content security checks due to use of SSL sessions for viewing and downloading.

This approach has the noted disadvantages compared to approaches that preserve an integration with existing e-mail systems. On the other hand, its main advantage is that such systems are not needed. This approach is the best alternative for business-to-client (B2C) secure Internet e-mail. Some of its disadvantages are lessened where many of the recipients (such as patients) will conduct secure Internet e-mail with only a few partners (such as doctors). It also works reasonably where one party (e.g., a doctor) conducts secure Internet e-mail with many others (e.g., patients). Where this works less well is where many parties conduct secure Internet e-mail with many other parties.