Townsend Security Data Privacy Blog

Webinar: Protecting PHI and Managing Risk - HIPAA Compliance View our Webinar "Protecting PHI and Managing Risk - HIPAA Compliance" Click Here to View Webinar Now

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.

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 establishes and governs national standards for electronic health care transactions.  According to the website of the U.S. Department of Health and Human Services: 

The HIPAA Privacy Rule provides federal protections for personal health information held by covered entities and gives patients an array of rights with respect to that information.... The Security Rule specifies a series of administrative, physical, and technical safeguards for covered entities to use to assure the confidentiality, integrity, and availability of electronic protected health information.  www.hhs.gov

The protections under HIPAA have been expanded by the Health Information Technology for Economic and Clinical Health Act (HITECH).  Again, according to the Department of Health and Human Services:

HITECH requires healthcare organizations to take more responsibility for protecting  patient records and health information. The Act widens the scope of privacy and security protections available under HIPAA, increases potential legal liability for non-compliance and provides more enforcement of HIPAA rules. The HITECH Act seeks to streamline healthcare and reduce costs through the use of health information technology, including the adoption of electronic health records.

HITECH defines a data breach of protected health information (PHI) as any unauthorized use, access or disclosure of PHI that violates the HIPAA Privacy Rule and poses significant financial, reputational or other harmful risks to an individual.

Should SMBs be concerned about a data breach of PHI?  A recent study found that only 5 percent of data breaches are caused by malicious cyber attacks, while almost 55 percent are linked to human error. 

To determine whether a PHI data breach has occurred, HHS looks at various factors, some within your control, some not.  A key question the Department will ask in the event of a data breach is:  Was the PHI safeguarded by encryption?

What level of HIPAA encryption is recommended?  What are the HIPAA encryption best practices?  The key, as the Practice Management Center of the American Medical Association points out, is to "...render electronic personal health information (ePHI) unusable, unreadable or indecipherable to unauthorized individuals...".  If you follow the specific technologies/methodologies prescribed, you increase the likelihood of being relieved of the potentially burdensome and expensive notification requirements established by the HITECH for a data breach.

Best practices for HIPAA encryption include:

1. Ensuring your encryption is certified by the National Institute of Standards and Technology (NIST). 
2. Using an encryption key management appliance that is FIPS 140-2 certified. Federal information processing standards codes (FIPS codes) are a standardized set of numeric/alphabetic codes issued by the National Institute of Standards and Technology (NIST).  They are designed to establish uniform identification of geographic entities through all federal government agencies. 
3. Encrypting any and all systems and individual files containing ePHI including medical records (and related personnel records), scanned images, your practice management systems and any emails that contain ePHI.
4. Encrypting data that is published on the Internet.  
5. Encrypting data on your computers, including all laptops.
6. Encrypting data that leaves your premises.
7. Encrypting all sessions during which your data was accessed remotely.  This last one requires diligence supervision to ensure that it is followed every single time.  It should become a habit, something each staff member with access offsite does as a matter of course. 

