Encryption Whitepaper - hipaa cow

disturbeddeterminedAI and Robotics

Nov 21, 2013 (3 years and 10 months ago)

98 views


1


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 withou
t 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
consul
t 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 B
asics of
Encryption


Purpose


The purpose of this docume
nt 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.

T
here are many solu
tions
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 pro
tected 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 sec
tion 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 Ec
onomic 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 technolog
ies 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 secti
on 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 informatio
n."

(45 CFR § 164.312(a)(2)(iv))


2


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 m
any 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 requ
ires 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 pass
phrase (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 tim
e. 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 recip
ient 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 P
ublic

key and
send her the message. The trick is that ONLY Alice’s P
rivate

key ca
n 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 hi
s P
rivate

key knowing that anyone can decrypt it with
hi
s P
ublic

key. Now why would Bob want to do this? Because anyone who used Bob’s P
ublic

key to
decrypt the message would KNOW that only Bob could have encrypted it (remember that Bob used his
P
rivate

ke
y 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


Anot
her 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 dif
ferent. 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 i
n 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 coul
d tell immediately if anything had been altered within the message.


3



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 create
d. Because of
this, hashe
s

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 h
as 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>=255


Cipher Text: 20 8 5 2
55 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 olde
r

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
-
b
it
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”
(NIS
T, 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 th
an 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 a
lready complicated interpretation of
the rule(s), the recent HITECH A
ct 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 indec
ipherable.


Taking all this into consideration,
the practical implication is that CEs will have exposure to regulatory
penalties unless data is encrypted.

R
ecent audits by OCR, OIG, and other agencies
indicate that these
agencies will not hesitate to impos
e sanctions for noncompliance involving a failure to encrypt.

In short,
it is much safer to encrypt than to attempt to create an alternative solution.



4



But… what to encrypt, and how? Data (
e
PHI) may be stored and/or transmitted in many ways; are we
to bel
ieve 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 m
ajor 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 dat
a 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, m
ost patients have access to email, and it is a
well understood

t
echnology; it is also
on
e
common area

likely to be
investigated

by an audit
or
.


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
secu
re. 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 mess
age. 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
e
mail encryption
is gene
rally

managed in
one of three

ways:




At the desktop

(
local

level
)



At the gateway

(
network

perimeter
)



From a secure s
erver outside of your network (i
n the “cloud”)


The encryption process is roughly the same in
each

case, although the steps necessary
may
di
ffer
. The
diagrams on the next pages explain the email encryption process in more detail:


5






























Figure 1
User
INTERNET
Public Key
Private Key
User
Public Key
Private Key
For every pair of users who need to exchange encrypted
email
,
each user must have the other person’s public key
.
It becomes obvious that the more people a user needs to
communicate with
,
the more keys he
/
she must maintain
.
Encryption is done using ‘Encryption Keys’
-

these keys
are used to both encrypt and decrypt messages
.
Each
user has two keys

a Public Key and a Private Key
.
As
the names suggest
,
the Public Key is exchanged with
other users or gateways
,
while the Private Key is not
.
To
send an encrypted email
,
the sender encrypts it using the
recipient’s Public Key
;
only the recipient’s Private Key is
able to decrypt the message
.
Local Solution
Public Key
Private Key
Encryption
Gateway

6


INTERNET
Public Key
Private Key
Public Key
Private Key
For every pair of users who need to exchange encrypted
email
,
each user must have the other person’s public key
.
With a gateway system
,
this key exchange is automated
.
Encryption is done using ‘Encryption Keys’
-

these keys
are used to both encrypt and decrypt messages
.
Each
endpoint has two keys

a Public Key and a Private Key
.
As the names suggest
,
the Public Key is exchanged with
other users or gateways
,
while the Private Key is not
.
To
send an encrypted email
,
the sender encrypts it using the
recipient’s Public Key
;
only the recipient’s Private Key is
able to decrypt the message
.
Gateway Solution
Encryption
Gateway
Encryption
Gateway
User
Public Key
Private Key























Figure 2




A cloud
-
based solution works similarly to the gateway solution shown above, but
does not re
quire
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, manag
ement 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

ensu
re that encrypted emails can be sent to anyone, regardless of whether the recipient
has the
ir own encryption solution
; local solutions
require the recipient to have a compatible

encryption
solution as well.




7


User A
User B
INTERNET
Encryption
Gateway A
Encryption
Gateway B
Public Key B
on Gateway
Private Key A
Private Key A
on Gateway
Private Key B
Private Key B
on Gateway
Plain Email
Message
Encrypted
Email
Message
Public Key B
Encrypted
Email
Message
Encrypted
Email
Message
Encrypted
Email
Message
Plain Email
Message
Local Process
1
)
User creates email message and selects to encrypt
2
)
User checks for recipient’s Public Key
3
)
If key exists
,
message is encrypted and sent
4
)
If key does not exist
,
user must request
(
message NOT SENT
)
5
)
Once keys are exchanged
,
message is recreated
,
encrypted and sent
6
)
If recipient does not support encryption
,
no communication is allowed
7
)
All key management is handled by the user
(
s
)
8
)
Communication is only available if the recipient’s key is available
Gateway Process
1
)
User creates and sends email message normally
2
)
Gateway checks for recipient’s Public Key
3
)
If key exists
,
message is encrypted and sent
4
)
If key does not exist
,
encrypted message is stored on server
5
)
Recipient is notified
(
by plain email
)
that an encrypted message is waiting
6
)
Recipient logs onto server and retrieves encrypted message
7
)
All key management is handled by the gateway
8
)
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 speakin
g, the
larger an organization,

