HIPAA and the HITECH Act have been hot topics lately.  Why is that?  First, the U.S. Department of Health and Human Services has recently issued guidance stating “unsecure protected health information (PHI)” is essentially any PHI that isn’t encrypted or destroyed.  This means that no matter how much technology you throw at securing the data, if it isn’t encrypted, then it isn’t considered secure.  The second, and arguably more compelling reason, is that HIPAA-covered entities are required to send notification letters if there is a breach of unsecured PHI.  Only using proper encryption grants safe harbor in the event of a breach.

I recently sat down with Patrick Townsend, our Founder & CTO, to discuss HIPAA, the HITECH Act, and encryption key management.  Here is part 1 of 2 of his thoughts on this topic:

Download Podcast Now

With HIPAA and the HITECH Act, there seems to be an increased focus on encryption.

Yes, there really is.  The technology that everyone looks to for protecting PHI is encryption.  So, yes, there is a real focus on encryption.  It is important.  Everyone who is a covered entity within the definition of HIPAA and the HITECH Act really needs to focus on protecting their patient information.  Encryption is specifically called out in the rules for covered entities, whether you are a health provider, an HMO, or any organization that is within that arena of medical delivery.

Are there any specifications on what type of encryption an organization should use?

Yes.  The HIPAA and HITECH Act are pretty explicit in providing the standards that are the basis of the approach you should take.  If you read the rules, as they are today, which are due to be finalized this year, they point straight to industry standards in terms of the kind of encryption and the techniques you should use to protect data.  The basic recommendations, in terms of standards, are to look at the National Institute of Standards and Technology (NIST) for proper ways of doing encryption and key management.

While the regulations aren’t specific in saying “You must use XXX algorithm for your encryption” they say you must base your encryption approach on widely accepted standards.  Additionally, they make specific recommendations to NIST for those standards.  If you look at the NIST standards, which have been in place for a long time, they publish standards on encryption and key management.  The proper encryption for “data at rest” or database files is AES encryption.  So patient data, at rest, in any type, is typically protected with AES.

For “data in motion” or data that you are transmitting, like patient claim data or patient information, we have standard protocols.  PGP whole file encryption, for example, is a well-accepted mechanism for protecting whole files.  It has been FIPS 140-2 certified, which means it is provably based on NIST standards for encryption.  Also, using a SSL/TLS connection for protecting data that you transmit over a web site or a web connection is another standard that maps directly to NIST.  Customers who base their encryption on those particular technologies will line up with NIST recommendations and best practices, and therefore align up with HIPAA and the HITECH Act. 

There is also a set of standards around encryption key management.  NIST publishes the best practices standards for encryption key management.  You have Special Publication 800-57 and other Special Publications that go together that really talk about key management.  And you also have FIPS 140-2 certification.  So key management solutions that are FIPS 140-2 certified match up to these regulations. 

To summarize, you want to find technologies that are based on standards.  Certifications lend credibility to the claim that they are based on standards.  Any organization that needs to protect data should look for solutions that have FIPS 140-2 and NIST certifications to indicate they are properly based on standards.

To hear this conversation in it's entirety, download our podcast titled "HIPAA, HITECH Act, and Encryption Key Management."

Many of you have asked me about encryption and key management requirements for HIPAA and HITECH Act. I can understand why there is a fair amount of confusion about this. The US Department of Health and Human Services (HHS) has not issued the final rules, but they have indicated that the current Interim Final Rules are unlikely to change very much. The final rules are due to be published later this year, and may be updated on an annual basis.

The current IFRs indicate that encryption is an accepted method of protecting patient health information. However, there is no mandate for encryption, and medical providers (Covered Entities, in HHS regulatory speak) can use other methods to protect data. However, the guidance about breach notification is very explicit on the question of encryption. A medical provider can only avoid breach notification if the data is encrypted. In the event of a data loss where the data is not encrypted, the medical provider must report the breach to HHS and to the patients affected by the loss. The breach event is published on a public web site maintained by HHS. There may be penalties for the loss of unprotected information, and HHS has already started levying fines on medical providers. Here is what HHS says about encryption and breach notification:

