Home > Cloud Computing, PCI, Virtualization > Please Help Me: I Need a QSA To Assess PCI/DSS Compliance In the Cloud…

Please Help Me: I Need a QSA To Assess PCI/DSS Compliance In the Cloud…


I wonder if you might help me.

I operate an e-commerce Internet-based business that processes and stores cardholder data.

I need a QSA to assess my infrastructure and operations for PCI/DSS compliance.

Oh, I forgot to mention.  All my infrastructure is in the cloud.  It's all virtualized.  It runs on Amazon's EC2.  All my data is hosted outside of my direct stewardship.  I don't own anything.

Since the cloud hides all the infrastructure and moving parts from me, I don't know if I meet any of the following PCI requirements:

I don't know if there are firewalls. I don't know about the cloud-vendor's passwords, AV, access control/monitoring, vulnerability management or security processes.

A friend told me about section 12.8, but it doesn't really apply because the "service" provider just provides me cycles and storage, I run the apps I build but I don't see any of the underlying infrastructure.

Also, I have no portability for BCP/DR because my AMI only runs on the Amazon cloud, nowhere else.  I don't know who/how backups are done outside of my manifest.

I'm sure we could ask though, right?

Update: OK, this post worked out exactly as I hoped it would.  On the one hand you have PCI experts who plainly point to the (contrived) example I used and rule empirically that there's no chance for PCI certification.   To their point, it's black and white; either Amazon (in this example) absorbs the risk or you can't use their services if you expect to be in compliance with PCI.

Seems logical…

However, this is the quandary we're facing with virtualization and cloud computing.  In terms of the companies that hire these PCI compliance experts, the assessment methodology/requirements are predicated upon a "standard" that continues to be out of touch with the economic and technological world around it.  That's not the experts' fault, they're scoring you against a set of requirements that are black and white. 

As companies try and leverage technology to be more secure, to transfer risk, to focus on the things that matter most and reduce costs — if you believe the marketing — It's really a no-win situation.

The PCI Security Standards Council doesn't even have a SIG for virtualization and yet we see the crushing onslaught of virtualization with no guidance and this tidal wave has been rushing at us for at least 3-5 years.   If you believe the uptake of cloud computing, we're blindly hurdling over the challenges that virtualized internally-owned infrastructure brings and careening headlong down a path to cloud computing that leaves us in non-compliance.

The definition of what a "service provider" means and how they interact with the cardholder data companies are supposed to protect needs to be redefined.

It's time the PCI Council steps up and gets in front of the ball and not crushed by it such that the companies that would do the right thing — if they knew what that meant — aren't punished by an out-of-touch set of standards.

Categories: Cloud Computing, PCI, Virtualization Tags:
  1. October 29th, 2008 at 10:18 | #1

    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.

  2. October 29th, 2008 at 10:22 | #2

    Um, yeah.
    This is where the train leaves the tracks, Martin. I just updated the post above to shed some more light on the topic. I think the definitional nuance just went off the reservation.
    Amazon has no visibility into my self-contained little application(s) just as I have no visibility into what operates the network platform of the cloud underneath.
    There are some ACL's I can deploy to control access, but this model upsets the apple cart.
    You've obviously never seen the EC2 contract or SLA. You're not going to get Amazon to amend the contract to take responsibility for PCI compliance…
    Check out the posts I made recently about "patching the cloud…"

  3. October 29th, 2008 at 10:38 | #3

    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.

  4. October 29th, 2008 at 10:46 | #4

    But, but Martin…
    The cloud is the Next Big Thing ! We're a virtual company. Virtualization and Cloud Computing is "secure!" We can't afford to own our own infrastructure…that's the whole value proposition of the Cloud Model!
    Surely there's room for negotiating here, right?
    Oh, maybe I can use Azure instead? 😉

  5. October 29th, 2008 at 11:09 | #5

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

  6. October 29th, 2008 at 13:05 | #6

    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?

  7. October 29th, 2008 at 13:06 | #7

    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

  8. October 29th, 2008 at 13:50 | #8

    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.

  9. Matt
    October 30th, 2008 at 02:19 | #9

    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.

  10. October 30th, 2008 at 04:07 | #10

    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)?

  11. October 30th, 2008 at 05:34 | #11

    @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.

  12. October 30th, 2008 at 05:45 | #12

    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/

  13. windexh8er
    October 30th, 2008 at 07:51 | #13

    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".

  14. David
    October 30th, 2008 at 08:49 | #14

    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.

  15. October 30th, 2008 at 09:03 | #15

    >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? 🙂

  16. October 30th, 2008 at 11:00 | #16

    @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?

  17. October 30th, 2008 at 11:15 | #17

    All really, really interesting points.
    I amended the original post with some summary narrative. Check it out.

  18. October 31st, 2008 at 05:31 | #18

    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.

  19. Scott
    November 3rd, 2008 at 12:04 | #19

    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.

  20. November 3rd, 2008 at 19:12 | #20

    The PCI SC ultimately issue the guidelines/guidance/compliance requirement, so suggesting that service providers step up to a set of checklists which are ill-formed in the first place seems like a bit like 2 monkeys trying to screw a football…not that this is at all uncommon, but again there's not even a SIG formed for virtualization, how are we going to deal with CC?
    As to your comment, the definition of "a cloud" let alone "a secure cloud" is getting more and more elusive by the day.
    Forgive me but the this is hardly "…the most extreme example." It's happening right now. Regardless of whether the service being discussed is "unsuited/unfit for the purpose" it's not stopping people from doing it. So long as they're doing it, we have a couple of options to consider:
    1) People shouldn't be doing it, so they're going to get what's coming to them and fail the PCI checklists because referentially the checklists don't speak to the model they're using and anything not defined is, well, denied. Since some of these providers simply won't absorb the risk, that's problematic.
    Not all that harsh really, except for the fact that it's basically ignoring the rush to virtualization, cloud computing and the adoption of models for commerce that have caught the regulators flat-footed (again.)
    2) Understanding that it's happening, the reasons why it's happening and why it's so compelling from a BUSINESS perspective, the PCI SC could decide to put that enormous brain trust of industry to good use and actually be innovative for once, working WITH the community to deliver guidance that reflects reality.
    My notion is that it really ought to be a combination of the two with some understanding that the definition of service provider in many of the various cloud models becomes much more fuzzy…ignoring that means we'll see a lot more post-breach failures as the GTM models dictate an economic and technological groundswell that is hard to ignore.
    Again, the point of my post is to get people talking. It's doing that. The next step is to start to mount pressure to get things changed…on both sides of the coin as has been alluded to.

  21. David
    November 4th, 2008 at 13:19 | #21

    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.

  22. Branmin
    November 17th, 2008 at 18:37 | #22

    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.

  23. December 10th, 2008 at 14:54 | #23

    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.

  1. No trackbacks yet.