the more cost effective a gateway solution becomes.



Another opti
on 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 enc
ryption 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 ma
ny 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?
…a
ll email?

…o
nly 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 wha
t 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

8


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

a
n

emai
l encryption solution, but we still need to transfer
patient

data to and from our payer
s

and other business associates. What can we do?”


Often,

p
rotected

data (including ePHI) must be transferred to/from other entities or business associa
tes
by a means ot
her 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 th
e
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
da
ta from one location to another;

t
his

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 connec
tion 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

p
ath

(
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 tha
t 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 coul
d 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
; m
ost eP
HI
will

still

be as

relevant and useful in 5 years as it is today.



This would require us to learn something new
-

a
ren’t there any websites we can use?
That would be really easy, and we
already
know how to use the Internet.”


In addition to
S
FTP/FTP
S
, th
ere 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 t
o 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 ta
ken in the event that you wish to

terminate your relationship, or

if they go out of
business,
etc.


9


Questions that should be asked include:




D
o they employ redundant systems to ensure availability?



Do their servers need to be encrypted or have they deter
mined 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

14
0
-
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, wors
e

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
expe
nses, 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 VP
N


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 encryp
tion) 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 appropri
ate 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 offi
ce.


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.



10


"W
ell 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 ava
ilable 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 probab
ly 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


tha
t 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 t
unnel 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 connect
ion 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 lapto
p 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 s
usceptible 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 stor
ed 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 m
ethods. In any case,
proper
ly

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
e
Discove
ry 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.



11


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 fil
es 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 prede
fined 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 encrypti
on 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)


Fu
ll 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 sensiti
ve 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 utili
zes 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 whi
ch 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 Au
thentication (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 s
ign
-
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 organi
zation’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
d
ue 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.



12


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 befo
re 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 ou
r 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 suppo
rt wireless access
,

and have
the ability t
o stor
e 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 dev
ice.



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 c
ontrols.


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 t
ype 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 contr
ol 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.


Fina
lly, data encryption delivers a high degree of confidentiality and provides a safe harbor if there is a
b
r
each of patient information when a device is lost or stolen.

Encryption renders the information
unreadable and unusable unless the encryption key is a
vailable.



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, b
y
default, the
BES

Solution generates the master encrypt
ion key and message key that the
BES

and
BlackBerry devices use to encrypt and decrypt all data traffic between one another.




13


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 enfor
ce 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 informati
on falling into the wrong
hands
-

monetary fines, legal action, loss of intel
lectual 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 boi
ls 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 si
milar) connection,
or on some other form a media (e.g., DVD, CD or USB Drive, etc).
O
ne of the most common
disadvantages with this method is in
k
ey
m
anagement. 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 a
t Rest


"I suppose now you're going to tell me tha
t we need to encrypt our

servers too? You
wouldn't really do that, would you?"


Data at rest is d
ata 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 se
rver room
needs to be encrypted;

t
here 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 system
s (yes, that includes employees)



Disk d
rives f
ail 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 rat
her are ke
pt 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 o
f
fice 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
unr
eadable form
,

and

to

