Townsend Security Data Privacy Blog

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 requires that medical providers, called Covered Entities, implement data security to protect patient information from disclosure. Sensitive patient data is termed “electronic protected health information”, or ePHI, and includes information like patient names, addresses, social security numbers, procedure codes, birth dates, and much more. All Covered Entities, which is almost everyone in the healthcare system, must implement these data security controls. As a matter of law, a Covered Entity that fails to protect patient information and suffers a loss or exposure of that information must make a formal data breach report to the US Department of Health and Human Services.

Because many of the losses of patient data happened not by Covered Entities, but by vendors and service organizations they hire, the regulations were amended to cover Business Associates. Any Covered Entity that shares patient information with an outside organization must now have a Business Associate agreement with them that binds them to the same patient data protections that HIPAA requires of Covered Entities. This plugged a hole in the original HIPAA law that resulted in patient data loss through outside vendors. Everyone who handles ePHI, inside or outside the medical industry, is now obligated to implement the HIPAA data security rules.

So, to the basic question: Do I have to encrypt patient information?

The answer is Yes, but the rule allows for some exceptions. Let’s examine this more closely, because those exceptions get a lot of Covered Entities into trouble.

The HIPAA regulation requires the encryption of patient information when stored on disk, on tape, on USB drives, and on any non-volatile storage. This is called encryption of data at rest. The HIPAA regulation also requires the encryption of data as it moves across a network via a web browser session, FTP or any other method used to transfer data. This is called encryption of data in motion.

The relevant regulations which say you have to encrypt ePHI are these:

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

45 CFR 164.312(e)(2)(ii)

The regulations are simple and very easy to read. I suggest that you take a quick look. Just a few sentences define the requirement.

Notice that there is no mention of laptops, backup tapes, USB thumb drives, tablets, phones, or anything else in the regulation. If it is “electronic protected health information”, or ePHI, it must be protected.

Now we have to take a little side trip. Notice that this security control is “addressable”. What does that mean? Here is the formal definition for an addressable control.

So now you know that there is not a hard mandate to encrypt patient data if you can document that there is a reason you can’t do it, AND if you have an alternative that is equivalent to encryption. You might argue, for example, that it is expensive to do encryption. Or that it is really, really hard to do encryption. Those may actually be valid arguments. If you make that argument you have to document your reasons, and you have to provide a reasonable, appropriate, and equivalent alternative to encryption.

Notice those words “reasonable”, “appropriate”, and “equivalent”. Those are the words that are likely to get you into a lot of trouble. If you decide not to use encryption, you are committing to using something that is an equivalent method of protection, and you are committing to documenting your reasons.

Covered Entities put themselves at risk when they decide to use addressable controls for encryption. Those include:

• Failing to document the reasons why encryption can’t be used.
• Failing to document the particular hardship that encryption entails.
• Failing to implement a reasonable alternative to encryption.
• Failing to implement an equivalent method of protection.

When a Covered Entity experiences a data breach, the fact that data was not encrypted and the fact that the alternative method did not prevent the data breach, will put you at direct risk for a compliance action. It will be hard to argue that you’ve used a protection method that is equivalent to encryption when you’ve actually lost the patient data! It is going to be hard to win that argument.

If you review a number of the Corrective Action Plans (CAPs) for data breaches you will find that there are often a number of failures involved in the data breach besides the loss of unencrypted ePHI. Improper documentation and inadequate staff training are almost always involved when OCR issues a fine and CAP over a loss of patient data. But the failure to encrypt ePHI is always involved.

Now we are back full circle to our question: Do I have to encrypt patient information?

I think you can see now that the answer is "Yes". You need to encrypt patient data in order to provide adequate protection to your patients AND to your organization as a whole. It’s the only defensible strategy in light of how HIPAA, HHS, and OCR will evaluate your data breach.

We work with a number of Covered Entities around data protection and the implementation of encryption. I know that almost all Covered Entities have gaps in their implementation of encryption. Here are a few things you can do right now to start to address these:

• Make an inventory of all of the systems that store or transmit patient data.
• Identify all of the systems where encryption is not implemented.
• Prioritize the implementation of encryption for all of these systems. In many cases this will mean working with a software or hardware vendor.
• If vendor updates are available that add encryption capabilities, schedule those updates as soon as possible.
• Immediately notify all of your software and hardware vendors that you expect them to implement encryption according to industry standards, and that future acquisitions will require this security control.
• Remember that a proper implementation of encryption involves protecting encryption keys from loss. Be sure that encryption keys are stored away from patient data on key management servers that are designed to protect encryption keys.
• Make an inventory of all Business Associates that receive patient data from you and be sure you have a signed Business Associate agreement on file.

Encryption is far easier to implement now that at any time in the past. Covered Entities have lots of options and don’t have to be at risk of a compliance action.

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.

Two Factor Authentication (2FA) and a look at the compliance regulations that require identity verification for remote access.

The use of two factor authentication provides an added layer of security beyond just a username and password. Because passwords can be guessed, stolen, hacked, or given away, they are a weak layer of security if used alone. Since frequent access happens from outside of the network, remote login is considered high-risk and requires additional steps to confirm user identity. Protecting access with two factor authentication adds identity assurance and significantly reduces risk of unauthorized access in the retail, healthcare, and financial industries.

Payment Card Industry Data Security Standards (PCI DSS)

The PCI Security Standards Council has stated that they will continue to change and evolve compliance regulations over time as attacks change. In PCI DSS section 8.3 the requirement states that organizations must “incorporate two factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.”  The objective of this requirement is to ensure that merchants implement strong access control measures so that authorized individuals with network and computer access can be identified, monitored, and traced.

Requirement 8: Assign a unique ID to each person with computer access. Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data.

Requirement 8.3: Incorporate two factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.

Note: Two factor authentication requires that two of the three authentication methods (something you know - something you have - something you are) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two factor authentication.

Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health (HITECH) Act

HIPAA was an act signed in 1996 by President Bill Clinton, meant to improve the efficiency of the healthcare system by encouraging the use of Electronic Data Interchange (EDI) when accessing Protected Health Information (PHI). Covered entities must develop and implement policies and procedures for authorizing PHI access in accordance with the HIPAA Security Rule Administrative Safeguards 164.308(a)(4) [Information Access Management: Access Authorization] and Technical Safeguards 164.312(d) [Person or Entity Authentication] and the HIPAA Privacy Rule at §164.508 [Uses and disclosures for which an authorization is required].

The HIPAA Security Rule requirements have most recently been expanded via the HITECH Act, which establishes mandatory federal security breach reporting requirements with expanded criminal and civil penalties for non-compliance. To remain HIPAA compliant and avoid fines for HITECH Act non-compliance, strict control over access to patient records must be demonstrated.

HIPAA/HITECH requirements regarding the transmission of health-related information include adequate encryption [164.312(e)(2)(ii) when appropriate, and 164.312(a)(2)(iv)], authentication [164.312(d)] or unique user identification [164.312(a)(2)(i)] of communication partners. By selecting Two Factor Authentication (2FA), users would be required to combine something they know, something they have, or something they are; thereby providing more secure access to PHI files. Protected Health Information can be account numbers, medical record numbers and geographic indicators among other private consumer information. It is important that only those health care workforce members who have been trained and have proper authorization are granted access to PHI.

Gramm-Leach-Bliley Act (GLBA) & Federal Financial Institutions Examination Council (FFIEC)

The Federal Financial Institutions Examination Council (FFIEC) is charged with providing specific guidelines for evaluating financial institutions for GLBA (Gramm-Leach-Bliley Act) regulations compliance. The FFIEC also provides guidance around the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against financial fraud with the document, “Authentication in an Internet Banking Environment” (v.3). For banks offering internet-based financial services, the guidance document describes enhanced authentication methods that regulators expect banks to use when authenticating the identity of customers using online products and services, as follows:

• Financial institutions offering internet-based products and services to their customers should use effective methods to authenticate the identity of customers using those products and services. Furthermore, the FFIEC considers single-factor authentication (as the only control mechanism) to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties.
• The implementation of appropriate authentication methodologies should start with an assessment of the risk posed by the institutions’ Internet banking systems. The authentication techniques employed by the financial institution should be appropriate to the risks associated with those products and services.
• Account fraud and identity theft are frequently the result of single-factor (e.g. ID/password) authentication exploitation.
• Where risk assessments indicate that the use of single factor authentication is inadequate, financial institutions should implement multi-factor authentication, layered security, or other controls reasonably calculated to mitigate those risks.

The FFIEC is a government agency which works with many other government agencies to unify how financial institutions should be supervised. The guideline documents recommend banks treat the FFIEC as baseline compliance for safe online authentication and transaction verification. Since all single factor authentication techniques can be easily compromised, financial institutions should not rely solely on any single control for authorizing high risk transactions, but rather institute a system of layered security with multi-factor authentication.

Although there are varying levels of enforcement, guidelines vs. laws vs. fines, it is clear that two factor authentication plays a critical security role in both compliance and following best practices. This trend will only grow within various industries and throughout the overall data security environment.

Townsend Security offers Easy to Deploy, Cost Effective Two Factor Authentication Solution for the IBM i Platform

Alliance Two Factor Authentication brings mobile SMS and voice verification to the IBM i platform. The solution was built to solve large scale problems in a cost-effective manner and appropriately addresses the concerns raised in the various guidelines and standards listed above. Remote access to networks containing critical payment, patient information, or financial records can be protected with the Alliance 2FA solution using your mobile phone to receive authentication codes.

For more information, request our 2FA Resource Kit! 

Secure system logging on the IBM i (AS/400) can not only help you meet compliance requirements, it can help you stop a data breach before it happens!  Intruders may start with a password hack that gives them access deeper into the system.  There is usually a long trail, visible within system logs. Everything from the original breach can be detected and identified with proper monitoring of the system logs.  What really is driving the need to collect and monitor system logs centers around how often breaches are easily detected with log management.  For example:

• Less than 1% of the breaches were discovered through active log analysis
• Forensics showed 69% of these breaches were detectable via log evidence

PCI Section 10 requires logging for anyone who collects credit card data

Requirement 10:  
 “Track and monitor all access to network resources and cardholder data”

• 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
• 10.2 Implement automated audit trails for all system components to reconstruct the following events:
• 10.3 Record at least the following audit trail entries for all system components for each event:
• 10.4 Using time-synchronization technology, synchronize all critical system clocks and times
• 10.5 Secure audit trails so they cannot be altered.
• 10.6 Review logs for all system components at least daily.
• 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.

GLBA / FFIEC recommends data security logs of actions that could affect financial reporting or fraud for financial institutions.

• Network and host activities typically are recorded on the host and sent across the network to a central logging facility.
• The logging facility may process the logging data into a common format. That process is called normalization. Normalized data frequently enables timely and effective log analysis.

(This Link provides more information about FFIEC recommendations for logging)

HIPAA / HITECH ACT requires system logs of access to Protected Health Information (PHI) in the medical sector

• LOG-IN MONITORING (A) - § 164.308(a)(5)(ii)©

…the covered entity must implement: “Procedures for monitoring log-in attempts and reporting discrepancies.”

• Access controls - § 164.312(b)

(section b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI.

There are other compliance regulations and protocols that apply, but they all say about the same thing … you should be collecting system logs, you should be monitoring them, and you should take action based on anomalies that you find in them.  It is not enough to assert that you are doing the right thing; you have to be able to prove it with system logs that are independent from the original system files and verifiable.

System logging is important across all operating systems, but we are going to look at IBM i with greater detail due to it’s complexity.  Because the IBM i system can handle multiple applications, it doesn’t log information like others do.  The IBM i collects logs simultaneously from multiple sources and deal with large volumes: Up to 3,500 events per second…250 Million of events per day!  The essence of good reporting is externalizing the systems logs and collecting them in a central repository which helps remove the risk of tampering. Compliance regulations recognize the need to watch all users – including the most powerful users, because network originated threats to the IBM i are often not noticed or quickly responded to by IT security professionals without close monitoring of system logs.

Creating the QAUDJRN (Security Audit Journal) on the IBM i

QAUDJRN is not created or enabled by default on the IBM i platform.  If you have not set it up, you are not yet collecting system logs.  To implement system logging you create the journal and journal receiver, then set system values that control options about what information is collected. Once the values are set, the collection process begins.  QAUDJRN is non-modifiable and date-stamped and a large amount of useful information can be collected in each event.  However just running system log reports on the security audit journal are not enough. Centralizing events and monitoring them off the IBM i platform are crucial. The events need to be consolidated and correlated in a separate location (usually a SIEM Console) in order to see the whole picture and understand potential attacks on your system.  

Take Away:
If you are properly collecting and monitoring your system logs, you can detect a breach before data is lost.

To delve deeper into this topic, we are sharing this newly recorded webinar in which, security expert Patrick Townsend talks about system logging on the IBM i today and how the capabilities of Alliance LogAgent can provide you with a high performance, affordable solution that will communicate system logs securely between your IBM i and Security Information and Event Management (SIEM) Console.

As always, we welcome your questions and comments posted here!

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".

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.

Many people we talk to are gambling with $7.2 million whether they realize it or not.  This week we are at HIMSS12 in Las Vegas meeting members of the IT medical community – an appropriate venue for such high-stakes gambling.  How are these people gambling with so much money?  The average cost of a data breach is $214 per record, or $7.2 million for an organization.  This figure is determined not only by direct costs of a data breach, such as notification and legal defense costs that impact the bottom line for companies, but also indirect costs like lost customer business due to abnormal churn.

Is there a way to make sure you aren’t putting your organization in such risk?  The HITECH Act, the compliance regulation that the medical community is concerned with, says that 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.  Other compliance regulations (such as PCI DSS) go as far as REQUIRING protecting Personally Identifiable Information (PII) with encryption and key management – not just to receive a breach notification exemption.

Becoming compliant with these regulations doesn’t have to be hard (though it can be).  Townsend Security has made it easy (saving your organization time and money) with NIST-certified AES encryption for all the major enterprise platforms, as well as a FIPS 140-2 certified encryption key management hardware security module (HSM).  For those organizations who are already encrypting but need key management, our encryption key manager can easily work with your existing database (SQL, Oracle, DB2, etc.) to help meet compliance requirements that call for separation of duties and dual control.

If you aren’t familiar with NIST and FIPS 140-2 certifications, the National Institute of Standards and Technology (NIST) provides them to encryption and key management solutions after they undergo a rigorous testing process.  The testing is carried out by independent testing labs who then report the results directly to NIST for validation.  Only the most dedicated security vendors are able to pass the tests and achieve NIST and FIPS 140-2 certifications.  Not only are these certifications essential for meeting compliance regulations, but they provide you an ease of mind that a third-party has verified the integrity of the product.

So are you gambling with $7.2 million?  If you aren’t protecting your PII with encryption and key management you might be.  Take the first step for help and call our gambling hotline (800-357-1019) or send us an email.  We’d be glad to help you step away from the table.

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".

Are you an ISV?  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.

Anyone who works with software applications in the medical segment is painfully aware of the complexity of patient information.  You mix a lot of personal information about patients, their family, their care givers, diagnostic information, pharmaceuticals, and insurance providers together, and you get a witches brew of data that would make your head spin.

Mix in a rapidly changing regulatory environment and you’ve really got a headache!

Medical organizations and application vendors have a lot on their plates keeping up with all of this, and now with new Electronic Medical Record (EMR) requirements coming into effect, they have to become experts in encryption technologies to protect patient information.

The lights are blinking red; system overload!

We’ve been helping medical organizations meet their data protection requirements with our encryption and key management solutions for several years. Our commitment to industry certifications such as FIPS 140-2 fits well with HIPAA and HITECH Act guidelines on data protection. When you read about NIST recommendations for encryption and key management best practices, we are already there.

Software ISVs who serve the medical industry also need partner-friendly solutions. ISVs need more than just a technical solution. They need someone they can call on to explain data protect best practices, who can assist in the implementation of encryption and key management, and who can help them stay competitive in their markets. The last thing an ISV needs is to integrate some expensive technology into their solutions and then find themselves at a competitive disadvantage. I am proud of our partner program and its focus on making sure our partners are successful both in their technology initiatives, and in their businesses, too.

This will be our first year at the HIMSS conference in Las Vegas, but we are bringing a lot of experience in the medical segment to the show.  I hope you find the show interesting and helpful, and that you come by our booth (#14124).