Townsend Security Data Privacy Blog

Securing data with encryption and protecting the encryption keys with proper key management is addressed in many compliance regulations and security best practices.

Let’s take a look at the Security Rule and Omnibus Rule (update to HIPAA/HITECH compliance regulations) that cover Protected Health Information (PHI) and the data security requirements that affect Drupal developers or users.  When dealing with the healthcare industry, Personally Identifiable Information (PII) is a subset of PHI, and refers to information that is uniquely identifying to a specific individual. Protected Health Information is specific to medical and health-related use and generally refers to demographic information, medical history, test and laboratory results, insurance information and other data that is collected by a healthcare professional to identify an individual and determine appropriate care. To better understand the recent changes in HIPAA/HITECH regulations, here are a few key rules that provide guidance:

The Security Rule

The Department of Health and Human Services (HHS) and the Centers for Medicare & Medicaid Services (CMS) provide guidance around the protection of sensitive data and PHI based on a security series of seven papers, each focused on a specific topic related to the Security Rule. The rule is officially titled “Security Standards for the Protection of Electronic Protected Health Information” (45 CFR Part 160 and Part 164, Subparts A and C) but is commonly known as the Security Rule.In the Security Rule standards on Technical Safeguards [164.304 as “the technology and the policy and procedures for its use that protect electronic protected health information and control access to it.”], encryption and decryption requirements regarding the transmission of health-related information are covered in sections 164.312(a)(2)(iv) and 164.312(e)(2)(ii).

HHS offers the following guidance to render Protected Health Information as unusable, unreadable, or indecipherable to unauthorized individuals:

Electronic PHI has been encrypted as specified in the 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 Omnibus Final Rule

On January 25, 2013, the Office for Civil Rights (OCR) of the U.S. Department of Health and Human Services published the Omnibus Final Rule, entitled “Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules under the Health Information Technology for Economic and Clinical Health (HITECH) Act and the Genetic Information Nondiscrimination Act (GINA); Other Modifications to the HIPAA Rules” (Omnibus Rule), 78 Fed. Reg. 5566. The Omnibus Rule was effective on March 26, 2013, with a compliance period of 180 days, requiring compliance as of September 23, 2013.

The Omnibus Rule Summary:

• Finalizes modifications to the Privacy, Security, and Enforcement Rules to implement the Health Information Technology for Economic and Clinical Health (HITECH) Act, proposed in July 2010
• Finalizes modifications to the Privacy Rule, proposed in July 2010, to increase the workability of the Privacy Rule
• Modifies the Breach Notification Rule, adopted by interim final rule in August 2009
• Finalizes modifications to the Privacy Rule to implement the Genetic Information Nondiscrimination Act of 2008 (GINA), proposed in October 2009

Within the Omnibus Rule, HHS makes it clear that certain provisions of the HIPAA Rules are now applicable to business associates. HHS has expanded the definition of “business associate” (45 C.F.R. § 160.103) to include patient safety organizations (PSOs), health information organizations (HIOs) and subcontractors. Also included as business associates are health information entities, e-prescribing gateways, other persons that provide data transmission services or facilitate access to health records, and vendors of personal health records provided on behalf of covered entities. HHS considers this subcategory to encompass data transmission services requiring routine access to PHI and services that provide personal health records access on behalf of a covered entity. Also, subcontractors (or agents) that perform services for a business associate are also considered business associates to the extent their services require access to PHI. For example, a vendor providing data storage would be considered a business associate if the data included PHI. This would require subcontractors to have HIPAA compliant business associate agreements in place and under the Omnibus Rule, business associates are now directly liable for compliance with the Security Rule. This means they must comply with the Security Rule’s requirements for (1) administrative, physical and technical safeguards; (2) policies and procedures; and (3) documentation in the same manner as covered entities. The protection of PHI falls on a wider set of requirements and more businesses and organizations will be affected by the Security Rule and Omnibus Rule for HIPPA/HITECH compliance.