“Protected health information (PHI) is rendered unusable, unreadable, or indecipherable to unauthorized individuals if one or more of the following applies:

1. Electronic PHI has been encrypted as specified in the HIPAA Security Rule by “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key” (45 CFR 164.304 definition of encryption) and such confidential process or key that might enable decryption has not been breached.  To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.  The encryption processes identified below have been tested by the National Institute of Standards and Technology (NIST) and judged to meet this standard.“

This is how proper key management is discussed in the HHS documentation. Note that it explicitly states that encryption keys must NOT be stored on the same device as the protected data. This is very similar to the PCI DSS requirement. The HHS documentation makes reference to NIST publications, and those publications recommend the use of FIPS 140-2 key management solutions.

It is important to note that tokenization is not mentioned by the HHS guidelines at all. Tokenization vendors will probably argue that tokenized data is not patient information, so can be used to avoid breach notification. But that is a vendor claim, and is not addressed by HHS. It should be noted that like PCI DSS, the tokenization solution must also meet the HHS guidelines for encryption and key management.

The bottom line?

The only way to avoid a breach notification is through the use of industry standard encryption such as AES, and appropriate encryption key management technologies. Encryption keys must not be stored on the same device (server) as the protected data. NIST best practices recommend that key management systems should be FIPS 140-2 certified. Our Alliance Key Manager solution meets these guidelines and will help you get to the land of HIPAA and HITECH Act Nirvana.

For more information, download our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification with NIST-Certified Data Encryption."

5 Commonly Asked Questions About Data Privacy

The job to protect sensitive data often falls in the hands of IT security administrators and their teams because of their technical expertise. We feel data protection is everyone's responsibility because every employee has an invested interest in maintaining their organization's good reputation with customers and partners.

We have compiled questions from discussions over the years with  customers and prospects to help people understand the basics of data privacy and why responsibility of maintaining data integrity goes beyond the IT department.  In addition to this list, we have produced a podcast with more information - download it here.

1. What constitutes personal information that we have to protect and how do businesses protect this information?

The first things people think of are credit card or social security numbers.  However, other pieces of information are equally as important.  Think about the things your bank asks you when you call them to talk about your account. Can you verify your phone number? The last four digits of your social security number? Your birthdate? Maiden name? These pieces of information can be used to commit fraud. 

The banks are using that information to identify you. And the fraudsters will use that information to impersonate you. The technical term for this kind of information is Personally Identifiable Information, or PII.

Businesses can protect data with a few different techniques involving third-party software solutions and implementing internal policies around who has access to data.

Vendor solutions can provide the ability to control who has access to data inside the company and prevent potential hackers from gaining access to your network.   Companies can also use vendor solutions to encrypt their data. Encryption is a process that takes sensitive information and runs it through a scrambling process. Once encrypted, your data can only be deciphered with a special key.  The data is useless to the person that attempts to steal it, unless they they have the key.

2. We’ve been hearing a lot about encryption and key management. How do they relate to each other?

They go together, they are complementary technologies. In addition to the raw credit card number, another very important input to the encryption is the secret key.  Without the key, no one can read the encrypted data. Many people think that an encryption algorithm itself is a secret mechanism, but that’s not the case. Encryption is well understood, there are standards for it and they’re readily available.  The secret that prevents malicious users from stealing data is the encryption key.

At home, the key to your front door is what protects you. Companies that use encryption have to create a key that is unique and strong, and then protect it to ensure it doesn’t get into the wild. Anyone who has the key can get the data. In the real world of protecting data with encryption, the encryption key is what users are taking care to protect.

3. What happens when the encryption is not done correctly?

There are many ways that encryption can be done incorrectly or poorly. We see that particularly around the area of encryption key management. One big mistake many people make is storing an encryption key on the same platform where the data are stored. Sometimes you hear the term integrated key management to describe this practice. Even if you lock down the database, keeping it on the same partition as your data leaves it readily accessible for potential cracking.

Other examples are using nonstandard or proprietary encryption. It’s important that a company buying encryption technology should vet their vendors carefully. NIST certified encryption is the best assurance that a solution meets your compliance requirements.

4. Are there any laws or regulations requiring businesses to protect their sensitive data?

