ENCRYPTION - OTAVA · Web viewAs you can see, encryption is very useful in ensuring the confidentiality and integrity of data as well as proving the point of origin (which serves

This document is Copyright 2010 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 document is provided “as is” without any express or implied warranty. This document 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 preemption issues related to this document. Therefore, this document may need to be modified in order to comply with Wisconsin law.

The Basics of Encryption

Purpose

The purpose of this document is to provide a high level overview of encryption, and some of the standard techniques in which it is used to protect information. This includes such topics as encryption types, hashing, email, data transfer, remote access, key management, and securing portable devices like laptops, blackberry's, smartphones, etc.

This document does not intend to recommend or promote any particular product or technology. Where specific brands or products are mentioned, they are used as examples only. There are many solutions available, and this paper makes no attempt to recommend any one solution over another.

Definition

So what is encryption? Simply defined, encryption is:

"…the process of transforming information (referred to as plaintext) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key." (Wikipedia, 2009)

The Breach Notification Rule under section 45 CFR 164.402 defines:

"Unsecured protected health information means protected health information that is not rendered unusable, unreadable, or indecipherable to unauthorized individuals through the use of a technology or methodology specified by the Secretary in the guidance issued under section 13402(h)(2) of Public Law 111-5 (American Recovery and Reinvestment Act of 2009 (ARRA) on the HHS Web site."

The “Secretary” of the U.S. Department of Health and Human Services (HHS), according to ARRA, Title XIII – Health Information Technology of Economic and Clinical Health Act (HITECH), Subtitle D, Part 1, Improved Privacy Provisions and Security Provisions, Section 13402(h)(2), is supposed to:

“…. after consultation with stakeholders, issue (and annually update) guidance specifying the technologies and methodologies that render protected health information unusable, unreadable, or indecipherable to unauthorized individuals, including the use of standards developed under section 3002(b)(2)(B)(vi) of the Public Health Service Act, as added by section 13101 of this Act.”

…and finally, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), states:

"A covered entity must, in accordance with §164.306… Implement a mechanism to encrypt and decrypt electronic protected health information."(45 CFR § 164.312(a)(2)(iv))

1

Asymmetric vs. Symmetric Encryption, and Hashing

“Are there different kinds of encryption? And how do I know if they are truly safe?”

There are a few things about encryption that are important to understand. There are many books and other publications on the subject of encryption that go into much more detail, but here are the basic things that everyone should understand:

Symmetric Encryption

Cryptographic solutions fall into one of two types. Symmetric encryption requires that each party who wants to decipher the encoded message (cipher text) must have the secret key (or password). So if Bob wanted to send Alice his grandmother’s secret recipe for chocolate chip cookies, he could encrypt the message and use the key “My dog has fleas” to do so. Now for Alice to decrypt that message, she would need to know the passphrase (or “key”). This works well when the intended recipients are few or when there are only a small number of secret messages that will be delivered over time. However, the management of secret keys for each message becomes complicated real fast especially as the number of intended recipients grows. This can become a key management nightmare. The other issue is, how do you deliver the secret keys to each recipient securely?

Asymmetric Encryption

Not long ago, some real smart people from MIT developed a system known as Public Key encryption. Simply described, each person has two keys. One is a secret (or Private) key, and the other is a Public key. Public keys can be stored in a public database (often online) for anyone to see. If Bob wants to send Alice a secret message, all he needs to do is to encrypt that message with Alice’s Public key and send her the message. The trick is that ONLY Alice’s Private key can decrypt the message. Now Alice and Bob do not need to worry about sending the private keys to anyone, because they only need to know each other's Public keys, and can keep their private keys to themselves.

Additionally, Bob can encrypt a message with his Private key knowing that anyone can decrypt it with his Public key. Now why would Bob want to do this? Because anyone who used Bob’s Public key to decrypt the message would KNOW that only Bob could have encrypted it (remember that Bob used his Private key that only he knows). This process is referred to as “Digitally Signing” and it is used to prove the Origin of the message. In this manner, a digital signature is much more reliable than a written signature which can often be easily forged.

Hashing

Another clever use of encryption is to create a unique fixed length string of characters from a selected text (such as the entire document). This string is called a HASH. If anything at all changes within that document (or file) then the HASH is completely different. This process is used to verify the INTEGRITY of the file. As an example, if you were to create a hash of the entire Library of Congress you could have a hash that looks like this:

31a8b73156f221bfa56529145b608687

Now if I change only one comma in that entire collection of data, the hash produced would create a completely different string, like this:

30d9e3bd5acd2036f4d0d7b19837269d

Using this hashing process, and by comparing the hashes of the original and received messages or files, Alice could tell immediately if anything had been altered within the message.

2

