As we move closer to the finalized rules for HITECH data protection, some things are now becoming very clear.  The government wants ISVs and service providers to offer encryption of data at rest to their customers, and they want covered entities to use it!  While a careful read of the regulations reveals that they do not mandate encryption, the guidance makes clear that encryption is the ONLY safe harbor from breach notification.  Your customers will interpret this as a mandate, and will start demanding encryption in your products and service solutions.  We are already starting to see this happen.

Healthcare ISVs face some really big challenges as they start to move into the unfamiliar territory of encryption and key management.  Here are four critical issues you will face as you start down the path to securing your data at rest with strong encryption:

1)    The Big Challenge is Encryption Key Management

Encryption itself is not really the biggest technical challenge facing ISVs as they start to encrypt data in their application databases.  Most operating systems, databases, and programming languages offer encryption libraries that you can use right off the shelf.  For example, Microsoft provides encryption libraries in SQL server and the .NET language.  Oracle offers similar support for encryption in their database.  The really big challenge is encryption key management.  Encryption keys are the secrets that must be protected.  Key management systems create, store, and protect keys from loss, and this will be the hardest thing to get right.

2)    NIST & FIPS Certification

The HITECH guidance is full of references to the National Institute of standards and Technology (NIST) for encryption standards and best practices.  Advanced Encryption standard (AES) is the recommended technology for encryption.  And the NIST recommendations for key management are the gold standard for key management solutions.  Serious key management vendors submit their solutions to NIST for certification under the FIPS 140 protocol, and these vendors are easy to locate on the NIST web site.

3)    Getting Encryption and Key Management Right

You will be tempted to push the responsibility for encryption and key management to an outside vendor.  If it is really hard to do, why not let someone else do the job? You can refer your customers to the vendor for the solution, and the vendor can do the work of getting the database encrypted.  It seems easy.  Until you discover that your customers are not going to distinguish between your vendor and you when problems happen!  You will be ultimately responsible for any problems with data protection.

4)    The Right Partnership

Many ISVs discover that finding the right partner for encryption key management solutions is the biggest hidden challenge in their projects. Not only is the technology very specialized, there are a small number of vendors who offer FIPS 140 certified solutions.  You have to offer solutions to your customers that are easy to deploy and meet your product pricing objectives.  What if you need a customized key management solution?  Are there any vendors who are willing to help you with these requirements?  Finding the right partner is as important as finding the right technology.

Visit our ISV Partner Program page for more information on becoming a partner or download our white paper titled Healthcare ISVs: Critical Issues in Meeting HITECH Data Protection Regulations.

The recent news of SAIC being dinged for not protecting US military TRICARE medical information with standard AES encryption and suffering a data loss is interesting. While the details are still thin, it appears that the data was encrypted, but not with a standard AES encryption method. The HITECH Act proposed data security rules make specific reference to AES and other NIST standards.

We don’t know which encryption method was used to protect the data. It could have been a home grown method of encryption, or it may have been a widely accepted encryption method that was just not a part of NIST standards. But it apparently doesn’t matter. If you are not using a NIST standard method of encryption, you are in violation of the compliance requirements.

I think it is going to take some time for the implications of this to settle in. Here are some rather unorganized thoughts:

Over the last two years I’ve seen at least FOUR instances of vendor “AES” encryption solutions that actually weren’t AES encryption. In one case, a point-of-sale vendor implemented an AES encryption library with a 256-bit AES block size. The AES standard (FIPS-197) only allows the use of a 128-bit block size.  The company running this software had no idea that they weren’t actually running an industry standard method of encryption.

In another case a customer was running AES encryption with a non-approved mode of encryption. The underlying encryption library was AES, but the mode was not a NIST-approved mode of operation. This was a distinction lost on the company running this “AES” solution. But it seems likely to me that they were out of compliance and at risk in the same way SAIC was. This company is going to have to rip out the current solution and replace it with something that is actually compliant. That seems like such a waste of time and resources.

In one of these cases the software was provided by a “security” vendor. This vendor sells encryption and key management software specifically to meet encryption compliance regulations. That’s very sad.

With the best of intentions and with deep knowledge of encryption protocols, you can still make mistakes when developing an encryption solution. It is hard to get this right. And weak vendors without the commitment and passion to get it right represent a risk to everyone. So, if you are a vendor of encryption solutions, what do you do to insure that you are getting things right? You learn to not trust yourself so much, you invest in independent review of your solutions, and you invest in independent certification. Today we would never release an encryption product without subjecting it to NIST certification and independent review.

If you are a company facing an encryption project, how will you select a security vendor for your encryption libraries and encryption key management solution? How will you know that their AES encryption is really based on the NIST standard? Are you ready to trust the claims of a sales person? I wouldn’t, and I don’t think you should, either. If a security vendor can’t show you a formal NIST AES Validation certificate, or a FIPS-140-2 certification, you should run for the nearest exit. You just have way too much to lose.