Yes, there are quite a few, and many companies find themselves complying with multiple regulations. If you take credit cards, you fall under the Payment Card Industry standard. That’s a private regulation promoted by the credit card vendors such as Visa and Mastercard. If you’re a bank or engaged in the banking industry, you fall under Gramm-Leach-Bliley Act and FFIEC regulation for protecting data. In the health care industry, you fall under the HIPAA/HITECH acts.  FIRPA is the regulatory environment around educational institutions.

Individual states have passed data privacy regulations and defined data breaches and the penalties for them. And the federal government is moving laws through Congress to define protections for personal information. There are quite a number of regulations that define data that needs to be protected.

5. How would my organization develop a data security policy?

It’s a real challenge especially if you’re starting for the first time, it’s easy to feel overwhelmed when hearing about data breaches on a daily basis. Keep it simple to start. There are some things you can do that are very effective up front.  Rank where the vulnerabilities are. Here are just a few to help get you started:

1. Make sure you have good antivirus software on Windows and Mac.
2. Use good strong passwords. “1234” or “admin” are not good passwords!
3. Understand where your data resides and who has access to it.

Here’s another interesting thing, if you have a problem, it’s going to be your problem, not the vendor’s problem. It’s going to be your headache, your upset customers, and your financial loss. So pay attention to your encryption solution! 

Something that inhibits people from taking action is just thinking they are not subject to a data breach.  That’s a dangerous attitude. We've been saying it for years beause it's true - Data Gets Out. Encrypt it! 

Download the complete podcast here.

One clear direction I’ve observed over the last few months is the focus of QSA auditors and other security professionals on the protection of sensitive data AFTER it traverses the Internet and then lands in a database on a hard disk drive. We have really good ways of protecting data in transit using 128-bit SSL encryption. For example, the web protocols HTTPS and FTPS provide for the ability to encrypt the data in transit, and Secure Shell SSH also provides strong encryption. But after the data reaches the end point of its journey it lands on a hard drive somewhere, and it is often exposed to loss at that point. I believe that’s why security auditors are putting a lot of emphasis now on making sure that data is encrypted when it hits a hard drive.

Many companies have implemented web services in combination with the XML data standard to take advantage of low cost, real time integration with their customers and vendors. When you combine the ubiquity of the web HTTPS protocol with the W3C XML standard you get a power incentive to use this platform for business integration.
 
But care should be given to what happens to data when it leaves the realm of encrypted transit and lands on server hard drives.

Of course, the right thing to do is encrypt sensitive data before it lands on the hard drive. This means that the tools you are using have to support encryption as a natural part of the process of converting XML data. Standard XML processing tools such as Xerces and Xpath do not have built-in encryption. The same is true for XML toolkits and APIs provided by IBM, Microsoft, and others. This leaves it to developers to try to intercept data after it is transformed from XML and before it lands in a database table or on a hard drive. That’s a real challenge.

In our Alliance XML/400 web services product on the IBM platform we built encryption right into the data transformation process about four years ago. Alliance XML/400 customers can protect sensitive data by just enabling the encryption option on a translation map. The solution does the rest. The data is encrypted before insertion into the database and there is no exposure as the data lands in the database on the hard drive. Our customers are taking advantage of this feature to meet PCI and other compliance regulations.

For non-IBM System i environments we now provide an easy way to retrieve encryption keys and perform encryption in a variety of development languages such as Microsoft .NET, Java, and C/C++.

Encryption can help protect against another common threat, too. At the annual PCI SSC standards council meeting in Orlando this year, forensics expert Chris Novak of Verizon talked about how more than 75 percent of data loss events begin with a well known weakness that hasn’t been patched, and half of these are based on SQL injection attacks. With SQL injection, the attack on your servers starts with bad data inserted into a database in the clear, leaving open a later exploit. There are ways to prevent SQL injection through programming techniques, but encryption will also help defeat them.

Will encrypting your data provide all of the security protection you need? Certainly not. I like to think of it this way:  Wearing a parachute on a skydiving expedition is no guarantee that you won’t be hurt when you land.  But that doesn’t mean you wouldn’t wear one, right? I think of encryption in the same way.

To view a replay of a recent webinar we presented on XML & Web Services, click here.

Patrick