A hash is a one way process and is impossible to reverse. That means that in no possible way could you create all of the data in the Library of Congress with only the hash that was created. Because of this, hashes can be posted publicly, or delivered without any concern of privacy or security short-comings. In fact, many people will post the hashes for their applications on the same page as the download so you can tell if the application has been altered in anyway.

As you can see, encryption is very useful in ensuring the confidentiality and integrity of data as well as proving the point of origin (which serves to prove non-repudiation)

Algorithms

An algorithm is simply the mathematical formula used to encrypt the data. For example, in the following illustration the sentence fragment is encrypted using a simple substitution algorithm:

Plain Text: The quick brown fox Algorithm: A=1, b=2, c=3, d=4, etc… <space>=255Cipher Text: 20 8 5 255 17 21 9 3 11 255 2 18 15 23 14 255 6 15 24

Over the years there have been many algorithms developed: DES (Data Encryption Standard), 3DES (running data thru DES multiple times), AES (Advanced Encryption Standard), Blowfish, and others. Many of the older algorithms have been broken, or ‘cracked’, and are now useless. The current federal standard is AES.

Encryption algorithms are rated on several factors, most importantly the key length – the longer the key, the stronger the encryption. DES and 3DES, for example, were originally created to use a 56-bit key. Data encrypted with DES can now be cracked in a matter of hours on a moderately powerful computer. The AES algorithm is available is 3 key strengths: 128-bit, 192-bit, and 256-bit; obviously, the 256-bit key is the strongest. It is estimated that, on a machine that could crack a single DES key in one second, it would take 149,000,000,000,000 (149 trillion) years to crack the AES128 algorithm; by comparison, the age of the universe is currently estimated to be less than 20 billion years (NIST, 2000).

The federal FIPS 140-2 standard “specifies the security requirements that will be satisfied by a cryptographic module utilized within a security system protecting sensitive but unclassified information” (NIST, 2002). When choosing an encryption product, look for those that are certified to be compliant with this federal standard – this ensures that it will meet any criteria specified by federal law, either now or in the foreseeable future, and will be more than sufficient to pass an audit.

HIPAA and Encryption

The HIPAA encryption standard specified in the security rule is deemed "addressable" meaning that the covered entity (CE) must either implement encryption or come up with a 'reasonable and appropriate' solution to meet the regulatory requirement. As encryption technology has developed and become more affordable, it is becoming more difficult to take the position that there are any 'reasonable and appropriate' alternatives to encryption.

To add to the already complicated interpretation of the rule(s), the recent HITECH Act specifies severe penalties for breaches of unsecured PHI, and further states that these penalties do not apply if data is encrypted or otherwise rendered unusable, unreadable, or indecipherable.

Taking all this into consideration, the practical implication is that CEs will have exposure to regulatory penalties unless data is encrypted. Recent audits by OCR, OIG, and other agencies indicate that these agencies will not hesitate to impose sanctions for noncompliance involving a failure to encrypt. In short, it is much safer to encrypt than to attempt to create an alternative solution.

3

But… what to encrypt, and how? Data (ePHI) may be stored and/or transmitted in many ways; are we to believe that we must encrypt the data all the time, in all its forms?

Simply... no. As the result of a proper risk analysis, we can identify the specific areas requiring encryption and implement the appropriate measures to safeguard the data. Some of these major areas are illustrated in the following pages, with guidance on when and how to encrypt.

Common Uses

Email Encryption

“Okay, so we need to encrypt email – what does that mean, and how do we do it?”

While the above analysis would apply to both data in motion and data at rest, email presents one of the most likely vehicles for breach, and is the first area to address when implementing encryption. As an example, most patients have access to email, and it is a well understood technology; it is also one common area likely to be investigated by an auditor.

The protocols used for sending email were created a long time ago when there was little if any concern for privacy of the information being sent. Because of this, standard email is inherently not secure. The data being delivered is transmitted in what is commonly referred to as “Plain Text”. What this means is that a person could intentionally intercept data flowing between the sender and the receiver without much effort, and could read the entire message. In this manner, this person could be copying the data, or changing it at will. So how can you protect yourself and that information which could be leaked from sending or receiving protected information in an email?

Public Key email encryption is generally managed in one of three ways:

At the desktop (local level) At the gateway (network perimeter) From a secure server outside of your network (in the “cloud”)

The encryption process is roughly the same in each case, although the steps necessary may differ. The diagrams on the next pages explain the email encryption process in more detail:

4

Figure 1

5

Figure 2

A cloud-based solution works similarly to the gateway solution shown above, but does not require hardware or software, and there are fewer key management considerations.

There are advantages and disadvantages to each solution...

As the diagram on the next page shows (figure 3), the local solution encrypts the message from the point of origin (Outlook, or some other email program), meaning it is encrypted over the local network as well as over the Internet. A gateway solution leaves the message in plain text on the local network, encrypting it only when it leaves the organization. However, management of the encryption keys is automated with a gateway or cloud-based solution, while it is mostly a manual process with local encryption.