“This final omnibus rule marks the most sweeping changes to the HIPAA Privacy and Security Rules since they were first implemented,” said HHS Office for Civil Rights Director Leon Rodriguez. “These changes not only greatly enhance a patient’s privacy rights and protections, but also strengthen the ability of my office to vigorously enforce the HIPAA privacy and security protections, regardless of whether the information is being held by a health plan, a health care provider, or one of their business associates.” [excerpt from 2013 HHS press release]

Another important change should be clarified around Safe Harbor. The Omnibus Rule eliminates the Safe Harbor Status, which previously protected a covered entity from a HIPAA violation based on misconduct by a business associate, now holding all parties liable. This is very different from Safe Harbor for Breach Notification that is still in effect if you encrypt sensitive data. As documented by the HHS “We encourage covered entities and business associates to take advantage of the safe harbor provision of the breach notification rule by encrypting limited data sets and other protected health information pursuant to the Guidance Specifying the Technologies and Methodologies that Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals (74 FR 42740, 42742). If protected health information is encrypted pursuant to this guidance, then no breach notification is required following an impermissible use or disclosure of the information."

To address these changes, the security experts at Townsend Security partnered with Chris Teitzel, CEO of Cellar Door Media and Drupal developer to create Key Connection for Drupal in connection with the existing Drupal Encrypt module. In order to provide secure key storage and retrieval options, Key Connection for Drupal provides a secure key management system (Alliance Key Manager) outside of the Drupal installation. Now when protected health information is collected or stored in a database it can easily be encrypted and the encryption keys properly managed. Key Connection for Drupal allows developers and users to choose whether they need to retrieve a key and encrypt/decrypt locally or to send the data to Alliance Key Manager to perform NIST validated on board encryption.

Stay tuned for our next look at data privacy compliance regulations and security best practices that impact developers and users of the Drupal CMS open source platform in regards to protection of financial and educational information. For more information about encryption and key management, download our eBook Encryption Key Management Simplified.

The updates to the HIPAA/HITECH Act Meaningful Use standards were recently released and indicate a stronger urgency by Health and Human Services (HHS) to encourage healthcare companies to encrypt sensitive patient data in order to protect that data and avoid data breach notification.

I recently sat down with Patrick Townsend, CEO & Founder of Townsend Security, to discuss what these meaningful use updates mean and how healthcare organizations should respond to the recommendations:

If you’re a healthcare organization, and you are wondering if you should be encrypting your electronic data, the straightforward answer is yes. Patient information should be encrypted at rest and in transit, and HHS will really start to bring down the hammer in terms of fines and penalties for those who have a data breach and have not encrypted data. We live in a time when a data breach is no longer a matter of “if” but “when,” and encryption is really an insurance policy to protect your organization when a data breach happens to you.

HHS still does not mandate that health care organizations encrypt sensitive patient data, but the meaningful use updates reiterate that they should encrypt their data.

The original HIPAA law and HITECH Act of 2009 did not mandate encryption of electronic patient information. However, HHS has the ability to set rules in a number of areas, and they have added stricter rules around data privacy by mandating that all data breaches must be reported to HHS. Data breach notification typically results in hefty fines and other financial losses associated with brand damage and credit monitoring for affected patients. HHS has been very clear that the only way to avoid breach notification and the impacts of a data breach, is to encrypt patient data. In these most recent updates, they reaffirmed that the only safe-harbor from breach notification is encryption.

Many organizations believe they can prevent a data breach by using strong passwords and other network security tactics such as access control lists. It's true that those actions fall within the purview of the law, but they will not help you avoid breach notification.

Another piece of the update of meaningful use concerns encryption keys. Encryption keys that are used to protect data should not be stored on the same server with encrypted patient information. HHS is trying to give better and clearer guidance on this to the best of their ability while staying within the law.

To learn more about encrypting protected health information (PHI) and achieving safe-harbor from data breach notification, download our podcast, “HIPAA/HITECH Act Breach Notification Meaningful Use Update.”

