HIPAA Compliance and Cloud Security

Wednesday, June 15, 2011

Danny Lieberman

959779642e6e758563e80b5d83150a9f

In almost every software security assessment that we do of a medical device, the question of HIPAA compliance and data security arises.  

The conversation often starts with a client asking the question – “I hear that Amazon AWS is HIPAA compliant?  Isn’t that all I need?

Well – not exactly. Actually, probably not.

As Craig Balding pointed out on his blog post Is Amazon AWS Really HIPAA Compliant Today? there are some basic issues with AWS itself.

There is no customer accessible AWS API call audit log

In other words, you have no way to know if, when and from where (source IP) your AWS key was used to make API calls that may affect the security posture of your AWS resources (an exception is S3, but only if you turn on logging (off by default)).

There is no way to restrict the source IP address from which the AWS API key can be used

The AWS API interface can be used from any source IP at any time (and as above, you have no audit trail for EC2 API calls).  This is equivalent of exposing your compute and storage management API to the entire planet.

Each AWS account is limited to a single key – unauthorized disclosure of the key results in total breakdown of security

It only gets worse. Web services and storage are just a small part of data security. Even if Amazon AWS was perfect in terms of it’s data security countermeasures – there would still be plenty of opportunity for a data breach of PHI.

There are multiple attack vectors from the perspective of HIPAA compliance and PHI data security. The following schematic gives you an idea of how an attacker can steal PHI, figure (inspired of my colleague Michel Godet) using any combination of no less than 15 attack vectors to abuse and steal PHI:

HIPAA security in the cloud

There are potential data security vulnerabilities in the client layer, transmission layer, platform layer (Operating system) and cloud services (Amazon AWS in our example).

Note that the vulnerabilities for a PHI data breach can not only happen inside any layer but in particular there are vulnerabilities in the system interfaces between layers.

Let’s take a specific example:

Consider a remote medical diagnostic service that collects information, transmits it over secure channels (https for the sake of argument) to a centralized facility for processing and diagnosis.  

The entire transmission stream can be secure but if the processing and diagnosis facility uses Microsoft IIS as an interface, it is possible to attack the IIS Web server, create denial of service and exploit IIS7 and Windows operating system vulnerabilities in order to gain access to the machine itself, the data in motion and possibly gain access and compromise the internal network.

A discussion of HIPAA compliance needs to include a comprehensive threat analysis of the entire supply chain of data processing and not just limit itself to the cloud services that store electronic medical records.

For further reading, see the below resources on HIPAA compliance with Amazon Web services and work that Software Associates has done on threat modeling.

Cross-posted from Israeli Software
Possibly Related Articles:
26230
Cloud Security HIPAA
Healthcare Provider
Encryption HIPAA Compliance Cloud Security Threat Modeling Managed Services
Post Rating I Like this!
Default-avatar
Chris Rich Excellent post. I recently posted a blog on IT pro feedback regarding meeting HIPAA compliance here http://blog.netwrix.com/2011/10/25/what-it-professionals-think-about-hipaa/

Chris Rich
Product Manager
NetWrix Corporation
NetWrix is #1 for Change Auditing and Compliance: Simple, Lightweight, Affordable
1319559960
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.