The selection of an encryption solution MUST take all these factors into account. Also, gateway solutions may ensure that encrypted emails can be sent to anyone, regardless of whether the recipient has their own encryption solution; local solutions require the recipient to have a compatible encryption solution as well.

6

User A User B

INTERNET

EncryptionGateway A

EncryptionGateway B

Public Key Bon Gateway

Private Key A

Private Key Aon Gateway

Private Key B

Private Key Bon Gateway

Plain Email Message

Encrypted Email

Message

Public Key B

Encrypted Email

Message

Encrypted Email

Message

Encrypted Email

Message

Plain Email Message

Local Process1) User creates email message and selects to encrypt2) User checks for recipient’s Public Key3) If key exists, message is encrypted and sent4) If key does not exist, user must request (message NOT SENT)5) Once keys are exchanged, message is recreated, encrypted and sent6) If recipient does not support encryption, no communication is allowed7) All key management is handled by the user(s)8) Communication is only available if the recipient’s key is available

Gateway Process1) User creates and sends email message normally2) Gateway checks for recipient’s Public Key3) If key exists, message is encrypted and sent4) If key does not exist, encrypted message is stored on server5) Recipient is notified (by plain email) that an encrypted message is waiting6) Recipient logs onto server and retrieves encrypted message7) All key management is handled by the gateway8) Communication is always available

Figure 3

Cost is another factor that must be considered, and not just the amount of money spent to purchase a solution; ongoing maintenance and support costs must be considered as well. Generally speaking, the larger an organization, the more cost effective a gateway solution becomes.

Another option is to encrypt the message and/or data and include it as an attachment in an otherwise unencrypted email. SecureZip, WinZip and PGP are examples of applications that have this capability – they will compress the data into a smaller file, and apply an encryption algorithm. These are usually protected by a password that controls the decryption process – without the password, the file is unable to be opened and read. This method also has the advantage of being able to combine several data files into a single encrypted-compressed object for emailing as a single attachment.

The danger of using this method is that a single password is the sole mechanism protecting the data from unauthorized access; the weaker the password, the less secure the data. There are many utilities available today that can crack a password-protected ZIP file; in many cases, only an hour or two may be required to crack the password and access the data.

Having decided to implement an email encryption solution, regardless of whether it is local or gateway based, the next question is, "What do I encrypt? …all email? …only PHI?" Well, it depends…

If PHI is to be sent outside the entity (i.e. to an external recipient) via email, it must be encrypted – that much is indisputable. But what about non-PHI - corporate confidential data, such as accounting records or employee files? In most cases, these are items that the CE would not want made public if they were to be obtained by someone other than the intended recipient. There are many examples of non-PHI data that should most likely be encrypted; only a complete risk assessment can determine which emails

7

need to be encrypted and which need not. Most encryption solutions – both local and gateway – have a mechanism for applying policies on what and when to encrypt.

As a general rule, err on the side of encryption! While encryption is not explicitly required by the HIPAA regulations, there is very little room (if any) for alternative safeguards.

Data Transfer

“We can’t afford to implement an email encryption solution, but we still need to transfer patient data to and from our payers and other business associates. What can we do?”

Often, protected data (including ePHI) must be transferred to/from other entities or business associates by a means other than email; File Transfer Protocol (FTP) is a common data transfer method. There are several means of securing data over an FTP connection – the data itself may be encrypted (protecting the data itself), the FTP connection may be secured (protecting the communication path), or a combination of both may be used.

There are two common methods to secure the standard (and insecure) File Transfer Protocol (FTP). The first method is to use Secure Shell (SSH) to copy the data from one location to another; this method is generally referred to as SFTP. Setting up and configuring an SSH server is relatively easy and inexpensive, and many companies currently support using this technology. The second method is to use Secured Socket Layers (SSL) to protect the connection of a standard FTP transmission. This is referred to as FTPS and is also very common.

And, as with email, the data itself may be encrypted; again, there are many utilities that can be used to secure the data before sending.

For added protection, the two methods may be combined – sending an encrypted file over an encrypted connection. The benefit to encrypting both the data and the communication path is to mitigate the risks that each one has separately. For example, only protecting the communication path (data in transit) may mean that unencrypted data is sitting on your internet facing server or the recipient’s internet facing server for extended periods of time. If there were to be a breach of that system, there would be no protection of the data that was delivered. If you only send encrypted data (data at rest) over a standard unencrypted FTP connection, then the credentials that you are using to log in (or the ones used to connect to your server) are being transmitted openly. A malicious person could capture these credentials and log into the server themselves, altering the encrypted data file, or making a copy for later use. As technology advances, it is very likely that the encrypted file captured today could be easily decrypted in 5 years; most ePHI will still be as relevant and useful in 5 years as it is today.