If you knew that something was going to happen to your business that would cost you not only your clients' trust but also $13 million (the average cost of a healthcare data breach), would you try to prevent that thing from happening?

According to the Ponemon Institute study, Third Annual Benchmark Study on Patient Privacy & Data Security, healthcare data breaches cost the industry $7 billion dollars annually. Unfortunately, that's not the most shocking number of the study. As it turns out, 94% of healthcare organizations have experienced at least one data breach over the past two years. Almost half of all healthcare organizations have experience at least five data breaches each over the past two years. This means that almost 100% of healthcare organizations have lost patient data such as private health information, names and addresses, credit card information, and social security numbers. If you're wondering how identity theft happens, this is it!

In a recent article published by Forbes, Rick Kam of ID Experts and Larry Ponemon of the Ponemon Institute pointed four major issues around data security in the healthcare industry:

1. Cost of a data breach: "Data breaches cost the U.S. healthcare industry nearly $7 Billion annually."

The cost to the industry includes losing patient trust, providing patients with credit monitoring services, as well as paying out hefty fines to HHS. The cost to patients often comes in the form of identity theft.

2. Electronic records: "The rise of electronic health records (EHRs) is putting patient privacy at risk."

Using computers to store and organize patient data is a blessing to most healthcare providers. However, maintaining electronic records not only causes healthcare organizations to fall under state and industry data privacy regulations, it also opens up the door to data breaches caused not only by external hackers looking to make a buck, but also employee mistakes which account for about one third of all data breaches.

3. Mobile devices and the cloud: "The rise of mobile and cloud technology threaten the security of patient data."

These days many doctors and healthcare providers use personal mobile devices to access patient data. How are these devices protected? Often they are not. Since many organizations include healthcare are now using cloud providers to store data, cloud security has also become a hot topic. How do you secure your data stored in the cloud, when it may be accessed by other users? Encryption and encryption key management is the best place to start. [Blog: 3 ways to manage encryption keys in the cloud]

4. "Little time, even less money"

Budget is one of the biggest factors that goes in an organization's data security plan. The tools needed for a comprehensive data security plan such as encryption and encryption key management may seem expensive and complicated, but the solutions out there today are in fact cost-effective and easier than ever. In the end, a company's security posture really comes down to priorities. Is preventing a multi-million dollar data breach a priority? Or will you leave it up to chance?  

Encrypting your data at rest and data in motion is the first critical step to protecting your database. Always look for NIST and FIPS certifications to ensure you are using the best encryption and key management tools available.

View our webcast “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” to learn how your organization can manage their risk of a data breach and achieve breach notification safe harbor status.

Many of my physician friends tell me how hard it is to get people to follow their health advice. They have conversations every day like this:

Doctor:  You should quit smoking.
Patient:  But I don’t want to. It’s hard. It’s uncomfortable.
Doctor:  OK. But it is going to make you sick, and you are going to wish you did.

I think I understand their frustration. Here is a conversation I have on a regular basis with Covered Entities who need to comply with the data security requirements of HIPAA and the HITECH Act:

Me:  You should really encrypt patient information (Protected Health Information, or PHI).
Covered Entity:  But I don’t want to. It’s hard. It’s confusing. I have other things to do.
Me:  OK. But it is going to really hurt when you have a data breach, and you are going to wish you did.

The Department of Health and Human Services (HHS) just released an update to it’s meaningful use policies about encrypting patient information. They took pains to say that they weren’t revising the rules, and encrypting patient data is not a mandate. But they also took pains to say that you REALLY, REALLY should be encrypting that data.

And they made one thing perfectly clear:  The only way to avoid the data breach notification requirement, and potential fines, is to encrypt the data. Even though there is no mandate to encrypt the data, you are really going to wish you did if you have a data breach. And with small and mid sized entities increasingly the target of attacks, it is a good time to address the problem.

Here are pointers to the relevant HHS guidance documents, and a plain language interpretation of what they mean:

