Cloud Security

Last week, saw the release of a research paper from the University of California and MIT called Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds [PDF].

The abstract reads:

Third-party cloud computing represents the promise of outsourcing as applied to computation. Services, such as Microsoft’s Azure and Amazon’s EC2, allow users to instantiate virtual machines (VMs) on demand and thus purchase precisely the capacity they require when they require it.  In turn, the use of virtualization allows third-party cloud providers to maximize the utilization of their sunk capital costs by multiplexing many customer VMs across a shared physical infrastructure. However, in this paper, we show that this approach can also introduce new vulnerabilities.
Using the Amazon EC2 service as a case study, we show that it is possible to map the internal cloud infrastructure, identify where a particular target VM is likely to reside, and then instantiate new VMs until one is placed co-resident with the target. We explore how such placement can then be used to mount cross-VM side-channel attacks to extract information from a target VM on the same machine.

After introducing the main concepts the threat model of the research is defined:

In our threat model, adversaries are non-provider-affliated malicious parties. Victims are users running confidentiality-requiring services in the cloud. A traditional threat in such a setting is direct compromise, where an attacker attempts remote exploitation of vulnerabilities in the software running on the system. Of course, this threat exists for cloud applications as well. These kinds of attacks (while important) are a known threat and the risks they present are understood.

We instead focus on where third-party cloud computing gives attackers novel abilities; implicitly expanding the attack surface of the victim. We assume that, like any customer, a malicious party can run and control many instances in the cloud, simply by contracting for them. Further, since the economies offered by third-party compute clouds derive from multiplexing physical infrastructure, we assume (and later validate) that an attacker’s instances might even run on the same physical hardware as potential victims. From this vantage, an attacker might manipulate shared physical resources (e.g., CPU caches, branch target buffers, network queues, etc.) to learn otherwise confidential information.  In this setting, we consider two kinds of attackers: those who cast a wide net and are interested in being able to attack some known hosted service and those focused on attacking a particular victim service. The latter’s task is more expensive and time-consuming than the former’s, *but both rely on the same fundamental attack.

Section (5) “Network Probing” lays the foundation for (6) “Cloud Cartography” through describing…

…an empirical measurement study focused on understanding VM placement in the EC2 system and achieving co-resident placement for an adversary. To do this, we make use of network probing both to identify public services hosted on EC2 and to provide evidence of co-residence (that two instances share the same physical server)

They then go on to describe the tools and techniques in:

• “enumerating public EC2-based web servers using external probes” (hping2, nmap, wget)
• “translating responsive public IPs to internal IPs (via DNS queries within the cloud)” (DNS)
• “launching a number of EC2 instances of varying types and surveying the resulting IP address assigned” (I assume this was scripted)

Using data from booting 4,499 (!) EC2 instances across different EC2 accounts under their control (remember that by default, an EC2 account has a 20-instance soft-limit), they develop the following heuristics for mapping EC2 instances:

• All IPs from a /16 are from the same EC2 availability zone (e.g. US).
• A /24 inherits any included sampled instance type (e.g. small, large, x-large etc). If there are multiple instances with distinct types, then we label the /24 with each distinct type (i.e., it is ambiguous).
• A /24 containing a DomO IP address only contains Dom0 IP addresses. We associate to this /24 the type of the DomO’s associated instance (note: DomO is the first domain started by the hypervisor after boot)
• All /24’s between two consecutive Dom0 /24’s inherit the former’s associated type.

They conclude this section with “cartography countermeasures”.  This boils down to making local IP address assignment (from the address pool) random across instance types and availability zones and/or restricting the customers view.

Section (6) describes how to determine co-residence:

Given a set of targets, the EC2 map from the previous section educates choice of instance launch parameters for attempting to achieve placement on the same physical ma- chine. Recall that we refer to instances that are running on the same physical machine as being co-resident.

In this section we describe several easy-to-implement co-residence checks.

Looking ahead, our eventual check of choice will be to compare instances’ Dom0 IP addresses.

We confirm the accuracy of this (and other) co-residence checks by exploit- ing a hard-disk-based covert channel between EC2 instances.

They identify 3 network-based co-residence checks:

• matching Dom0 IP address
• small packet round-trip times
• numerically close internal IP addresses (e.g. within 7).

Now able to determine that a given EC2 instance under their control is on the same physical hardware as the target, section (7) analyses EC2’s VM placement strategy and explores techniques the attacker can use to achieve reliable co-residence with a target VM.   In the context of a brute force placement attack they note that “even a very naive attack strategy can successfully achieve co-residence against a not-so-small fraction of targets”.  Thus if your target set is wide, brute force turns out to be a viable strategy.  For individual or small sets of targets, a more efficient strategy is “instance flooding” (spinning up numerous VMs) immediately after the target has booted to “take advantage of the parallel placement locality exhibited by the EC2 placement algorithms”.  This is where the dynamic nature of cloud comes into play:

But why would we expect that an attacker can launch instances soon after a particular target victim is launched?  Here the dynamic nature of cloud computing plays well into the hands of creative adversaries. Recall that one of the main features of cloud computing is to only run servers when needed. This suggests that servers are often run on instances, terminated when not needed, and later run again.  So for example, an attacker can monitor a server’s state (e.g., via network probing), wait until the instance disappears, and then if it reappears as a new instance, engage in instance flooding. Even more interestingly, an attacker might be able to actively trigger new victim instances due to the use of auto scaling systems. These automatically grow the number of instances used by a service to meet increases in demand. (Examples include scalr ³⁰ and RightGrid ²⁸.  See also ⁶.) We believe clever adversaries can find many other practical realizations of this attack scenario.

With co-residence achieved, section (8) assesses the practicality of side channel attacks in a VM environment.  As you’d expect, a number of possibilities exist, however the holy grail of cryptographic key extraction does not appear plausible (at this time).  One notable quote:

The side channel attacks we report on in the rest of this section are more coarse-grained than those required to extract cryptographic keys. While this means the attacks extract less bits of information, it also means they are more robust and potentially simpler to implement in noisy environments such as EC2.

Side channel attacks discussed include:

• Denial of Service
• Measure cache usage (measure CPU utilisation on the physical machine; or “how busy are their servers?”)
• Load-based co-residence detection (aka detecting co-residence without relying on sending any network probes)
• Estimating traffic rates (sounds harmless but can be used to deduce targets activity patterns, peak trading times for maximal DoS effect etc)
• Keystroke timing attack (remote keystroke monitoring)

As with each of the other sections, the authors suggest potential countermeasures.

Overall the paper makes a very interested read.  There’s no EC2 “0-day”, but that’s not the intent of the paper.  Rather, we are reminded that cloud platforms and technologies do bring some novel attacks that thus far have not really figured in much of the security conversation to date.  We need more of this type of research to better understand what we are getting ourselves into.

Today, nScaled announces the Legal Cloud in Beta. This is a vertical specific cloud targeting the “infrastructure on demand” (IaaS) requirements for international law firms:

Legal Cloud today announced that several top, international law firms had signed up as early testers of its virtual data center services for the legal market. The Legal Cloud is operating a ‘closed beta’ with select law firms interested in reducing the costs of their existing collocation facilities, finding a way to implement a business continuity program without duplicating private infrastructure or simply planning for their future primary and secondary infrastructure facilities.

What Makes This Different?

From their blurb:

The founders of the Legal Cloud have been working in the legal technology industry for over a decade. We understand that the needs of international law firms are different to other industries. Our data centers are optimized to meet the needs of law firms. Our choice of technologies, performance, data storage, latency, service level agreements, security and features have all been specifically devised to support the needs of the legal industry (source).

Why This Is Important From a Cloud Security Perspective?

• This cloud is designed around the needs of a specific industry:  with a well defined set of clients in mind it can cater to the groups specific operational and security needs
• These are not just “any customers”: international law firms that will have legal, compliance and security requirements over and above your “average” cloud customer today.  This needs to be a cloud with ‘higher assurance’ features to gain the trust and buy-in of legal CIOs
• The security conversation suddenly becomes a lot more focused: we are not talking about a general “one size fits all” cloud anymore and facing the disharmony of varying customers security needs and provider capabilities.  This may sound trivial but security conversations can get painful fast when customer and provider come from different worlds.
• In a view I’ve held for a longtime, its a taste of things to come: banking clouds, healthcare clouds, federal clouds (happening now).  Yes, there are other industry specific clouds (e.g. Salesforce Service Cloud) and they have their own security requirements, but arguably less assurance will be demanded by customers.
• The customers become an important lobby group for future security feature requests: instead of X voices asking for completely different things, the community of Legal Cloud users will state requirements “loud and clear” and if nScaled doesn’t listen, provide an opportunity for “Another Legal Cloud” to steal customers.
• The success of this cloud will be judged by many: if nScaled delivers on their promise, they will benefit from first mover advantage and become the “standard” for legal cloud.  From my UK experience, the legal community is cautious about new technologies and is a pretty tight-nit group, so if sufficient “established” legal firms move its not hard to imagine many more following (well, I’m sure that’s what nScaled hopes ;-).

What Is On Offer?

Legal Cloud is offering the following on a services basis:

• Fully virtualized data centers
• Business Continuity Service
• Active Cloud Servers
• Unlimited Storage
• Snapshot recovery points

And here’s how it looks from a 50,000ft:

What Do They Say About Security?

After a brave headline of “Security Guaranteed” (sure to rile anyone in information security), they go on to state:

The security of your data is of paramount importance. Here is how we guarantee it’s security.

Secure Data Centers

Our data centers are highly secure and redundant precision environments backed by the Fanatical Support of Rackspace. (SAS-70 Compliant)

Secure Virtual Private Networks

We extend your network into the Legal Cloud using VPN (Virtual Private Network) and VLAN (Virtual LAN) technologies. Your data is encrypted during transit with IPsec. Within the Legal Cloud, your data is segregated in logically separate areas from other clients data and attached only to your private networking. This gives each client their own private network and storage in the Cloud.

Data Encryption

Client Data is encrypted from client source servers to target devices using strong encryption protocols.

Not on the public Internet

The legal Cloud is not exposed to the public Internet. It is actually an extention of each clients internal network, each seperated by strong security protocols.

Service Level Agreements

We are working on appropriate SLA’s for our legal customers during the beta period.

Psychologically, I suspect the most significant reassurance for many CISOs will be this one single sentence: “Not on the public Internet”.  Beyond that, use of IPsec will make this feel very much like a standard 3rd party ‘partner’ connection.  I don’t see any mention of storage encryption options as yet, nor any further detail on the logical separation - once I’ve had a briefing and can speak more to the security aspects, I’ll post more.

P.S nScaled have annouced a couple of webinars aimed at their target audience here.

Regular readers will know I recently extended an invitation to give feedback from an enterprise IT security perspective to any startup that got accepted to present at Under The Radar on April 24th in Mountain View, California.

This post is a summary of a very interesting call I had with George Reese, CTO of enStratus and author of the forthcoming “Cloud Application Architectures” book.  Please note: this isn’t a comprehensive review of the full service, rather it reflects the pieces that we delved into based on some of the common concerns we have around Cloud Security (to give you some idea, we spoke for over 90 minutes…).

enStratus offers cloud infrastructure management tools “aimed at the needs of enterprise IT”.  Today, they support Amazon EC2, with support for other clouds to follow.

Their tag line is ‘Confidence in the Cloud’ and their offering focuses on 3 key areas addressing the twin cloud adoption barriers of security and reliability:

• protecting cloud based data through encryption
• offering service levels above that of the underlying cloud provider (99.9999% for EC2)
• achieving Recovery Time and Recovery Point Objectives “in the face of the most extreme disasters”.

George outlined 3 concerns his customers have about cloud providers such as Amazon:

• Amazon controls the physical systems on which the data resides, meaning Amazon malfeasance, Amazon misfeasance, or even 3rd party subpoenas put that data at risk.
• The complexity of resource orchestration in the context of credential management; i.e. when do your credentials need to be in the cloud versus when their presence is just a security risk
• User management, even via traditional identity management systems, can be dysfunctional.

The enStratus Approach to Cloud Key Management

One of my pet peeves with AWS is the “one key to rule them all” security model (the dysfunctional user management George alluded to).  Any disclosure of that key results in an attacker gaining access to all your infrastructure.  But to make privileged API calls, every developer must have a copy of the key…

Its not unknown for AWS users bundling an AMI (creating a virtual machine image) for public consumption to leave their AWS credentials in the AMI itself.  Oops. This is obviously a Bad Thing ™ as a malicious user that opts to use that AMI can steal their access key, gain access to their Amazon hosted infrastructure and run up bills in their name.

One of the things I really like about the enStratus offering, is the relentless focus on controlling the use and hence exposure of a customers’ ‘cloud masterkeys’. Their implementation keeps the keys away from the AMI, and therefore the cloud, PLUS out of the hands of an org’s IT/dev people.