“This would require us to learn something new - aren’t there any websites we can use? That would be really easy, and we already know how to use the Internet.”

In addition to SFTP/FTPS, there are many Internet-based file transfer, or file storage and retrieval sites which use SSL to protect the data transfer. The sender simply needs to set up an account with one of these providers, create user accounts for those people with whom they need to share data, and copy the data to the site. While this method is generally secure, extreme care should be taken when initially choosing a provider for this service. Things to consider include system availability, system security, what provision will be taken in the event that you wish to terminate your relationship, or if they go out of business, etc.

8

Questions that should be asked include:

Do they employ redundant systems to ensure availability? Do their servers need to be encrypted or have they determined through their risk analysis that

other compensating controls are sufficient? Is the upload/download process secure (SSL / HTTPS / SFTP / SSH)? Have they been certified to use the level of encryption that you or your business partners

demand (FIPS 140-2 compliant)? Are their controls regularly audited? Will they guarantee appropriate destruction methods of hard drives or backup tapes which may

contain your data?

“Well okay then, we can’t afford and don’t have the expertise to implement and support a technical solution. We’ll just use a courier service and send copies of the data on CD.”

BZZZZZZZZT – not so fast! What happens if the courier loses the CD? ...or delivers it to the incorrect place, or person? ...or, worse yet, makes a copy to sell to the highest bidder? The data must still be protected; encrypting the data file(s) on the CD is the only way to ensure that. The methods presented in this paper for encrypting data at rest will insure that your data is secure no matter what method is used for transfer.

Remote Access

"We're trying to cut costs, and help the environment. I've heard about telecommuting; how can I let my employees work from home?"

Telecommuting, or working from a remote location, is becoming a common method for controlling expenses, and helps the environment by putting fewer cars on the road. Remote access systems allow employees or other users to securely connect to applications and data as if they were in the office. There are several means of granting access to applications and data from remote locations; one of the most common is with a Virtual Private Network, or VPN. As the name suggests, the VPN creates a temporary encrypted connection into the host network that exists only for as long as needed. There are two types of VPN – either is just as secure.

The standard VPN requires a client utility to be installed on the remote workstation, and creates an encrypted connection, or tunnel, into the company's network. This method uses keys (similar to the keys used in email encryption) to authenticate the remote computer, and the IPSEC protocol to create and secure (encrypt) the tunnel. One advantage to this is that the connection can be better controlled by the company – connections are only allowed for computers with the appropriate client utility. Most firewalls (you do have a firewall, don't you?) have the ability to deploy and establish VPN tunnels, using their own client utilities. Remote users must still supply their ID and password to connect, just like they were in the office.

Recently, a new type of VPN has become very popular – the SSL VPN. Instead of having an installed client utility, the SSL VPN is set up as a secure website (similar to how banks provide online banking services). Because there is no client to install, this has the advantage of being available to anyone, from anywhere, and not just from a specific computer.

In either case – SSL or IPSEC – any/all client applications would need to be installed on the remote computer in order to be accessed and used.

9

"Well that's no good – we don't have enough licenses to install our applications on every computer that could be used to access our systems. How do we get around that?"

Another option – available with some SSL VPN solutions – is to make the applications available on the website. After the user connects and logs into the network (oh yes, they still have to log in – again, think online banking), the applications are published as icons on the web page. Citrix, with their Citrix Access Gateway product, is probably the best known solution of this type.

"Our software vendor needs to access our server to update their application, but they want to charge us for travel, food, and lodging. Can they use remote access instead?"

Absolutely! This is a great use of remote access technology, and can help offset the costs associated with implementing such a solution. It also allows for faster response, and decreased downtime in the event of a software problem.

"Our vendor says they want to establish a 'Lan-to-Lan' VPN – that sounds complicated and expensive. What is it, and how does it work?"

A Lan-to-Lan (or L2L) VPN is very similar to the client-based IPSEC VPN discussed earlier. However, instead of requiring a client utility, this solution creates a permanent encrypted tunnel between the two networks. Again, many firewalls have this capability, and there are dedicated VPN solutions available from companies like Cisco, Juniper, and others.

While there are many advantages to using this technology, VPN's can be expensive to implement and maintain – only a complete risk assessment can determine whether this technology is appropriate for any particular organization. The important point to remember is that if you decide to allow access remotely, you must ensure that the connection and/or the data is encrypted.

Portable Devices

Laptops

"I've heard a lot on the news about laptops being stolen, and patient or employee records being exposed. Some of our employees have laptops – what do I need to do?"