From this web site and this document, you can read about the encryption recommendation that says (emphasis added):

“Therefore, if a covered entity chooses to encrypt protected health information to comply with the Security Rule, does so pursuant to this guidance, and subsequently discovers a breach of that encrypted information, the covered entity will not be required to provide breach notification because the information is not considered ‘‘unsecured protected health information’’ as it has been rendered unusable, unreadable, or indecipherable to unauthorized individuals. On the other hand, if a covered entity has decided to use a method other than encryption or an encryption algorithm that is not specified in this guidance to safeguard protected health information, then although that covered entity may be in compliance with the Security Rule, following a breach of this information, the covered entity would have to provide breach notification to affected individuals.”

Interpretation: You should really encrypt that data, and it is going to hurt if you don’t.

Now that we have that part clear, what kind of encryption do you need? Here is the guidance on encryption:

“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.”

Interpretation: Use industry standard encryption (AES, for example) and don’t store encryption keys on the computer with the data. If you ignore this advice, it is going to hurt.

Of course, doctors and health administrators do not write the EMR and patient management systems that they use, so what can they do? Here are three suggestions:

1. When selecting software to manage your practice (hospital, clinic, pharmacy, etc.) insist that the vendor include encryption of patient information. This must not be optional or some feature that will be added in the future.
2. When selecting software that encrypts patient information, insist that encryption keys be stored on devices designed to protect them. These should be encryption key management hardware security modules (devices) with a NIST certification to FIPS 140-2. This should not be optional or something that will be added in the future.
3. If you already have software that doesn’t do encryption, start asking your vendors why they are not protecting you from a data breach. Ask them if they will pay the fines and costs of a breach. Ask for a date certain when they will provide the level of data protection that you need.

Patrick

Learn more about 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".

At Townsend Security we get all kinds of questions about PCI Compliance. A question we get asked frequently by healthcare professionals is:

As a medical healthcare provider, we accept payments via check or credit card through Point of Sale devices implemented by a third-party vendor. Are we responsible to comply with PCI DSS requirements?

Many people assume that if they use a third-party vendor, the vendor must be the one to comply with PCI DSS. Our CEO Patrick Townsend, has a different take on this subject. I asked Patrick if he could answer some of the common questions asked by healthcare providers concerned about PCI DSS compliance requirements.

Are we (healthcare providers) responsible for complying with PCI DSS?

Yes, every Merchant is responsible for PCI DSS compliance even if using an outsourced service. However, this type of arrangement can greatly reduce the amount of work that the Merchant has to do. Usually you will only need to complete and sign a Self Assessment Questionnaire (SAQ). You would get this from your outsourced authorization provider.

Okay, but if we do need to be concerned with PCI compliance, how is the PCI DSS processed managed?  Does the IT team tackle this? Our compliance team?

Typically the IT department takes the lead on coordinating any work that has to be done for PCI DSS. This might include things such as a vulnerability scan by an approved scan provider and similar types of tasks. An officer or director then reviews and signs the SAQ and letter. In medical organizations the Compliance Officer is typically more involved with various medical industry compliance requirements related to HIPAA and so forth and usually not involved with PCI DSS. But it never hurts to ask.

What about banks that process our clients’ credit card information?  What kind of reporting should we be getting from our bank confirming that they are compliant or following PCI DSS compliance?

Banks are under a different type of compliance requirement for PCI. You should just ask them for a letter assuring you that they meet all PCI data security requirements as an authorization provider.

Sometimes PCI compliance can be confusing. Hopefully, thanks to Patrick, you may now have a better understanding of PCI compliance and how you can outsource credit card information while remaining PCI DSS compliant. If you have questions about PCI compliance, send me an email at kristie.edwards@townsendsecurity.

If you want to learn more about PCI compliance and how Townsend Security can assist with the process, listen to Patrick speak about current best practices and encryption key management in the webinar, “Key Management Best Practices: What New PCI Regulations Say.”

We have recently seen the medical community step up their level of concern regarding protecting Protected Health Information (PHI).  Aside from just “doing the right thing” there are business reasons attached.  Data breaches are now a regular occurrence and have serious dollars connected to them.  Did you know that data breaches in the healthcare industry have increased 32% in the past year and cost an estimated $6.5 billion annually?  Additionally, breaches aren’t just a result of hackers.  Forty-one percent of healthcare executives attribute data breaches to employee mistakes.  Luckily, there is a safe harbor for breach notification – proper encryption and key management.

We recently held a webinar titled “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” and received some excellent questions that we would like to share with our blog readers around encryption, key management, and breach notification.

What does the Department of Health and Human Services (HHS) have to say about Encryption and Key Management?

The Department of Health and Human Services (HHS) points to the National Institute of Standards and Technology (NIST) for encryption and key management best practices.  When an organization has a breach, and their encryption and key management isn’t based on industry standards such as those defined by NIST, you can bet they are going to be responsible for a breach notification – averaging $214 per record or $7.2 million per breach.

So when NIST says “This is what we suggest you do,” companies are taking note.  WHEN there is a breach – not IF there is a breach – HHS is going to ask how you were encrypting your data.  Was your encryption based on standards? How were you managing your encryption keys?  Was your encryption a homegrown or proprietary solution? 

NIST suggests using Advanced Encryption Standards (AES) for encrypting data at rest and pairing it with a proper key management as you would find in our  Alliance Key Manager HSM.  With NIST certified encryption and key management, you are provably meeting standards and best practices, and in turn, HHS is more likely to say you are exempt from a breach notification.

We are a medical software vendor.  Are we required to encrypt PHI in our solution?

Software vendors and medical equipment vendors have no mandate requiring them to protect the data, but it is a strong recommendation.  Keep in mind that both end customers and their patients are expecting their data to be protected the right way and they don’t want to find themselves subject to breach notifications.  Implementing proper encryption and key management has become even more important for software vendors as it is becoming a competitive issue.  We are seeing our partners finding success because there are still gaps in terms of who is offering this kind of protection – though everyone should be.  

The other thing to think about, and HHS is quite clear on this issue, is they really want vendors of medical solutions to offer encryption.  Although it is not a mandate yet, companies that currently have solutions in the medical segments should be prepared for encryption and key management to become a requirement in the future.  As we have seen before, things that are strong recommendations today often end up as mandates tomorrow. 

View our webcast “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” to learn how your organization can manage their risk of a data breach and achieve breach notification safe harbor status.

The Healthcare industry is still struggling to come to terms with the new HIPAA/HITECH requirements to protect patient health information. There are now clear requirements to protect patient information (called Protected Health Information, or PHI) from loss, and data breach notification is now mandatory, but CIOs in the medical segment have not yet developed pro-active attack plans to secure their data, and are caught by surprise when they experience a data breach - something that is happening at an alarming rate.

Why is this?

I think we can understand this by looking back at the history of the Payment Card Industry rollout of data security standards about 8 years ago. In the early days of PCI DSS compliance, many companies also took a reactive stance regarding the regulations. I heard CIOs say that they thought their data was already safe, that their IT staff assured them that everything was OK, and even that they would only do something if they had a loss and were forced to make changes. I even heard “I’ll pay the fine and do the time if I get caught.”

It took a number of years before CIOs and their executive teams who fell under PCI DSS to come to understand the real impacts of data breaches and developed a pro-active stance around data protection. Companies came to realize that data breach costs went far beyond the initial fines for non-compliance. There are litigation costs, costs for notifications, new external audit requirements that extended years into the future, opportunity costs while valuable staff focused on fixing the problem and not enhancing the business, and a loss of confidence by their customers and partners. Additonally, breaches can create a public relations nightmare for your company and possible long-term damage to the brand. All of these have real impacts on the bottom line.

When companies in the payment industry fully grasped the impacts of a data breach, they went to work pro-actively to protect sensitive data.

