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:
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.
- Creating HIPAA-Compliant Medical Data Applications with Amazon Web Services – The article briefly outlines how companies can use Amazon Web Services to power HIPAA-compliant information processing systems. It focuses on the HIPAA sections The Privacy Rule and The Security Rule, and how to encrypt and protect your data in the AWS cloud.
- Encrypted Storage in the Cloud – Commentary and insight based on the article above.