With many of today’s laptop computers providing portability as well as being suitable replacements for desktop computers, more and more users have laptop computers. The result is increased risk to an organization’s data which resides on the laptop, since laptop computers are more susceptible to being lost or stolen. The best way to protect sensitive data is to not store it on the laptop hard drive in the first place; through the use of remote applications (i.e. web applications, Citrix, etc.). However, if sensitive data must be stored on the laptop computer hard disk drive, the best way to protect it is by use of encryption. There are generally two ways to encrypt data on a laptop hard disk drive, full disk encryption and file/folder level encryption, or some combination of the two methods. In any case, properly centralized, IT managed data backup and key management are extremely important, since a lost or damaged encryption key could result in permanent data loss. It is also important to consider your requirements related to eDiscovery when looking at laptop data encryption (i.e. disk drive imaging, recovery, archival, etc.). There are several types of encryption products available and the cost of encrypting data on a laptop computer is generally quite small when compared to the risk of exposing sensitive data.

10

File and Folder Level Encryption

File/folder level encryption is typically selective, being performed manually under direct user control, or via an automated program. Some file/folder level encryption products can encrypt files automatically, based on specific configuration for file encryption by file location (e.g., folder), file type (e.g., spreadsheets), or source application (e.g. Excel).

The Windows Encrypting File System (EFS) is one example of a basic file/folder level encryption product. It can be centrally activated by using Active Directory Group Policy Objects to encrypt specified files or folders. However, like all file/folder level encryption products, it relies on users to properly write sensitive data into predefined protected folders, and cannot stop users from copying sensitive data, which is supposed to be encrypted, to unencrypted locations (either on the hard disk drive or on removable/portable media).

There are more sophisticated file/folder level encryption products which do more, and some offer stronger policies and enforcement which make it less likely that sensitive data will go unencrypted on the laptop hard disk drive or on removable/portable devices (e.g. USB drives).

Full Disk Encryption (FDE)

Full disk encryption (FDE) does just what the name implies; it encrypts everything stored on a physical disk or a logical volume. The purpose of FDE is to ensure that all data written to the hard disk drive is always encrypted. This includes not only sensitive data and files, but also application and operating system files (i.e. page files, data caches, etc.). By applying encryption to the disk drive(s), any/all data is encrypted the moment it is written to the drive, and it is completely inaccessible if the drive is removed or is accessed externally. The only way to access the data on a FDE disk is to use the approved, predefined access methods (usually the application used to create and manage the data).

How does it work? Just like other encryption schemes, a key is used to convert the data to an unreadable form, and to convert it back into something readable when needed. An example of one type of FDE encryption is the BitLocker feature in Windows 7. The BitLocker tool encrypts entire disk volumes and utilizes security features of the laptop computer hardware and operating system (i.e. Trusted Platform Module (TPM) chip, USB keys, etc.). Since it encrypts by disk volume, any data written to unprotected volumes will be unencrypted.

There are FDE products which are more comprehensive and encrypt the entire contents of the hard disk drive, sector by sector, and bit by bit (including boot sectors, swap files, OS files, and user data). Most FDE products provide additional protection through the use of Pre-Boot Authentication (PBA), authenticating the user before the operating system starts. The authentication, encryption, provisioning, and reporting capabilities vary for each FDE product, but enterprise FDE products typically provide features like Windows single sign-on, centralized administration (i.e. password resets), centralized logging for security audit and compliance reporting, and features like a remote kill switch if a laptop computer is reported lost/stolen or doesn’t periodically check in with the organization’s FDE server.

Comparing FDE and File/Folder Encryption

"I'm confused... what are the pros and cons of file and full disk encryption?"

The main drawback of file/folder level encryption is the possibility of sensitive data not getting encrypted due to the selectivity of this method. Also, since individually encrypted files, or groups of files, can migrate throughout the organization (i.e. onto file servers, as email attachments, etc.), use of centralized key management and proper key archiving is imperative, to ensure these files can be decrypted in the future.

11

A drawback with FDE is that initially encrypting an entire laptop disk drive can take hours, not including the time necessary to ensure there is a full backup of the laptop disk drive before starting the encryption process. Also, due to the way FDE works, encrypting every bit of the hard disk drive, FDE products have a tendency to find bad laptop hard drives more quickly than they would otherwise be discovered (if ever). In addition, proper procedures must be put in place since some FDE pre-boot authentication methods can interfere with other programs used by the organization to manage the laptop computer (i.e. asset tracking, sign-on processes, desktop administration, patching and auditing tools, etc.), since they cannot remotely reboot the computer without the user’s credentials. Another consideration is the potential impact to data recovery if a FDE laptop computer hard disk drive is corrupted or damaged.

Other Portable Media

"Many of our employees have Blackberry's, or some other kind of smart phone that could allow them to take data with them on the road. Do these need to be encrypted? And if so, how do we do it?"

