Nov 02 2008

PCI Compliance in the Cloud: Get it in writing!

Published by at 8:25 am under PCI

A few days ago my friend Chris Hoff asked a very interesting question:  Can I be PCI compliant if I’m using some form of cloud computing?  Now Chris is a virtualization guru, and I have no intention of ever arguing virtualization issues with him (it’s not healthy for the ego to get beat down that badly), but when it comes to PCI I’ve got a leg up on him.  So I made several comments on the post, most of which boil down to referencing PCI requirement 12.8:  If you’re sharing cardholder information, i.e. credit card numbers, with a third party service provider, you need to have a clause in your contract that makes the service provider responsible for the PCI compliance of their systems.  With the example given, Amazon’s EC2, the chances of getting such a clause in your contract are almost non-existent.  Therefore, if you’re using Amazon’s EC2, you aren’t going to be PCI compliant until such a time as Amazon makes a compliant infrastructure.  The same needs to be said of any of the other cloud vendor, it’s not just EC2.

Afterward, Chris appended the post to say that he got exactly the response he expected.  But he doesn’t feel this is a good enough answer: virtualization and cloud computing are the next wave of computing fashion, therefore they need a deeper review by the PCI Security Standards Council to clarify PCI’s stance on these topics.  His rational is that cloud computing is going to happen, is happening and will happen whether we want it to or not.  He believes that the definition of ‘service provider’ needs to be re-examined and updated to reflect the changes these technologies will bring about. 

Point blank:  Chris is wrong.  The definition of ‘service provider’ is fine, here it is directly from the PCI Council’s site:

Service Provider
Business entity that is not a payment card brand member or a merchant directly involved in the processing, storage, transmission, and switching or transaction data and cardholder information or both. This also includes companies that provide services to merchants, services providers or members that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded

By this definition, Amazon EC2 would be a service provider, pure and simple.  It doesn’t matter that the service they’re providing is virtualized.  In the eyes of PCI a virtualized system is really no different from a physical system.  Why should a rack of servers in a data center be different than the same services being provided on one server with multiple VM’s on it?  The service provider is still responsible for the physical security of the systems, they’re still responsible for the patching and security of the underlying operating systems.  Even when we talk about virtualization on your own network, the same PCI requirements apply.  In fact, virtualization can often be a negative from the PCI perspective, since every system that’s in the virtualized environment is now in-scope for a PCI assessment.

I would agree with Chris in saying this is a topic that needs more discussion, but to educate businesses and help them realize that cloud computing is no more a panacea for all their PCI woes than any other form of virtualization is.  You’re taking the same problems that you had with a service provider and adding a whole new layer of abstraction to them.  You’re sharing hardware with an unknown number of other clients, you have less visibility into what’s going on lower in the stack and you have a new set of patching and vulnerability concerns to be worried about.  Rather than reducing your stress levels and potential to be compromised, cloud computing will probably raise it to a new level.

I’d be willing to bet becoming a PCI compliant service provider wouldn’t be all that difficult for Amazon and EC2.  The security is probably already in place, all it would take is having an assessment every year to prove that Amazon meets the standards.  It’s the transfer of liability that’s going to be the big sticking point; I can’t imagine Amazon’s lawyers being in a big hurry to take on this responsibility, no matter how much the marketing department might want ‘PCI Compliant’ in their brochures.  And until you can put a clause in your contracts making your service provider responsible for a portion of your compliance, you aren’t going to be able to use EC2 and be compliant.

Just because a technology is new and exciting, it doesn’t mean we need to redefine the rules.  The definition of service profider works just fine when we’re talking about cloud computing.  They’re providing a service and they need to be compliant if your going be compliant.  There are PCI compliant service providers out there now and there are folks working on PCI compliance in the cloud.  Being a new and sexy technology shouldn’t exempt you from having to meet with the same compliance standards as everyone else, should it?

One last point, PCI requirement 12.8 is about transference of risk to the business closest to the cardholder data.  That’s it.  If your service provider isn’t willing to accept the risk associated with transferring, storing and manipulating cardholder data, you need a different service provider.   

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

20 responses so far

