Thursday, March 5, 2009

And so begins everyone's claim for Cloud Compliance

Today's blog entry at Mosso Blog

Cloud Sites, Mosso|The Rackspace Cloud’s Flagship offering, is officially the very first cloud hosting solution to enable an Internet merchant to pass PCI Compliance scans for both McAfee’s PCI scans and McAfee Secure Site scans.

While I am all about helping companies meet compliance with whatever technology they are trying to implement there are some facts that seem a little skewed here.

1) They only passed the ASV scan. A scan of the external facing ip addresses as required by requirement 11.2.b. This is great but it's not PCI DSS compliance - it is in fact only one very small piece.
11.2.b Verify that external scanning is occurring on a quarterly basis in accordance with the PCI Security Scanning Procedures, by inspecting output from the four most recent quarters of external vulnerability scans to verify that: Four quarterly scans occurred in the most recent 12-month period; and The results of each scan satisfy the PCI Security Scanning Procedures (for example, no urgent, critical, or high vulnerabilities); The scans were completed by an Approved Scanning Vendor (ASV) qualified by PCI SSC.
2) They aren't processing credit cards - they call an Authorize.net API (SSL wrapper and encryption) and let credit cards flow through to someone else's non-cloud network. Their marketing material shows the API. It sure is neat but again we are still only talking about a piece of the PCI DSS compliance. I am happy that you are not storing credit cards.

3) I don't believe they would be able to PASS an onsite assessment for a RoC but since it looks like they are only a L3 merchant - a SAQ is all they need to fill out.

So why don't I believe they could pass?

Until someone can present a clear picture of the demarc point between the application, virtualization and the physical layers and the controls offering protection between those layers; no QSA will be able to say they are compliant. I have discussions just about the idea of a demarc point between the Dom0/DomU. We haven't even begun to drill into the other layers.

So in this case the merchant's argument might be that they are using a shared hosting provider: (language borrowed from multiple posts in SPSP forum)

A shared hosting refers to a hosting service where many hosted servers reside in a date center connected to the Internet. In shared hosting, the provider is generally responsible for managing servers, installing server software, security updates, technical support, and other aspects of the service.

PCI compliance is the responsibility of the organization who owns the data. In a shared hosting environment where it is truly shared hosting and the client can upload whatever they want, then the client is responsible for ensuring they are using a hosting provider that meets their needs. Simply having merchants that house data in a hosting environment does not impose the requirements upon the hosting provider. There are two basic paths here. 1) the merchants need to ensure they are using a hosting provider that complies with the PCI DSS or 2) the merchants need to ensure they can manage their own systems in accordance with PCI DSS.

I haven't met a Shared Hosting provider yet who is willing to accept the liability of PCI DSS compliance in the cloud - this isn't to say that they aren't all working towards it. So this leaves the merchant responsible for managing their own system - and we fall back to my Dom0/DomU comment and the current problems with providing enough evidence of compliance.

Most QSA's are struggling with the idea of virtualization in general - they either get stuck on the 1 service per server or their view of virtualization is based on their use of VMware or Parallels. QSAs are going to have to either take deep dives into Architecture or they are going to fail companies all over the place.

Finally as I said at CloudCamp last weekend - want to be compliant in the cloud today, treat all information that is stored in the cloud with the highest level of encryption, then it only becomes random bits and it doesn't matter if you suffer a breach.

2 comments:

Anonymous said...

Merchants are those with merchant accounts for accepting credit card payments. In the context here, Rackspace is not a merchant.

The PCI_HowTo.pdf that they have recommends the use of Authorize .NET with the SIM API. Using the SIM API, card data never touches the merchant's systems. The customer is directed to a hosted checkout page on auth .net and the results come back to the merchant site with any cardholder data masked. If the SIM API is used, the merchant can use SAQ A to meet Visa CISP validation requirements. For due-diligence, they just need to ensure that Authorize .NET is PCI DSS compliant in their contracts.

But the problem here is that it’s recommended.

If the merchant web site uses a payment processing procedure where their site touches cardholder data, they are in scope of PCI DSS. At this point, Rackspace potentially can be considered a Service Provider or what Visa calls a Third Party Agent (TPA). It is ultimately the merchant’s responsibility to be compliant to the PCI DSS for ALL REQUIREMENTS. They can do this directly with things they can control, including the web application security of all software they run (eg. Shopping cart software). Anything outside of their control such as server OS maintenance and physical security of the server needs to be included in the merchant’s contract with Rackspace. Getting a copy of Rackspace’s SAQ or ROC (Report on Compliance) is not enough! If card data from a merchant’s processing web site gets compromised because Rackspace gets compromised, the merchant will get the fines due to the chain of contractual liability. It won’t matter if Rackspace was validated. It is up to the merchant to be able to turn around and sue to recover damages from Rackspace at that point.

麗芬 said...

天下父母心-時時孝順你的父母~~.................................................................