convert it back into something readable

when needed
.

There are

many
available

o
ptions for

implementing

full disk encryption;

u
sers of

newer

Microsoft operating systems
even
have a

disk encryption

program called Bit Locker built in and
ready to use at no additional cost.






14


"We back

up our servers to tape every night, and store
the tapes

off
-
site. Do we need to
encrypt them too?"


We all know that tapes wear out and get thrown away.

Tapes

are often stored off
-
site for safety,

are

shippe
d 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.

M
ost vendors of tape backup solutions o
ffer encryption as a standard part of

their
product;

use it
-

i
t is

an

inexpensive way to apply

protection

to the data stored on tape
.

If your tape
backup
s

cannot be encrypted you should either not be sending tapes anywhere outside your facility
,

or
you sh
oul
d 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, drilli
ng 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 encryp
tion. 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 k
ey 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 agains
t 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 s
ecure 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 cen
trally 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 emplo
yee 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. Passwor
ds 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 encrypt
ion, one can generally think of two

15


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
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 applicatio
ns 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 generat
ed 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 es
tablish procedures to ensure the
protection of sensitive cryptographic keys
,

and use of physical devices (i.e. portable USB drive
s, 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
u
sed 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 stor
age. 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 key
s
.
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 fo
r 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 signatur
es,
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.


16


Summary



"That's way too muc
h 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 p
robably is necessary:




Data at rest

o

Laptops

o

Smartphones

o

CDs / DVDs / Tapes

o

Workstations / Servers

o

iPods,
T
humb drives, etc



Data in transit

o

Email

o

Data Transfer

o

Remote Access


Of these, several are relatively easy and inexpensive to
implement
, and for smal
ler
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.

Comple
te a risk assessment

a.

Determine exposure to threats

2.

Perform a
full
gap a
nalysis

a.

Current controls vs. risks

vs. exposure

3.

Determine residual risk

a.

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 necessary

b.

Don't forget to educate your users!

7.

Document, document, document

a.

All assessments, decisions, methods, etc, must be docu
mented

b.

Keep documentation for 6 years

8.

Rinse, repeat

a.

Security is not a goal, it is a process


Risk assessment
s

are required by HIPAA

anyway, so

you're already doing

the

first st
ep
, 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, an
d 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

17


documented plan will
ease the

deployment and man
agement of the chosen solution
and help to
make it

more effective.


18


Appendix A


The links below are
intended
for reference only and are in no particular order. There are many
solutions
a
vailable, from many vendors


the list
below

is a representative sampl
ing o
f

a few of
these solutions.

The HIPAA Collaborative of Wisconsin (HIPAA
-
COW) neither endorses nor
recommends any individual company or product.


PGP Corporation


encryption solutions

http://www.pgp.com/ind
ex.html


WinZip


data compression and encryption

http://www.winzip.com/index.htm


Citrix Corporation


remote access solutions

http://www.citrix.com/English/ps2/products/product.asp?contentID=15005&ntref=prod_top


Checkpoint Corporation


firewall, VPN, and full disk encryption

http:/
/www.checkpoint.com/products/index.html#gateways

http://www.checkpoint.com/products/datasecurity/pc/


Juniper Networks


firewall and VPN

http://www.juniper.net/us/en/products
-
services/security/


Cisco


routing, switching, remote access, and VPN

http://www.cisco.com/en/US/solutions/ns170/networking_solutions_products_genericcontent090
0aecd80511fa7.html



GNU GPG


encryption solutions

http://www.gnupg.org/


TrueCrypt


full disk encryption

http://www.truecrypt.org/


Guardian Edge


full disk encryption and endpoint protection

http://www.guardianedge.com/products/


WinMagic


full disk encryption and endpoint protec
tion

http://www.winmagic.com/products


Barracuda Networks


VPN and gateway solutions

http://www.barracudanetworks.com/ns/produ
cts/sslvpn_overview.php


OpenVPN


VPN solutions

http://openvpn.net/


Credant



full disk and mobile device encryption

http://www.credant.com



Zix Corporation


email encryption

www.zixcorp.com




19


Blackberry

www.blackberry.com



SecureZip

www.pkware.com





Appendix B


The resources below are available for more inf
ormation 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://otf
edb.sdean12.org


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


http://csrc.nist.gov/pub
lications/PubsSPs.html


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


http://en.wikiped
ia.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