20 Responses to “PCI Compliance in the Cloud: Get it in writing!”

  1. B.K. DeLongon 02 Nov 2008 at 9:01 am

    While I agree with your assessment of 12.8, I’m wondering (rather than adding more detail to the PCI DSS around virtualized environments), if there needs to be some sort of clarification from the PCI Council related to recommended best practices.

    I’ve heard many anecdotes and concerns from security professionals at Tier 1 companies that several of the auditors checking PCI compliance don’t quite get the ramifications of virtualization with regards to DSS requirements. Nor do I hear that SOP is to check all the virtualized server instances on a box to ensure cross-zone contamination is not occurring.

    I’m not directly involved in the securing and examining of networks for PCI compliance but are there opportunities in the audit process where the analyst would know whether an in-scope server is actually a virtualized instance and that the other virtual servers on the physical box should be deemed compliant as well?

    With regard to stating that the third-party is responsible for PCI compliance, I’m hearing in several cases that contracts are already in place prior to PCI Compliance. Many folks are challenged with conveying to legal counsel or even identifying the right people in their organization to ensure that the 3rd Party PCI Compliance requirement is making it into the contract process.

    And what do they do if their 3rd party/in-the-cloud vendor is not PCI Compliant? Would the PCI Council sanction the 3rd party and give temporary waver to the primary merchant? Is the primary merchant become responsible and it’s in their hands to pass along any fines? Would/does it mean that the merchant needs to consider a different solution until said 3rd party meets PCI compliance?

    A lot of this comes down to education and awareness of the core people in an organization outside the risk management and security teams to ensure everyone involved knows what needs to happen in these cases. While there may not be a need for further PCI requirements I think additional clarification and direction couldn’t hurt.

  2. Christofer Hoffon 02 Nov 2008 at 11:27 am

    Spoken like a true auditor who’s missing the point entirely, Martin.

    You are applying, given what you do, the letter of today’s “law” and trying to apply it to a technology and approach for which it was never intended.

    Your simplistic “what’s the difference between a rack of servers and a rack of servers with virtualization” example illustrates an incredibly narrow definition of “cloud computing” and is a dangerous position to take. If you need to understand the differences in those two environments, perhaps you ought to download my 4 Horsemen presentation.

    Just to be clear, you can’t just s/cloud/internet in every conversation to reduce the argument down to the ridiculous assertion that cloud computing is just the internet with virtualization…

    …and that’s the biggest problem here. Your position as an “auditor” is to assess infrastructure and policy against the regulations as they stand. My position as an architect is to assess the impact of technology against the business and prevailing technological advances and try and rationalize that against regulatory compliance and security.

    While someone trying to deploy on EC2 today might “fail” PCI compliance, if you believe the hype, this is going to be a huge, huge problem in a short period of time.

    I’m pushing awareness and highlighting issues while you’re selling compliance against a checklist; that’s not a knock…it just illustrates the point. The regulations and those whose job it is to assess against them are out of touch.

    Here’s why I’m confused…you illustrate my point entirely when you said:

    “You’re taking the same problems that you had with a service provider and adding a whole new layer of abstraction to them. You’re sharing hardware with an unknown number of other clients, you have less visibility into what’s going on lower in the stack and you have a new set of patching and vulnerability concerns to be worried about. Rather than reducing your stress levels and potential to be compromised, cloud computing will probably raise it to a new level.”

    <<<— EXACTLY! And you suggest the PCI Council doesn’t need to revise guidance why!?

    You’re arguing/defending a group of folks who don’t even properly address wireless (still) and telling me that *I’m* wrong…;)

    Glad the post is raising awareness but come back to me when you’ve actually performed an audit against someone using one of these services…

    /Hoff

  3. Martinon 02 Nov 2008 at 1:35 pm

    Chris,

    Part of the problem is that we’re looking at two different issues here, and for each of our issues, we’re both completely correct. What you’re trying to get at is ‘what is it going to take to secure the cloud?’, and I’m looking at ‘what’s it take to be compliant?’. Yes, my view is much more simplistic and it is because I’m an assessor (I’m still not sure what the difference between an auditor and an assessor is, but there is one). I’m not paid to try and secure the cloud. I have a fairly short list of requirements the merchant has to meet with to be considered ‘compliant’ and if this list is met, then I give them a pass. It’s not about securing the merchant, as much as I wish it was, it’s about passing that checklist.

    It’s not so much that I miss your point, it’s that when we talk about the case of PCI, your point really doesn’t apply. I’m talking about dealing with a particular merchant who’s using ‘the cloud’ as his service provider and what that merchant has to do to be compliant. You’re worried about what that same merchant has to do to be secure. The fact is, if I do have a client merchant who’s using the cloud, the guidance I’ve seen shows that I have to treat Amazon or some other cloud vendor the same as I do any other service provider. If the contract says the service provider is taking the responsibility to secure the infrastructure, then the merchant is off the hook. And I think this is where the breakdown in communication is happening and what needs to be addressed.

    Let’s turn the argument a few degree’s off it’s current course and maybe get to something we can both agree on: What would have to be done with Amazon’s EC2 infrastructure to become a PCI-compliant service provider? This question takes the merchant out of the picture entirely, they’re just a consumer of a product at this point. It’s Amazon that has to prove to an assessor, hopefully not me, that they’ve taken the proper steps to protect their infrastructure in a manner compliant with PCI. This is where the breakdown in the assessment process really lies. There is not a separate set of requirements a service provider needs to comply with; there are a superset of 5-10 points that a service provider needs to do in addition to the same requirements a merchant has to comply with.

    Should there be a higher standard for service providers? Heck yeah! Should the PCI Council look at virtualization and cloud computing, how they’re being created by service providers and marketed to merchants and come up with a new set of requirements for the service providers? Most definitely. Does something like that exist now? No.

    So I maintain that the PCI requirements, as they apply to a merchant, are very simplistic on this point: the service provider takes on the liability for the infrastructure being PCI compliant otherwise the merchant won’t be compliant. The merchant isn’t responsible for verifying the security of the service provider, their responsible for the transference of risk. From the merchant standpoint, the service provider can be a blackbox utility, as long as the proper contracts are in place as specified by 12.8 of the PCI DSS.

    I’ve performed assessments against a small number of service providers so they can show their merchants that they’re compliant. But in none of these cases have they been using virtualization, either at the local level or at the cloud level. I evaluated them just like I would a merchant. And I’d assess a virtualized service provider almost the same as I would a non-virtualized service provider, I’d just bring along a lot more tylenol to deal with the headaches the complexity would bring.

    I’ve got your preso open in another tab and I’m going to finish reading it as soon as I’m done with this comment. I wish I’d gotten to see it live. I respect you, Chris, but I think we’re making some of the same arguments from different viewpoints. Eventually I think we’ll come to some sort of agreement.

  4. Christian "xntrik" Frichoton 02 Nov 2008 at 5:54 pm

    I don’t claim to be a whiz at either PCI or *aaS/Cloud/whatever, but what happens if Amazon outsource to company-N for their data centers? What if network management for those data centers (both physical and virtual networking gear) is also managed by an additional third party? How far down the hole do you chase the elusive white rabbit?

    Or perhaps PCI doesn’t go into that level of detail?

    I know for any Authorised Deposit-taking Industries (ADIs) in Australia (read: banks/finance) we have a prudential standard, from the Australian Prudential Regulations Authority (APRA) APS 231 on outsourcing. This suffers the same sort of problem? Everyone outsources everything to everyone else. The web of trust is a complex mess.

    Great post and I’m keen to follow the discussion between you and Chris!

    Re, Christian.

  5. Chris Nealon 02 Nov 2008 at 9:28 pm

    My 2 cents worth.

    As someone who works for a service provider and delivers “in the cloud” services, the approach I am recommending for my organization is that our “in the cloud” services cannot be PCI compliant in isolation of the broader customer system(s).

    What we need to provide is services that are compatible with PCI compliance so that the use of our services doesn’t “break” a customer’s PCI compliant status.

    As a service provider I don’t hold PII or card data on our customer’s behalf (I appreciate that some service providers do, but we don’t) and as such I would argue we are not subject to PCI compliance/certification requirements. Of course our corporate systems do process credit card data, but these are operationally separate from the customer services.

  6. Walt Conwayon 03 Nov 2008 at 8:30 am

    Great discussion and arguments. As someone who has been involved with PCI for a few years, I have to side with Hoff on this one. Martin is completely correct in that you can become “compliant,” but is that really the objective? We have to get out of the checklist mentality with PCI or we end up with *thinking* we have protected cardholder data when we have not. A checklist mentality will lead us away from the tough questions and give a false sense of comfort; we will fall back on outsourcing or other compliance-simplification approaches as panaceas rather than strategies.

    The objective is security. Yes, I know PCI is a data protection standard and not a security standard, but securing the data is still the goal. Spend on security and compliance is free…well, at least it’s easier.

  7. Martinon 03 Nov 2008 at 1:13 pm

    Walt,

    Part of the problem here is that Chris is arguing how things need to be to create a secure environment. I’m arguing about how the PCI requirements are as they currently stand and how they need to be enforced in the real world. The reality is that PCI IS a check list! I wish it was a risk based compliance solution, in which case almost everything Chris has stated would be true. But for now it’s a long list of specific technology solutions that have to be implemented, not a set of judgment calls on what is or is not secure in an environment.

    Martin

  8. lyalcon 03 Nov 2008 at 1:15 pm

    Isn’t the basic issue of the forgoing discussion to resolve addressed the beginning of the PCI compliance process:
    Scope is established by where is card data stored, processed or transmitted.
    If it’s a cloud environment, then the whole cloud should be included in the scope of the PCI review, unless it can be justified down in scope.

    While that may have unpleasant ramifications for some, I think most QSAs would/should be smart enough to follow that simple PCI concept.

    lyalc

  9. Martinon 03 Nov 2008 at 1:24 pm

    lyalc

    This isn’t a question of scope. Or at least only partially. The virtualized systems themselves would most likely be in scope, but the underlying OS and virtualization software would not be visible to the merchant and have to be addressed by contract rather than by audit. You can’t have each of a thousand merchants doing their own audit of the cloud vendor, the vendor has to undergo their own assessment.

    From the merchant point of view, it’s simple, get it in the contract. From the service provider view, this is a can of worms none of them is really ready to open as of yet.

    Martin

  10. [...] people are saying that cloud computing cannot be used because of a requirement for third party contracts, which they claim will never be achieved with large companies such as Amazon.  The claim is thus, [...]

  11. [...] Network Security Blog >> PCI Compliance in the Cloud: Get it in writing! Martin has written a article that you should read if you have any responsibility for PCI. [...]

  12. [...] an interesting article by Martin McKeay through “Security Bloggers Network” which discusses PCI compliance and the implications [...]

  13. Cranston Snoardon 04 Nov 2008 at 10:28 am

    It’s not just PCI that will get caught or need to adapt to cloud computing environments… SOX, privacy, and other compliance issues require similar attention in a cloud computing environment.

    Proper due diligence and risk analysis need to be part of the business case for a firm to adopt cloud computing. It may be that regulators et al will not allow use of cloud computing if one performs certain types of processing or handles certain classifications of data. Similar requirements for isolation exist elsewhere – such as handling of classified military data.

    On the other hand, everyone seems to overlook one of the easiest means of PCI compliance – simply don’t handle the card data unless you have to. There are lots of ways to do this – just get your head out of the clouds…

  14. [...] om hulp bij zijn transactieverwerking via Amazon’s EC2 platform. Dit werd onder andere opgepikt door Martin McKeay en eindigde eigenlijk in een [...]

  15. [...] PCI Compliance in the Cloud: Get it in writing!     Comment     RSS Feed     Email a friend [...]

  16. Jesson 27 Mar 2009 at 9:16 am

    A few have stated something to the effect of “don’t hand the cardholder data”…. or, that “amazon would not be holding the data, the VM would”. This is simply not true. For instance, an SQL database on a VM in the could, would still be sitting on hardware somewhere, and for all intents and purposes that VM is an application on said hardware. Which would require the underlying hardware/OS to be PCI compliant. What happens when the cloud is compromised, and an entire VM image is offloaded to the attackers machine? The attacker has ALL the data.

  17. Jackieon 04 May 2009 at 8:57 am

    Merchant Service Provider is a great new alternative to Paypal and Google Checkout.

  18. Jason Rushtonon 13 Aug 2009 at 6:02 am

    I realize I’m resurrecting an ancient post, but it was very enlightening when I was researching Amazon and PCI

    I just wanted to add that I did get an answer from Amazon stating that it is NOT possible to be PCI Level 1 certified using AWS services:

    http://developer.amazonwebservices.com/connect/thread.jspa?threadID=34960&tstart=0

  19. Martinon 13 Aug 2009 at 6:09 am

    Good to know Jason. And I’m glad to know that Amazon is acknowledging that they are not enabling merchants to become PCI compliant.

    Martin

  20. Markon 19 Aug 2009 at 4:51 pm

    Thanks for the information. Big news in Australia for cloud computing is Telstra have just announced a $500m investment into cloud services. Great news for the local industry.

Trackback URI | Comments RSS

Leave a Reply

%d bloggers like this: