Rational Survivability

It does get complicated when it things get into the cloud, but it all boils down to PCI req. 12.8: Put it in your contract! The 12.8 requirements mandate that if you're sharing data with a service provider, which Amazon's EC2 is, your contract with the service provider must have stipulations placing the burden of being PCI complaint on the service provider. But I somehow doubt that Amazon EC2 has undergone a PCI assessment.
If all of your data is being held and managed by company XYZ and you have a contract with them that explicitly requires them to be PCI compliant, it's quite likely you could be compliant without any further effort. Not that any good QSA would take your word for it, but it's possible. I have yet to see any Level 1 or Level 2 merchants that could successfully claim all of their data storage and manipulation happened on a PCI-compliant service provider's netwlrk.
On the virtualization front, there's really not much either for or against virtualization in the PCI standards. However, the moment you put any cardholder data on any system in the virtualized environment, the entire environment becomes in scope for PCI. This can raise your pain to a whole new level if you were hoping to save money by virtualizing.

Well, if they won't allow a PCI clause in the contract, you're not compliant. Period, end of story. You're not compliant with 12.8, therefore you're not compliant.
My previous comment was predicated on the hope, however dim, that you might get Amazon to sign a contract implying PCI compliance. Without that contract, your not going to pass go.
That makes this discussion pretty easy. If you're using Amazon's EC2 and don't have a contract making them responsible for being compliant, your not going to be compliant. And since it sounds like that's not going to happen any time soon, if you're using EC2, you're not going to be PCI compliant.
A side note, if a company is completely relying on Amazon's EC2 to be responsible for their data backups and disaster recovery, they have bigger problems than PCI to worry about. An apology from Amazon and a months' rebate isn't gong to help you when your virtual machine get's accidentally deleted or dropped. But then I'm sure you've already thought of that.

Just tell your auditor that your customers are happy, and that Gartner says that is all you need to do.

Here's a fun question…
What's the chance that some bargain basement PCI Compliance Assessor would even recognize that I was using EC2 as my infrastructure – and declare me "compliant" regardless?

Martin
EC2 has to provide you with their PCI Certificate. That is what you will rely on when completing your SAQ.
We at EPX host a PCI COmpliant e-commerce solution. Our Paypage is cutomized to your site, uses replace value technology so that you still can see the detail trasnaction, process chargebacks and credits and maintain marketing information. Our platform is patent pending and provides full on-line reporting and administration.
Check out our BuyerWall platform at http://www.epx.com

Alex, I'd say about 100% right no, but that may change with the PCI Council's upcoming QA program. I'm waiting to see what sort of shakeup that creates in the industry as a whole. There will always be someone willing to certify a company for the right price.
Chris, if you can get your companies acquiring bank to sign off on EC2 as a 'secure environment', you're golden. But good luck getting to accept that sort of risk.

Morning,
As you are outsourcing your business to a hosting environment then they are required to be PCI compliant or in the process of becoming compliant otherwise your aquirer will not sign off your compliance. This needs to be agreed in your PCI service agreement.
If the right processes are in place from the start for hosting services then you are laughing.

So Matt then, if Amazon (the retailer) is PCI "compliant" then if I put my infrastructure on Amazon EC2 – I'm ok (assuming they're not legally separate entities)?

@Alex – Given the way AMIs are built and the control you have over them, there is no way that just putting your infrastructure on EC2 would in any way, shape or form cause it to be automagically PCI "compliant". The assessor would have to actually audit each critical system. It would not matter if Amazon is certified or not.
Not sure if anything stored on S3 via EC2 can, itself, be certified easily, tho.
For other bits of "the cloud" it may be possible (say, if you are only using a SaaS platform and the vendor is PCI "certified"). But it's likely that a SaaS provider is going to be running on EC2 or something similar, so all bets are truly off.
PCI is the least of our worries in "the cloud". I suspect very draconian (and moronic) regulations coming in 2009 that will make us wish we only had Sarbanes-Oxley to deal with, let alone vendor-driven PCI compliance. And, heaven help us if any new measures are applied across the board instead of being targeted to public companies.

You might want to check out the new release from COhesiveFT (Full disclosure, I am a founder). We released the VPN-Cubed product on Tuesday which is aimed at precisely the problem you describe. This product allows end users to regain control of the security of their assets running inside the cloud. Don't take my word for it look here at James Urquharts post http://blog.jamesurquhart.com/2008/10/why-i-think…
or check out the VPN-Cubed product at our web site http://www.cohesiveft.com/
Craig