enStratus acts as a trust broker. After signing up for the service, the customer loads their “all powerful” Amazon credentials via a shared enStratus Provisioning Server into a Credentials Server (no direct internet connectivity).

From that point forward, the customers’ IT people access the enStratus service and manage their cloud infrastructure via named user accounts assigned specific privilege levels.

Permissions include;

• administrator
• start/stop servers
• uptime retrieval and
• audit trail review.

Non-administrative users have no direct access to the AWS keys.

Here’s a peek at the architecture of enStratus.

When an authorised enStratus user issues cloud infrastructure management requests via the Web Services and Console server, the Provisioning server issues the cloud API calls on behalf of the users.  This eliminates the need for every user needing a copy of the key to sign requests.  Given they are mediating API requests, adding logging functionality was a no-brainer and means the next time you need to know ‘who spun up that unpatched AMI image with an allow-all security group?’, you can find out.

Its important to note that there is nothing preventing anyone with your AWS key from just making API calls directly to the AWS API endpoint - totally bypassing the enStratus infrastructure.  Therefore, careful key lifecycle management is still necessary; i.e. load fresh AWS credentials straight into enStratus and follow a “no sharing” policy.

I should point out that the EC2 ecosystem players can’t do anything about this as the AWS platform doesn’t offer a mechanism to tie IP level controls to AWS key usage or EC2 (yet).  One way Amazon could implement this (nothing announced) is with their new JSON based Access Policy Language.  Despite this, enStratus can still detect new EC2 instances spun-up by API calls they didn’t mediate, through telemetry used for operational monitoring - they just won’t be able to tell you who started it.

enStratus can help customers build their AMIs, including bundling in HIDS (Host based Intrusion Detection) via ossec, with centralised agent reporting.  Another example of how they protect the AMI key is through error checking in their scripted AMI builds to ensure key material is not left in an AMI accidently.  In addition, users are prevented from accessing partially provisioned AMIs (to eliminate potential key snarfing shenanigans).

Root access to EC2 images is disabled by default (unlike with vanilla EC2).  Privileged access is granted via sudo.

Filesystem Encryption

enStratus offers optional filesystem encryption through a checkbox.  Keys are temporarily passed into the EC2 instance when required; i.e. mounting.

Encrypted filesystem support is implemented via 2 block volumes configured as RAID 0.  2 sets of encryption keys are used.  One for encrypting and remounting the ephemeral drive (this is a “non-persistent store” automagically attached by EC2 to each running AMI).  The second key pair is used to encrypt and mount filesystems attached as Elastic Block Storage (EBS).  EBS is off-instance, persistent storage.  To avoid potential exposure of key material, the 2nd set of keys are stored on the encrypted ephemeral drive during mount.

Worth noting is that in testing, George found that 2 EBS volumes, configured as RAID 0 with an encrypted XFS filesystem  offers similar performance to a single, unencrypted EBS volume with an ext3 filesystem.

George is keen to stress that enStratus is not looking to control both customers data and their keys.  So whilst he recommends and can help customers make use of the EBS snapshot feature to clone/backup storage volumes to Amazon S3 (Simple Storage Service), he isn’t offering a hosted backup service (to avoid a potential conflict).  Of course, an evil and privileged enStratus employee could access your live data as the keys are stored in their Credential server.  Today though, enStratus is a small company so figuring out ‘who dunnit’ would not require the services of Sherlock Holmes.

Futures

Today, the enStratus management infrastructure sits outside of the cloud (at a colo) for cloud monitoring and isolation reasons.  George is exploring the possibility of also offering an on-premise offering for customers wishing for more control.

I offered a few short and medium term suggestions around additional integrity checks, encryption ideas, assurance processes (source code security reviews, penetration testing) and consideration to using a Hardware Security Module (HSM) for key storage to further bolster both security and trust.  George seemed genuinely open and receptive to these ideas and also shared a few interesting customer requests they are actively working on today.  Some of the more expensive line items would become practical if they can attract additional funding.

Overall, I have to say I’m impressed with their approach, technology and attitude.  Definitely worth a hands-on evaluation if current Cloud controls don’t fall within your risk tolerance.

Good luck to George and the rest of the enStratus team as they prepare to present at Under The Radar!

Attending Under The Radar?

As a special offer to cloudsecurity.org readers, the organisors of Under The Radar are offering $100 off the list price for VIP tickets.  To claim yours, click here.