HIPAA encryption protects not only the personal health information of employees and patients from unauthorized disclosure and use, it protects SMBs from the potentially significant costs (i.e., financial, administrative and via damage to the organization's reputation) that result from such disclosure. 

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.

DOWNLOAD WHITE PAPER Download our Encryption Key Management and PCI DSS 2.0 Compliance Matrix white paper and learn more about ensuring the data you are protecting meets PCI compliance. Click Here to Download Now

As security auditors get more educated on the IBM i platform, more customers are having the experience of failing a security audit around encryption key management. CIOs, IT Managers, and System Administrators want to know why this is happening to them now? They ask, why was our approach OK two years ago, and why is it not OK now?

I think I can answer that.

My job brings me into conversations with a lot of companies undergoing security audits under a broad range of regulations including PCI DSS, SOX, GLBA/FFIEC, FERPA, and many others. Security and compliance auditors look to industry standards and best practices for guidance on what their clients should be doing in the area of key management. In the US this inevitably brings them into contact with the National Institute of Standards and Technology (NIST), an agency within the US Department of Commerce. NIST provides a wide set of standards and best practices guidance in the area of encryption and key management.

As you become familiar with the broader set of data security regulations, you start to realize that the one common source they have is NIST. Even if not directly referenced in the regulations, the concepts are largely drawn from work done by NIST, and that is why there are a set of common attributes that auditors look for in a key management implementation.

So, auditors now look for key management implementations based on NIST best practices and standards. Key management best practices can be found in the NIST Special Publication 800-57 (three parts).

One of those best practices is Separation of Duties. This best practice says that the people who manage encryption keys should not be the same people who manage and have access to sensitive data such as credit card numbers, social security numbers, patient data, and so forth. It makes sense – you want as few people as possible with access to sensitive data, and you only want people who have a real need to access sensitive data to do so. The same is true with encryption keys that protect that sensitive data.

On the IBM i platform the security officer and anyone with All Object (*ALLOBJ) authority can access any database file at any time, and can access any locally stored encryption key at any time, regardless of the protections you try to put in place. This is not really a limitation or weakness of the IBM i platform, the same condition exists on other operating systems and platforms, too. No matter what you do you can’t achieve a defensible level of Separation of Duties if you store encryption keys on the IBM i platform. You can try to mitigate this situation through system logging and similar controls, but you can’t eliminate it.

Auditors have learned this about the IBM i platform.

Separation of Duties is only one problem area with the local storage of keys. You also have to contend with Dual Control, Split Knowledge, key lifecycle management, and a broader set of key management best practices most of which are difficult or impossible to achieve when encryption keys are stored locally.

And that’s the main reason IBM i customers are failing security audits around encryption key management.  Download our our Encryption Key Management Requirements for PCI white paper to learn more on how you can pass your next key management audit with flying colors.

Patrick

As you probably know “Phishing” is the security term used for email that looks perfectly valid, but which contains links or attachments that can infect your PC. Really good phishing email looks like it came from someone you know, or from a business that you work with and trust. A well-crafted Phishing scheme lowers your defenses. You say to yourself, “I’m glad John got back to me on that financial plan.” Or, “I wonder why Wal-Mart is having trouble with my invoice.” And a click or two later and you’ve fallen victim to a phishing attack.

Sometimes you know right away when you’ve fallen victim. Your PC goes bonkers or acts oddly and perhaps disturbing messages appear. However, the worst infections can go undetected for a long time. The malware may be snooping for your on-line banking account password, or trying to steal other valuable information. These are probably the worst types of malware infections as you don’t know you are infected.

Small and mid-sized businesses are now under increasing attack from this type of security threat. Organized criminals are looking at these companies as more vulnerable and easier targets. They may have smaller bank accounts, but it may be easier to drain them. So don’t think being a small company will not make you a target.

Here are some thoughts on simple things you can do:

• Be sure all of your PCs and Macs are running the latest anti-virus protection software. Nothing should be connected to your network that does not have the best possible protection.
• Be sure you use strong and unique passwords for financial accounts. We human animals like to minimize the number of complicated things we have to remember. If you use the same password for Facebook and your company bank account, you are in a lot of danger.
• If you are a small company, consider dedicating a small laptop to do your on-line banking. You could load Linux (Ubuntu is my favorite) and a web browser like Firefox, and only use the laptop for that one function.
• Use two-factor authentication for all of your high value transactions. The better banks will help you implement this, and it is one thing that can be helpful.
• Be sure to remind your colleagues on a regular basis to be careful. Being alert is one of the strongest deterents.

One of the biggest mistakes you can make is to feel you are immune from this type of attack. Those of us who work in IT or in the security area begin to think we are bullet-proof. Not so! I found myself shocked recently after clicking on a Facebook posting that looked like it came from my daughter, and watching Microsoft Security Essentials quarantine a nasty virus. My shields were down and I suffered an attack. But this is the characteristic of a really good phishing attack. You relax into a state of trust right at the wrong time.

Now, where’s that email from my new business partner in Nigeria?

For more data privacy news and tips, follow us on Facebook, Twitter, and LinkedIn.

   

The new PCI Data Security Standards (PCI DSS v2.0) are here and we’ve gotten a lot of questions about the changes related to encryption key management. Because we work with a lot of companies going through PCI compliance audits and reviews, the new standards just confirm the trends we’ve seen over the last few months on how QSA auditors and security professionals view encryption key management, and what they see as the minimum requirements for managing keys. I recently sat down with Patrick Townsend, Founder & CTO of Townsend Security, to discuss the new PCI regulations in regards to encryption key management.  To hear an expanded podcast of our conversation, click here.

 

What is the source of industry best practices for key management?

 

The NIST special publication SP-800-57 provides specific pointers on best practices for both procedurally managing encryption keys, and what to look for in key management systems. In these documents you will find the genesis of most standards regarding encryption key management, including the concepts in PCI DSS 2.0 Section 3.

Also, key management solutions are certified to the FIPS-140-2 standard for cryptographic modules. So FIPS-140 is a source of best practices and standards.

 

Dual control, separation of duties, and split knowledge have been buzz topics in the key management world lately.  What do they mean?

 

Well, dual control means that at least two people should be required to authenticate before performing critical key management tasks.

 

Separation of duties means that the individuals managing encryption keys should not have access to protected data such as credit cards, and those that have access to protected data should not have the authority to manage encryption keys.

 

Split knowledge is defined in the PCI DSS version 2.0 glossary as a “condition in which two or more entities separately have key components that individually convey no knowledge of the resultant cryptography key.”

 

Are there any standards or best practices regarding “integrated key management?”

 

“Integrated key management” is a term of art, and not a standard.  If “integrated key management” means “we store our encryption keys on the server where the data is,” then that is a bad thing, from a compliance and security point of view. 

 

So, what are the best practices for encryption key management?

 

First you should follow the key life-cycle and be able to document it.  You should always separate the keys from the data.  If you follow the PCI guidelines, you are in excellent shape.  Finally, I would recommend only using a FIPS 140 certified key management solution.

 

What are the practical implications of these best practices and core concepts such as “dual control” and “separation of duties?”

 

One of the practical implications follows from a common fact of system administration. On all major operating systems such as Linux, Windows, and IBM System i (AS/400) there is one individual who has the authority to manage all processes and files on the system. This is the Administrator on Windows, the root user on Linux and UNIX, and the security officer on the IBM i platform. In fact, there are usually multiple people who have this level of authority. In one study by PowerTech, the average IBM System i customer had 26 users with this high level of authority! You just can’t meet PCI and other industry standards for proper key management by storing the encryption keys on the same platform as the data you are trying to protect.

 

To download an expanded podcast of our conversation, click here.