If you think that the HITECH Act is unique in its reference to NIST standards, have a look at the proposed Federal Privacy Law (Senate Bill 1151) that passed out of the Senate Judiciary committee last week. It is likely to empower the FTC to propose standards for encryption and encryption key management, and the FTC is likely to look to NIST for these standards.

The writing is on the wall, or rather, it’s on the Internet at www.nist.gov.

Learn more about proper encryption and key management best practices for HIPAA and HITECH Act in our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification".

Patrick

In part one of "HIPAA, HITECH Act, & Encryption Key Management" I sat down with Patrick Townsend, Founder & CTO, to discuss discuss the increased focus on HIPAA and the HITECH Act and the different types of encryption an organization could use to satisfy these requirements.  In part two, Patrick speaks on the benefits of encryption to organization in the health care industry, what the Department of Health and Human Services has to say, and finally how Townsend Security can help meet HIPAA and HITECH requirements for encryption and encryption key management.  Here is the second part of our conversation:

Download Podcast Now

Besides protecting patient information, does encryption provide any other benefits to the medical provider?

Yes, there is one particularly big benefit to anybody who is a covered entity, and that has to do with breach notification.  There is a breach notification requirement for anybody who loses patient data or thinks that patient data has been stolen from their system.  If you read the rules, there is no place where it says you must encrypt patient data – BUT- there is a section that says, if you have a breach, and if you have encrypted your data properly, there is a safe harbor from breach notification.  In other words, you don’t have to go through the expensive process of remediating the breach. 

So, there is a very, very positive practical benefit to any covered entity from using encryption, which is, if you have a breach, then that encryption will give you a safe harbor, or a way out from some of the more painful parts of breach notification.  Under breach notification, that information becomes public.  There can be fines levied around the loss of data.  Additionally, you must provide assistance to the patients whose information has been breached, which can be quite expensive.  In the credit card world, we know that the typical cost of remediating a breach is $214 per record, and now the average cost to an organization for having a breach is around $7 million.  So, the use of encryption and proper key management does have a very practical benefit to the covered entity itself in helping them avoid the more difficult and expensive costs of a breach notification.

What does the Department of Health and Human Services have to say about encryption key management?

Again, reading the rules, you will find references to NIST standards and best practices around key management.  It takes a lot of drilling down into the NIST best practices documents to really understand key management, but the information is there.  If I could boil it down to one really important concept, it is that managing encryption keys is the most important part of your strategy.  Protecting the keys is really what you do to protect the data.  So, implementing good key management is a core principle.  If you read the NIST standards, they talk about separation of duties, dual control, and split knowledge.  These are all concepts that have very real world implementations.

Dual control just says that when you are managing keys, you should have two people who must authenticate to manage encryption keys.  It makes sense if you want to avoid the potential for collusion around key management.  Separation of duties means that the people who manage data, or patient information, should NOT be the people who manage encryption keys.

These are the kind of concepts that auditors and others look for in a key management strategy.  In the real world, key management systems are very specialized appliances.  We are a vendor of general-purpose encryption key management solutions that implement these kinds of standards.  This is really how HIPAA and the HITECH Act approach the question about encryption key management.  Again, if you read the IFR’s, which become finalized later this year, they say to use encryption key management that is based on standards, such as NIST.

As a company that provides encryption and key management solutions, can you tell our listeners how these solutions can help them meet HIPAA and HITECH Act requirements? 

Traditionally, encryption key management has been the more difficult part of an encryption strategy, which we are now making easy.  It can be the most expensive part and most difficult to implement.  I think we have done a great job of creating affordable and cost-effective key management solutions, which are FIPS 140-2 certified and work well in a variety of environments across a lot of platforms.  So, the first thing that we have done that’s really beneficial in the medical segment, is creating an encryption key management solution that is affordable to customers and that works well with partners who distribute solutions in the medical environment.  Our encryption key management solutions really help drive down the cost of doing encryption the right way.  Again, the NIST certification on the key manager is important to provably meet the standards called out by the HITECH Act and the rules that they have been promoting.

Secondly, we do provide encryption libraries for customers who need them, so if you need to do AES encryption, for example, which is a NIST standard, we have encryption libraries that are very cost-effective, highly tuned for performance, and will work well in small and large organizations within the medical segment.

Lastly, we have some solutions around secure transfer of data, including PGP encryption and secure transport of data using SSL/TLS technologies.  Again, these match well with HIPAA and HITECH Act requirements for encrypting data.  I think this broad set of key management and encryption capabilities really help our partners and our customers meet these requirements.

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

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