Positive news from the Amazon camp today as Jeff Barr from the AWS team announces a new access control policy.  Right now, its applicable to the Simple Queue Service (SQS).

A Quick SQS Reminder

For those unfamiliar with SQS, here’s the elevator pitch from Amazon:

Amazon Simple Queue Service (Amazon SQS) offers a reliable, highly scalable, hosted queue for storing messages as they travel between computers. By using Amazon SQS, developers can simply move data between distributed components of their applications that perform different tasks, without losing messages or requiring each component to be always available. Amazon SQS makes it easy to build an automated workflow, working in close conjunction with the Amazon Elastic Compute Cloud EC2 and the other AWS infrastructure web services.

Amazon SQS works by exposing Amazon’s web-scale messaging infrastructure as a web service. Any computer on the Internet can add or read messages without any installed software or special firewall configurations. Components of applications using Amazon SQS can run independently, and do not need to be on the same network, developed with the same technologies, or running at the same time.

So, a very handy data structure that makes perfect sense in distributed programming.  However, access control options were limited…until today.

The New Secret Sauce

AWS is also introducing additional permission features that control access to Amazon SQS and to each of its fundamental actions on a very fine-grained basis. You can exercise this control at two levels:

* At the higher level you can use the new AddPermission and RemovePermission functions to set and remove particular access rights for each queue. Access rights, including the ability to send, receive, or delete messages, change message visibility, or to retrieve queue attributes, can be granted to any AWS user via their AWS account number.
* At the lower level you can use our new Access Policy Language. This expressive language makes its debut as part of this SQS release; over time, we plan to employ this Access Policy Language with our other services. The Access Policy Language enables the creation of complex rules to enable access to queues based on identity (AWS account number), source IP address, date, time, and more.

With this new permission system you can now use Amazon SQS queues to connect non-AWS applications to AWS applications and to connect AWS applications from different organizations. You could use an open, public queue as a drop box, allowing outside applications to submit work items for processing. This could be a fully public drop box, or it could be limited to requests from a single country by using a policy based on an IP address or address range. Communication between organizations can be established based on IP addresses or AWS accounts, as appropriate.

For me, the most significant news is not so much that SQS now has fine grained access control, but that Amazon have introduced a Access Policy Language and they plan to apply it to other AWS services.  This is a very positive development and could be the mechanism they use to overcome some of the longstanding security concerns I blogged about recently.

Architectural Overview

For the visually inclined (source):

Where:

1. You, the resource owner.

2. Your resources (contained within the AWS service; e.g., SQS queues).

3. Your policies.  Typically you have one policy per resource, although you could have multiple. The AWS service itself provides an API you use to upload and manage your policies. For information about the content of the policies, see How to Write a Policy.

4. Requesters and their incoming requests to the AWS service.

5. The access policy language evaluation code.

This is the set of code within the AWS service that evaluates incoming requests against the applicable policies and determines whether the requester is allowed access to the resource. For information about how the service makes the decision, see Evaluation Logic (Ed: note there are soft and hard denials).

An Example

Here’s an example from the developer docs showing a simple IP based control (multiple controls can be applied to a single resource):

The following example policy gives all users permission to use all possible SQS actions that can be shared for the queue named 987654321098/queue1, but only if the request comes from the 192.168.143.0/24 range.

{
  "Version": "2008-10-17",
  "Id": "Queue1_Policy_UUID",
  "Statement":
     {
        "Sid":"Queue1_AnonymousAccess_AllActions_WhitelistIP",
        "Effect": "Allow",
        "Principal": {
           "AWS": "*"
         },
        "Action": "SQS:*",
        "Resource": "/987654321098/queue1",
        "Condition" : {
            "IpAddress" : {
               "SourceIP":"192.168.143.0/24"
            }
     }
}

Conclusion

Notice the values for the ‘Action’ and ‘Resource’ tags.  Now imagine those with different AWS service identifiers and resource types and things start to get really interesting.

Now all we need is an user-friendly, hard-to-shoot-yourself-in-the-foot policy generator/front-end to open this feature up to the masses.

All in all, its great to see the introduction of a consistent policy language from the cloud pioneer.

I’m off to learn more about the language…

Update: in case it isn’t obvious from the example, the policy language is expressed using JSON (thanks @lmacvittie for the prompt)

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?