Portable devices include Blackberry's and other mobile phones that support wireless access, and have the ability to store messages and other data; this category also includes CD's, DVD's, USB or “thumb drives”, iPod's, and similar devices. All of these devices have the capability to store confidential or sensitive information that creates an increased risk of an intentional or accidental loss of confidential patient or business information.

There are several controls that an organization could implement to address this risk:

Have a policy that forbids storing data on the device. Deploy technology to limit what information is stored on the device. Enable built-in functionality, i.e.,passwords, that controls access to the device. Deploy technology to encrypt any data stored on the device. Implement some combination of these controls.

The first control has a number of shortcomings, the least of which is how to measure compliance. This approach does nothing to address the risk of a confidentiality breach if a device is lost or stolen.

The second control relies on technology to examine all data as it moves from corporate data storage to a portable device. This approach typically uses a lexicon of sensitive words, phrases or other word and number patterns to control the transfer of data. While this will reduce or control the type of data transferred, it will not eliminate the risk of a confidentiality breach if a device is lost or stolen.

Many of these devices have built-in functionality that requires the entry of a password in order to use the device. This feature would control access to the device and by extension limit access to all stored data. However unless a strong password is used, one not easily guessed, there is still a considerable risk that a lost or stolen device would result in a breach of confidential data.

Finally, data encryption delivers a high degree of confidentiality and provides a safe harbor if there is a breach of patient information when a device is lost or stolen. Encryption renders the information unreadable and unusable unless the encryption key is available.

Many of these devices offer encryption solutions already that should be explored. For example, Blackberry Enterprise Server (BES) offers data encryption using the AES256 algorithm. Also, by default, the BES Solution generates the master encryption key and message key that the BES and BlackBerry devices use to encrypt and decrypt all data traffic between one another.

12

By using a combination of the last two control options, password controlled access and data encryption, the risk of a breach of confidential information is significantly reduced. Adding the second control will further lessen the risk by limiting what information can be transferred to the device. There are several commercial security applications available that will enforce encryption and other controls on devices that do not natively have this functionality, including the ability to bit-wipe the device (delete all data) after a defined period of inactivity (days or weeks), or after a set number of failed password attempts.

Each business entity needs to determine which controls are appropriate. What is the risk associated with information leaving the organization? What is the risk of the information falling into the wrong hands - monetary fines, legal action, loss of intellectual capital, and loss of business reputation? Each business has to decide what information needs to be protected. Each business has to consider the cost of the control(s) and the value of the information needing protection. At the end of the day it boils down to a business decision that is implemented with technology.

As discussed previously, SecureZip, WinZip, PGP, and other utilities can encrypt and password-protect data; once the data is encrypted you can deliver it by email, over an FTP (or similar) connection, or on some other form a media (e.g., DVD, CD or USB Drive, etc). One of the most common disadvantages with this method is in key management. It can become difficult to manage all of the keys and passwords that belong to each file and for each intended recipient. You also need to ensure that you are delivering the key in a secure manner.

Data at Rest

"I suppose now you're going to tell me that we need to encrypt our servers too? You wouldn't really do that, would you?"

Data at rest is data that is stored on the disk drives of your servers and computers, on backup tapes, or elsewhere, when it is not in use. You may ask why data that is safely locked away in your server room needs to be encrypted; there are several reasons:

Virtually any server can be accessed from anywhere by someone who knows what they are looking for and is motivated to get it. That means that unencrypted data could be available to anyone who knows how to access your systems (yes, that includes employees)

Disk drives fail and are replaced; servers grow old and slow and are retired. These all need to be properly disposed of - until a disk drive is totally destroyed the data on it is accessible. In many cases failed drives are no longer locked in your server room, but rather are kept at the desk of the IT person where the cleaning staff could simply walk away with it

Not all servers are kept in locked rooms, safely hidden away in a hospital’s basement. Especially with small offices, often the only lock is the lock on the office door

The solution again is full disk encryption (FDE). By applying encryption to the disk drive(s), any/all data is encrypted the moment it is written to the drive, and it is completely inaccessible if the drive is removed or is accessed externally. The only way to access the data on a FDE disk is to use the approved, predefined access methods (usually the application used to create and manage the data). How does it work? Just like other encryption schemes, a key is used to convert the data to an unreadable form, and to convert it back into something readable when needed. There are many available options for implementing full disk encryption; users of newer Microsoft operating systems even have a disk encryption program called Bit Locker built in and ready to use at no additional cost.

"We back up our servers to tape every night, and store the tapes off-site. Do we need to encrypt them too?"

13

We all know that tapes wear out and get thrown away. Tapes are often stored off-site for safety, are shipped from one building to another, or are even transferred across the country. With all this tape movement, it is not uncommon for them to be lost. It is a trivial matter for someone to retrieve data from a backup tape. Most vendors of tape backup solutions offer encryption as a standard part of their product; use it - it is an inexpensive way to apply protection to the data stored on tape. If your tape backups cannot be encrypted you should either not be sending tapes anywhere outside your facility, or you should be looking for an alternative that supports encryption.

