Thursday, March 5, 2009

Mosso - First PCI Compliant Customer Through Self Evaluation and Scanning

Mosso, a PaaS cloud provider, claims to be the first in enabling a customer to be PCI compliant within the cloud. Naturally, this really excited me as I have spent a lot of time lately trying to figure out how to acomplish PCI compliance in the cloud. I was somewhat disapointed, however, once I read the details.

In this case, the application within the cloud does not actually store any credit card data. The customer leverages a third party payment gateway to handle collection and storage of all cardholder data.

Additionally, the customer did not gain PCI certification through an evaulation by a Qualified Security Assessor (QSA), but instead only needed to complete a "Self Assessment Questionaire" and pass a scan from an approved scanning vendor (ASV).

Since the application used a third party payment gateway to handle collection and storage of cardholder data, only a subset of the PCI DSS controls applied to this application. According to Mosso's article, only requirement 9 (Restrict physical access to cardholder data) and 12 (Maintain a policy that addresses information security) applied.

It's wonderful that some level of PCI compliance has been achieved for applications within the cloud, but I feel like this isn't much different than Amazon EC2 + Amazon Flexible Payments Service, or even simpler any cloud provider + Paypal. Hopefully in the future, we will have a case study in which an application that handles cardholder data will become PCI certified within a cloud computing provider's infrastructure.



Rob La Gesse said...

Nick, we continue to work towards what you describe. But this is an important first step towards achieving that.

Thanks for the post -

Rob La Gesse
Director of Customer Development
Mosso|The Rackspace Cloud

Andre Gironda said...

Since Mosso uses VMware ESX (Amazon uses a modified Xen), I am curious as to how virtualized RAM is met by requirement 9?

As far as I understand, virtualized RAM for guest VM's is not encrypted, nor is ESX capable of providing an encrypted filesystem where the vswp and potentially memory balloon driver could be protected.

While Xen and Hyper-V Role/Server are capable of providing an encrypted filesystem, they also cannot prevent hypervisor access to unencrypted VM guest virtualized RAM.

This only becomes much more of an issue when VMsafe in vSphere 4.0 becomes available, as well as via the XenAccess hypervisor introspection Sourceforge project for Xen.

I know that hyperjacking has not yet been a public issue for ESX -- it has been a problem for Xen in the past. Regardless of hyperjacking, the virtualization administrators for Mosso and Amazon clearly step beyond the boundaries, and should be at least viewed in a similar light as network monitoring that has access to VM guest RAM -- where all requirements would apply.

pci compliance said...

great post,thanks