Is Amazon AWS Really HIPAA Compliant Today?

Yesterday, Amazon released a whitepaper called ‘Creating HIPAA-compliant Medical Data Applications with AWS’.  There is plenty to comment on, but for now I want to draw attention to some security concerns I have around AWS and thus its current readiness to handle data that falls under HIPAA.

I’m a big fan of Amazon AWS - they are true innovators and the diversity of their service offerings is astonishing.  There are many use cases for Cloud Computing and not all have high assurance needs. But when touting HIPAA compliance for the processing and storage of medical data, I can’t help feeling there are (amongst other things) glaring API level control gaps that would make me extremely uncomfortable with my medical data stored in the Amazon Cloud today.

Amazon is marketing their Cloud - with its current security controls - as able to support HIPAA compliant applications.  The whitepaper does a good job talking up their existing security controls but omits to mention a number of serious control gaps that decision makers should be aware of prior to committing “other peoples data” medical data to the Amazon Cloud.

I’m not a HIPAA expert and therefore in my ignorance, it may well be that AWS can satisfy covered entities security requirements (if so, it says more about HIPAA than AWS or, more about a specific use case).  Consequently, I’ll step aside from the ‘compliance’ angle for a moment and confine my comments to ’security’ and encourage those with first hand HIPAA compliance experience to comment as they see fit.

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)). For example; if your key is compromised without your awareness and your EC2 “security groups” (firewall) are changed, there is no customer accessible log record. The only way to detect this is to poll the API on a regular basis (DescribeSecurityGroups) and compare with the output of previous calls or to call up Amazon support on a regular basis and ask them “is all well?”  (j/k).  I can think of much more sinister API calls to invoke, the security groups is just an example.

They also afford no customer visibility over failed authentication attempts at the AWS web interface or at the API.  Again, no visibilty to understand if your infrastructure in the sky is under attack.  Fine for some workloads, not so fine for others.

Oh, and while we are at it, why is there no firewall log for the built in ’security groups’ firewall functionality?  To get visibility today, you have to run a host based firewall with logging enabled but even then you will not see what was dropped by Amazon (when doing network security investigations, this information can be really helpful).  Basic reporting accessible to customers would be a good start.

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

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.  To be clear, they are not exposing their *internal* management plane - the infrastructure that the Amazon AWS team uses to manage the AWS infrastructure, rather its *your* hosted infrastruture management plane that is exposed.

Why can’t the EC2 security group concept (aka firewall) be applied to the AWS API, to limit access from approved management stations? After creating my key I should have the option to limit use to specific subnets of my organisation.  I’d love to hear this option is on the Amazon security roadmap (along with visibility of failed attempts).

Each AWS account is limited to a single key - exposure results in total security failure

I’ve said it before and I’ll say it again - you only get a single key per AWS account.

That makes it really hard to segregate environments.  To do so, you have to create multiple AWS accounts with different credit cards and even then that only gives a very coarse grained access model.

With your master key, why can’t you generate a handful of subkeys for different use cases?

If you could link those subkeys to roles that reflect your security policies, then you’d really have flexibility.  This would also mean you could lock away the all-powerful master key for use only when such power is warranted (thus reducing potential exposure).

The failure mode of a single key is ‘complete and utter’.  If my key is compromised, my entire AWS environment is compromised - all my virtual machines, all my data.  I don’t know about you, but that scares the living daylights out of me in the context of medical data.

Takeaway

Hopefully we all know by now that “compliance” does not equal “security”, but HIPAA compliance not withstanding, would you really want your medical data in a Cloud without some or all of these fundamental control gaps resolved or mitigated?  I can’t find anything in this new whitepaper or the old AWS Security Whitepaper that speaks directly to these issues.  If I missed something, please share below and I’ll update the post.

When medical data is stored at the medical provider, I can believe they will have a firewall that doesn’t allow outsiders to make API calls to their compute and storage management plane from anywhere in the world…  I can believe that leakage of an internal infrastructure management password cannot be used from *outside* the firewall.  At least, not without first exploiting an unrelated security weakness to gain access to the environment in the first place.

I can appreciate that providers are keen to demonstrate use cases but I can’t help feeling that in their eagerness to market ‘compliance’, Amazon is putting the cart before the horse from a security perspective.

What do you think?