To dispose of old tapes, you could take them to an MRI unit and fire up the magnet, run them through a trash compactor, burn them, or otherwise destroy the tape. For old hard disk drives, drilling a hole thru the disk housing (and thru the platters inside) will render the disk permanently unreadable. In either case, destroying the medium (disk, tape, etc) is the only sure way to prevent access to the data.

Securing The Keys

"As we encrypt more and more of our data, what happens if the keys get lost or a user forgets a password?"

Key management can be a challenge – this section deals with the subject in detail.

Proper key management is probably one of the most important aspects of data encryption. The loss or corruption of cryptographic keys can lead to the loss of access to systems and data. The larger and more diverse your environment, the more distributed your keys can become. You will need to pay particular attention to the importance of key lifecycle management. Key lifecycle management refers to key management, generation, usage, storage, archival, and destruction.

Key Management

The proper management of cryptographic keys is essential to the effective use of cryptography for security. Ultimately, the security of information protected by cryptography directly depends on the protection afforded the keys. All keys need to be protected against modification, and keys used for data encryption and digital signatures need to be protected against unauthorized disclosure. All users (end users and administrators) need to be aware of their liabilities and responsibilities with respect to properly managing cryptographic keys, and need to understand the importance of keeping their cryptographic keys secure at all times. Managers and administrators should be prepared for the possibility of cryptographic key compromise and should have proper controls in place to adequately manage this type of situation. Whenever possible, organizations should utilize centrally stored and managed cryptographic encryption keys. User generated and managed encryption keys require much greater vigilance of key lifecycle management procedures, as the organization could lose access to data if something were to happen to an employee or they were to leave the organization without divulging the keys used to encrypt sensitive or mission critical company data.

Passwords are generally used to protect (encrypt) cryptographic keys used for data encryption and digital signatures. Passwords are also keys, but are typically much simpler than the mathematically generated cryptographic keys, and sometimes the cryptographic encryption key is derived from a user entered password. As a result, data encryption systems are only as strong as their weakest link, which is usually the password used to protect the cryptographic keys.

There are several different types of encryption keys; the National Institute of Standards and Technology (NIST) defines about 20 different types. However, for data encryption, one can generally think of two types of applications, applications which encrypt data in transit using short-term keys (i.e. FTP, SSL, etc.), and applications which encrypt data at rest using long-term keys (i.e. WinZip, email, backup

14

systems, etc.). As one would expect, the key lifecycle management requirements will be different for short-term and long-term keys.

Key Generation

The generation of keys is the most sensitive of all the cryptographic functions, and any inadequacies in the implementation of the key generation function can seriously undermine the integrity of the system. Security measures should be in place to prevent unauthorized disclosure, modification, or replacement of keys. Depending on the key management implemented, some applications will locally generate keys (e.g. using WinZip to encrypt files) and other applications will generate and distribution keys from a central authority (e.g. centrally managed FDE). In either case, company employees must maintain complete control of generated keys from the time of generation and throughout their lifecycle.

Key Usage

The use of cryptographic keys in applications may require special handling and protection practices to ensure the confidentiality and integrity of the keys. You will need to establish procedures to ensure the protection of sensitive cryptographic keys, and use of physical devices (i.e. portable USB drives, etc) may be necessary to protect the keys. Authentication timeout features should be used to protect cryptographic keys from compromise or misuse and key recovery mechanisms should be implemented for cryptographic keys that are used to encrypt sensitive data.

Key Storage

The proper storage of cryptographic keys is critical to ensure the confidentiality and integrity of keys used by end users, administrators, and automated applications. You will need to ensure that appropriate storage methods are used whenever storing cryptographic keys. The two most common ways to store cryptographic keys are software storage and hardware storage. Procedures are necessary to manage software stored cryptographic keys due to greater vulnerability from key exposure; if using passwords, strong passwords should be chosen for providing access to the keys. There should also be adequate access controls for the encrypted key data file, to prevent theft or misuse. If storing cryptographic keys in hardware storage, you will need procedures to provide for the initialization, distribution, replacement, and destruction (as necessary) for the hardware token.

Key Archival

As part of the key lifecycle, archival of cryptographic keys is vital to ensuring that any data encrypted with those keys is always available to authorized parties. Sensitive user or centrally managed cryptographic keys should be archived for time periods which align with the data which has been encrypted by those keys. This will ensure that encrypted data can always be decrypted for as long as the encrypted data exists in the company’s data archives. For keys associated with digital signatures, key archival times will determine the timeline for signature validation.

Key Destruction