Nobody cited the AWS Customer Agreement yet (http://aws.amazon.com/agreement/)?
These two basically hand over enough responsibility to you, of which you won't ever be able to pass a true PCI audit:
5.4.3. You are personally responsible for all Applications running on and traffic originating from the instances you initiate within Amazon EC2. As such, you should protect your authentication keys and security credentials. Actions taken using your credentials shall be deemed to be actions taken by you.
Yes — YOU, are personally responsible. 🙂 The last line is classic, "if you're pwn3d — we don't care, we thought it was you".
And then…
5.4.5. Network. You may make network connections from Amazon EC2 hosted servers to other hosts only with the permission and authorization of the destination hosts and networks. Examples of unacceptable network traffic include:
* Unauthorized probes and port scans for vulnerabilities.
* Unauthorized penetration tests, traffic that circumvents authentication systems or other unauthorized attempts to gain entry into any systems.
* Web crawling which is not restricted to a rate so as not to impair or otherwise disrupt the servers being crawled.
* Unauthorized network monitoring or packet capture.
* Forged or non-standard protocol headers, such as altering source addresses, etc.
* Flooding.
* Denial of Service (DoS) of any kind.
You may not operate network services such as:
* Open proxies.
* Open mail relays.
* Open, recursive domain name servers.
So it seems that an "authorized" penetration test is OK… Because, if I'm auditing why wouldn't I do an app vulnerability assessment a few times a year? Then again, Amazon doesn't say anything about their infrastructure protecting itself. I'm guessing you'd be in a world of hurt trying to audit "the cloud".
–windexh8er

I'm going to assume (a) that someone is pulling legs here or (b) trying to make a point. Then I'm going to answer seriously.
I'm sorry there is no way your solution is PCI compliant.
It's already been pointed out you fail 12.8. Any failure, even at the lowest level, is a complete failure.
Review the new version of the standard as it clarifies things. Your service provider must be audited either under their own initiative or yours. This has always been the case, it's just spelled out now.
The other issue is scope, which will impact how many systems need to comply, which in turn effects cost. You are in for a very large bill to get an assessment. You need the full cooperation of Amazon to do it. Any requirement you can't meet, you will need to design, document, and test a compensating control for. And while in theory, you could have compensating controls for almost every requirement. In practice this is unlikely to work.
The possibility that other solutions may be able to protect you is still far from clear and would require a lot of review and due diligence before you begin. I would go far as suggesting that people offering extraordinary solutions should shoulder part of the burden of inital due diligence (Extraordinary claims require extraordinary proof).
My best advise based on what you've said here, is to seriously consider selling your book of business to a compliant competitor and let them migrate your customers to their infrastructure. Then you can layoff the individual who failed to do proper due diligence for you before starting.

>EC2 has to provide you with their PCI Certificate
Indeed; I also second what Martin said above – if you cannot get this, then you are not compliant.
Why is it so hard to understand? 🙂

@Bob Rudis:
I'm not concerned about being "technically compliant" as much as I am interested in risk transfer, fines, & legal sense. I can get my pet goldfish "technically compliant" if I have enough money and pay a desperate enough QSA. And I can probably get him registered to vote in Ohio now that I think about it….
12.8.2 compared to Amazon's agreement language pretty much ends the discussion from Amazon's responsibility standpoint. But if I can get a QSA to wave their wand and grant me magic-fairy compliance status – while being on EC2 – what's my liability?

@Hoff
I don't agree with your position on this. Certainly the SSC needs to look at virtualization and other technologies. Less extreme virtualization technology can certainly be assessed as compliant. As well they need to look at improvements in wireless and other areas. But you're suggesting they need to step up. What about the service providers? Don't they need to step up? Technology soloutions must answer to business requirements. Business requirements include more than just cost savings. I don't think the SSC needs to redefine service providers. In fact the PCI folks have that exactly right.
I'm fairly certain that a secure cloud could be designed and implemented. But time and time again, people build solutions without thinking forward about security. Then retroactive security naturally becomes much more expensive. This pattern of behaviour has repeated itself over and over. That's what's happening here.
You chose the most extreme example and pushed it to its logical conclusion. I submit that the service being discussed was unsuited/unfit for the purpose. Just becuase you attach a new term and some new technology to something, it's still outsourcing. Due diligence is still needed. It's that simple.

I'm not sure about your point that Amazon has no visibility to your data. If disk images are encrypted, the running virtual machine has keys. The virtual machine itself is exposed to the hypervisor. If a nefarious Amazon EC2 developer decides to record an entire execution trace or simple take snapshots of memory-in-place, the data being operated upon is exposed.
It doesn't need to be an Amazon EC2 developer, either. If one or more of the physical machines are compromised, or the hypervisor or controlling infrastructure is compromised, a hacker may be able to gain the necessary access to do the same.

@Chris
Okay, we're not on the same page. Maybe not even the same chapter. But people are talking – even if it's only you and I.
We can argue about how well formed PCI (or other standards are) but ultimately the data belongs to the card companies and Issuers and they can call the shots on how it's protected. Anyone who wants to play with their data has to play by their rules. So yes, service providers must step up. And the contractual architecture and compliance framework will largely ensure that happens.
To clarify, by saying the most extreme example of virtualization (being a cloud) I was contrasting it with simpler examples such as virtualized servers. The contrast is what is important and not the magnitude.
To show that certification (or at least audit) of these kinds of things is possible you should check out what Google's had assessed under a SAS/70 ( http://www.theregister.co.uk/2008/11/04/google_se… ).
Of course, some organizations will fail. It's still a question of due diligence. That should not be that hard for anyone in the business to grasp.
If the provider is not prepared to address the requirements, then their service is not fit for the purpose. People and companies have always taken risks that perhaps they shouldn't. This isn't any different. (The issue of being prepared to design, implement, and assess compliant services is also different from the decision to accept the risks of doing that business). Currently, there are a lot of providers of other much simpler services (e.g. co-location) that haven't stepped up. Yet others have and are stepping up.
There are also ways to read the PCI DSS requirements for intent and not quite so literally. But to your point – it can be very challenging to do that and retain the spirit/intent. It can also be non-obvious. Certainly it will provoke additional debate and will likely entail more cost to get it right.
The PCI folks have many fires to put out and aren't likely to rush out to greet relatively new technology on their own. They have their own priorities and resource constraints.
I could counter with, why aren't the virtualization vendors forming their own SIG/WG to address PCI.
By counter example, CISCO built and actually assessed a prototype store to show how their equipment could be compliant. A bit like the IBM Red Book projects.
I do strongly agree with you that the PCI SSC and virtualization/cloud providers should come together. A meeting of minds would benefit everyone.
On the other hand maybe Google (or someone else) may just do it by themselves. That is probably a loss to the collective industry.
Maybe we aren’t quite as far apart as seems at first glance.

Just came across your blog..way over my head with the cloud stuff but certainly would appreciate some advice if possible. My Merchant Card Processor has already charged me an annual service fee of $139.95 for the advanced pleasure of becoming PCI Compliant and also told me that if I do not fill out the questionnaire through a Company called Security Metrics, they will further charge me $20.00 per month. I own a small retail business(no online transactions) and wondered if this is a scam or completely legal as they state that I have to sign a legal document and then they will send me a certificate to become Compliant and yet they have already deducted the above amount and on the questionnaire it simply says that if you have answered all the questins "YES) you are now compliant!!!!
Totally confused and hate being ripped off all the time..Appreciate any help here…..Thx.

After putting some thought into this…
Hoff: There is no way a non-PCI-compliant cloud or virtualization layer of any kind is going to be out of scope for any PCI audit (SP or Merchant).
Answer: You can encrypt and isolate the hell out of your network traffic, disk, and local (VM) swap. Pretend you can completely prevent BIOS/console access of any kind. However, you can't stop your CPU from timing attacks, nor can you encrypt your virtual memory (or the .vswp file from the ballooning process for that matter). Adversaries will naturally move to these areas to attack the VMs and steal credit cards. Plus, there are thousands of other kinds of attack paths based on various other little things such as availability (I think you've made this point yourself in the past).
A PCI auditor has to assume that EC2 (or any non-PCI-compliant cloud or virtualization layer) is wide-open if it's not PCI audited.
OTOH, presence or non-presence of a VMM is something that has to be pen-tested and conform to standards and practices for every PCI requirement. In other words, if a VMM exists, it has to be patched, pen-tested, monitored, integrity checked, et al — and assume the normal alternate or compensating controls.
I'm curious what the QSA or PCI Council will want assessed for the case when a VMM is not present. Things like BIOS, firmware, and integrated flash filesystems (think ESXi) are sometimes left out of scope because they are largely unknowns in the IT world.