The Healthcare industry is not there yet.

What can a CIO do to change their organization’s posture on protecting PHI? Here are some things to start on:

• Educate senior management on the real costs of a data breach. (This is probably the most important first step - everyone has to buy into the need and the plan).
• Involve your IT professionals in creating an inventory of PHI every place it resides in your organization.
• Identify everywhere in your IT systems where you receive PHI from outside sources, and where you send PHI to outside sources.
• Create a plan to encrypt PHI and protect the encryption keys.
• Prioritize your projects. There will be low hanging fruit – places where putting encryption in place is relatively fast and painless.
• Focus on execution. “Are we there yet?”

I know that the Healthcare industry will eventually get to the right posture on data protection. It will take some time before the realities are well known. But as I talk to CIOs at companies who have experienced a data breach, I know that they get it. Hopefully, these painful lessons will seep into the larger industry sooner rather than later, and you won’t be that CIO who wakes up one morning to the unpleasant surprise of a data breach.

Patrick

View our webcast “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” to learn how your organization can manage their risk of a data breach and achieve breach notification safe harbor status.

In a highly digitized environment, identity theft poses a great risk if the necessary safeguards are not utilized. It is paramount that businesses and consumers are made aware of the massive repercussions a data breach of patient info can result in--such as identity theft of patients, as well as financial damage to and reputation loss of healthcare organizations. Current HIPAA regulations mandate that if a data breach occurs, then the organization responsible for that breach must reported it to Health and Human Services (HHS), pay thousands or millions of dollars in fines, and may have to report the breach to the media.  However, if your organization’s data is securely encrypted, you will be exempt from these repercussions.

Despite Health Insurance Portability and Accountability Act (HIPAA) security laws, healthcare data breaches are on the rise. According to the Ponemon Institute, the healthcare industry has lost more than $6.5 billion dollars due to data breaches.

Ponemon also identifies the three most common culprits of healthcare data breaches: stolen or lost equipment, third-party mistakes, and employee errors, indicating that many data breaches stem from unintentional mistakes. Storing health information on mobile devices is also a common practice among health care organizations. However, 49% of the respondents reportedly do not take any steps to secure patients' information on those devices.

A great example of an accidental data breach recently took place in South Carolina where a Medicaid employee transferred several spreadsheets of sensitive patient data to a personal email account. This kind of data breach could have exposed hundreds of thousands of patients to possible theft of Social Security numbers, Medicaid ID numbers, addresses, phone numbers, and birthdates.

Another alarming example took place at an Emory Healthcare storage facility where 10 back-up disks for an old computer were found missing. These disks contained protected health information (PHI) of more than 300,000 patients including patients' names, doctors' names, diagnoses, medical procedures and other privileged information protected under HIPAA.

As healthcare organizations face greater challenges in protecting massive amounts of patient data, the US federal government continues to strengthen security laws, regulations, and best practices. Due to the HITECH act of 2009, HIPAA compliances now requires more stringent steps to ensure full security of patient information.

As the CTO, IT Manger or System Administrator of your healthcare company, you have a critical task to accomplish. You cannot afford to waste time and money on legal battles that you can avoid in the first place. If you do experience a data breach, the emotional toll on your patients could result in lost clients and a tarnished company image.

Here is the good news: NIST-certified encryption and FIPS 140-2 certified encryption key management is at your fingertips!  Townsend Security’s encryption solutions offer affordable possibilities that will fully protect your patients' records and allow you to avoid a breach notification in accordance with HIPAA/HITECH. You need a security technology with a strong encryption solution that is NIST certified and suitable to your server environment. If data is securely encrypted, data breaches don’t need to be reported and you and your patients are assured peace of mind.

For more information, download our podcast "Protect PHI and Manage Risk - HIPAA Compliance" and learn more about achieving Safe-Harbor status in the event of a breach and what is considered a data breach.  Additionally, learn what to be aware of when selecting an encryption or key management solution.