As part of the key lifecycle, expiration is an important part of key management. Reasonable lifetimes for keys should be determined, again aligned with the data encrypted with those keys. For keys associated with digital signatures, procedures are needed for the deactivation/revocation of keys so that data digitally signed prior to a compromise date (or date of loss) can be verified.

15

Summary

"That's way too much information to remember. How do I figure out what I need to do?"

The need for one or more encryption solutions in a healthcare setting is indisputable for all but the very smallest of entities. There are several situations where encryption may be, and probably is necessary:

Data at resto Laptopso Smartphoneso CDs / DVDs / Tapeso Workstations / Servers

o iPods, Thumb drives, etc Data in transit

o Emailo Data Transfero Remote Access

16

Of these, several are relatively easy and inexpensive to implement, and for smaller organizations a single solution may provide security in multiple areas. For example, installing PGP may allow you to do full disk encryption on laptops, create encrypted-compressed files for transfer, and send / receive encrypted emails as well. As the size and/or complexity of the environment increases, so does the difficulty and cost of implementing controls.

While it may be possible to protect PHI without implementing encryption, the risks associated with such a non-solution are too great to ignore; the ARRA/HITECH breach notification requirements alone are often a sufficient justification for encryption. So how do you determine what to encrypt, when, and how? The following steps will help to answer those questions, and to develop a solution:

1. Complete a risk assessmenta. Determine exposure to threats

2. Perform a full gap analysisa. Current controls vs. risks vs. exposure

3. Determine residual riska. Actual exposure, and associated cost of non-compliance

4. Prioritize the findings a. By exposure, by cost, or by some other appropriate comparison

5. Develop remediation plan(s)a. Highest priority first

6. Implement solution(s)a. Update your policies, if necessaryb. Don't forget to educate your users!

7. Document, document, documenta. All assessments, decisions, methods, etc, must be documentedb. Keep documentation for 6 years

8. Rinse, repeata. Security is not a goal, it is a process

Risk assessments are required by HIPAA anyway, so you're already doing the first step, right? The gap analysis and residual risk determination steps are part of a complete risk management strategy, so you should already be doing them as well. And, if the preceding statements are correct, then you already know your risk exposure. All that remains is to assign the appropriate priority to those risks, develop plans, and execute your strategy.

In most cases, the risks of not encrypting far outweigh the cost of implementing an encryption solution. A risk assessment will help determine the areas of greatest need, and a well documented plan will ease the deployment and management of the chosen solution and help to make it more effective.

Appendix A

The links below are intended for reference only and are in no particular order. There are many solutions available, from many vendors – the list below is a representative sampling of a few of these solutions. The HIPAA Collaborative of Wisconsin (HIPAA-COW) neither endorses nor recommends any individual company or product.

PGP Corporation – encryption solutionshttp://www.pgp.com/index.html

WinZip – data compression and encryptionhttp://www.winzip.com/index.htm

Citrix Corporation – remote access solutionshttp://www.citrix.com/English/ps2/products/product.asp?contentID=15005&ntref=prod_top

Checkpoint Corporation – firewall, VPN, and full disk encryptionhttp://www.checkpoint.com/products/index.html#gatewayshttp://www.checkpoint.com/products/datasecurity/pc/

Juniper Networks – firewall and VPNhttp://www.juniper.net/us/en/products-services/security/

Cisco – routing, switching, remote access, and VPNhttp://www.cisco.com/en/US/solutions/ns170/networking_solutions_products_genericcontent0900aecd80511fa7.html

GNU GPG – encryption solutionshttp://www.gnupg.org/

TrueCrypt – full disk encryptionhttp://www.truecrypt.org/

Guardian Edge – full disk encryption and endpoint protectionhttp://www.guardianedge.com/products/

WinMagic – full disk encryption and endpoint protectionhttp://www.winmagic.com/products

Barracuda Networks – VPN and gateway solutionshttp://www.barracudanetworks.com/ns/products/sslvpn_overview.php

OpenVPN – VPN solutionshttp://openvpn.net/

Credant – full disk and mobile device encryptionhttp://www.credant.com

Zix Corporation – email encryptionwww.zixcorp.com

Blackberrywww.blackberry.com

SecureZipwww.pkware.com

Appendix B

The resources below are available for more information on many of the topics presented in this paper. Again, HIPAA-COW makes no assertion or recommendation of any of the material available via these links.

http://en.wikipedia.org/wiki/Encryption

http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/brguidance.html

http://www.hipaa.ihs.gov/index.cfm?module=use_of_encryption

http://en.wikipedia.org/wiki/Public-key_cryptography

http://otfedb.sdean12.org

http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software

http://csrc.nist.gov/publications/PubsSPs.html

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf

http://hipaa-encryption.com/HIPAA-Compliance/phi-encryption/government-encryption-standard-advanced-encryption-standard-aes/

http://www.nist.gov/public_affairs/releases/aesq&a.htm