EHRs Need More than Standard Security

I attended a series of web meetings over the past two weeks for the Federal Advisory Committees (FACAs) under the HHS Office of the National Coordinator for Health Information Technology. After listening in to the public Privacy and Security standards working group, I became a bit frightened by how legacy thinking around information security continues to leave us vulnerable to general mischief. The IT industry needs more innovation than we're receiving, especially with regards to the protection of our personal information.

What concerned me most was related to the authentication standards associated with accessing personal health records. While the working group debated the need to support SSL and TLS for secure authentication over a browser with an Electronic Health Provider (EHR), and whether username and passwords were sufficient, one member made the statement that the username and password authentication method is the industry standard and since the banking industry uses it, the working group should consider it sufficient for protecting electronic patient records. Further into the conversation, a member suggested using the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-63 - Electronic Authentication Guideline as the basis for determining the EHR authentication standards.

To address the first point, the "industry standard" used for just about all sensitive personal transactions, I submit that it's either based on the flawed assumption that an organization can trust the endpoint that the user employs to access the sensitive records or the more cynical perspective that if the organization cannot trust the endpoint, it has no liability for what may occur on the user's computer system or mobile device, and therefore no actual or perceived business risk. I recently posted a discussion of how the modern hacker is effectively exploiting the associated vulnerabilities using a traditional Man-in-the-Middle attack to hijack an active electronic session, so I think that I've already sufficiently addressed my thoughts around how the "industry standard" is insufficient for protecting sensitive information.

To the second point, I hadn't reviewed NIST SP 800-63 recently, so I took another look from a contemporary perspective. For a document written in 2006, it does a pretty good job at addressing the known weaknesses in electronic authentication at the time, but its treatment of multifactor authentication as the answer for high-security applications is insufficient for the modern IT world. Even in an updated draft form, the document falls well short of how to protect access to sensitive information.

The updated draft does give some attention to the issues that warrants note. For example, it presents a sample "Session hijack" attack as:

An Attacker is able to take over an already authenticated session by eavesdropping on or predicting the value of authentication cookies used to mark HTTP requests sent by the Subscriber.

When discussing the authentication controls for the first enhanced assurance level (Level 2), the document then presents a protective posture for transmitting authentication information "through a protected channel which is linked to the primary authentication process in such a way that session hijacking attacks are resisted." It follows by presenting a countermeasure to further protect against hijacking.

Hijacking resistance – An authentication process and data transfer protocol combination are resistant to hijacking if the authentication is bound to the data transfer in a manner that prevents an adversary from participating actively in the data transfer session between the Subscriber and the Verifier or RP [Relying Party] without being detected. This is a property of the relationship of the authentication protocol and the subsequent session protocol used to transfer data. This binding is usually accomplished by generating a per-session shared secret during the authentication process that is subsequently used by the Subscriber and the Verifier or RP to authenticate the transfer of all session data.

Imagination is limited in how the document characterizes "Session hijacking" as primarily a communications problem. The problem is that, without a trusted endpoint, a sound authentication method cannot necessarily represent a validated communications channel. In the way that it's presented, the document is treating authentication as a technical control rather than a business process, and that's the primary point of failure.

To protect sensitive electronic health transactions, the Health IT committees functioning to support HHS need to think beyond the "industry standards" and look for innovative ways to avoid this failure. For example, HHS should consider obligating EHR organizations to implement not just multifactor authentication processes, but also multistage authentication processes that require valid user interaction to conduct sensitive operations within an existing session. Where operations are deemed very sensitive, then the additional stages should include some level of "out-of-band" authentication protocol that focuses on protecting the process rather than the communications channel.

Information security failures often occur when considering security as solely a technical concern. Doing so only amounts to addressing symptoms rather than causes. Appropriate security begins with the business processes themselves. Correct weaknesses there, and the rest will follow.

If you would like to comment on this or any of my other postings, you may look for it on Google+ or on LinkedIn and comment there. This helps counter SPAM and promotes intelligent discourse over anonymous rantings.