Over the past few years, I have heard many folks assert that one can be a PCI-compliant merchant using public IaaS cloud, and I have heard just as many state that it's not possible. In retrospect, I have found most of them - including myself - to be misinformed. After gaining more firsthand experience, I feel confident telling you where I sit at this state in the game on the question: “Can I be PCI compliant using a public IaaS cloud?”

To cut to the chase: The answer is yes, and the hardest part is knowing what you need to do, which I want to help you with here. I am a former Qualified Security Assessor (QSA) and have participated in multiple PCI working groups. As the Director of Security and Compliance for RightScale, I can speak for where we see things, but the information, processes, and opinions I express here are mine alone and are not intended to represent any guidance from the PCI Security Standards Council (SSC) or any card brand.

I’ll first talk about foundational principles and mindsets, then go through each PCI Data Security Standard (DSS) requirement and I’ll give you my “How I did it.” Note that you may disagree, and that is fine. A healthy discussion on this topic is beneficial to everyone! So with that, let's get started.

Setting the Foundation for PCI Compliance

You will need to understand some foundational assumptions and working rules I go by. First, here are three environment assumptions/guidelines:

1. All Cardholder Data (CHD) will be housed in the IaaS provider. There is no other managed hosting or physical system in the design.
2. The application is structured into 3 tiers: Load balancer, app server, DB server.
3. Dev and Test are separate and have NO CHD, and thus are outside of Cardholder Data Environment (CDE). Thus the design only deals with production systems.

And the foundational assumptions/rules:

1. You will need to choose an IaaS Cloud Service Provider (CSP) that:
   1. Is on the “Approved Service Providers” list for one of the major card brands (for example the VISA list). If they are not listed, but have done a Level 2 assessment and can show you their Report on Compliance (RoC), that may suffice, depending on your situation.
   2. Will sign a contract that states they must protect CHD in accordance with PCI DSS to the extent it applies to them. This is basically covered if they have done (A) above.
   3. Note: The reason you need a PCI compliant IaaS CSP is because they control the physical systems up to, and including, the hypervisor. They will be responsible for the PCI DSS compliance of that part of the stack.
2. Find a QSA who knows cloud technology or determine if you have the knowledge internally. Note that IMHO very few organizations have the depth of knowledge needed in this area, and will likely get it wrong if they don't get help.
   1. A good choice is the QSA who did the assessment for your IaaS CSP.
3. Design your application.
   1. Do not store the Primary Account Number (PAN) if you do not need it. Many payment processors have mechanisms for recurring billing or credits. Depending on your situation, it is highly likely that you do not need to store the PAN, thus making your life significantly easier from a PCI DSS compliance standpoint.
   2. If you are going to store PAN, then the design of crypto mechanism and, more importantly, the key management of data in the DB, is critical. This is really not a “cloud” thing, and is dealt with in any PCI application that stores CHD.
   3. Terminate SSL/TLS at the load balancer and run all other traffic over the private interface/network. This assumes that the “private” interfaces have been designed to meet the definition of “non-public” as far as PCI DSS. This is the case with Amazon Web Services. Traffic between the private IP addresses can be considered a private network and not require encryption. This does not mean that you can’t or shouldn’t do it, just that you do not have to in order to meet PCI DSS requirements.
4. Use host-based firewalls for isolation on the individual virtual machines.
   1. Using “security groups” or other hypervisor-based filtering is likely acceptable, but I like the control of the firewall at the host. Use them both if you want, but be careful of conflicts.
   2. I’d recommend using a tool such as CloudPassage to manage the firewall rules. This gives the separation of duty that PCI DSS requires, and will make achieving compliance much easier.
5. I recommend using an IaaS cloud management solution. In my case, I am managing my PCI environment with RightScale, so some of my descriptions are based on that solution, but the principles I use can be applied regardless of the tools you use.
   1. Disclaimer: The RightScale platform has not undergone a Level 1 assessment, and thus is not on the list of “Approved Service Providers.” I use the fact that RightScale has the available documentation to help me “prove” that the SaaS Platform meets the PCI DSS requirements (using my previous QSA experience). Simply, our ability and willingness to be transparent and helpful in the assessment is key.

How to Determine Scope and Requirement Applicability

I use the following questionnaire for each system/application to determine what is in scope for my PCI assessment:

1. Does the system “store/process/transmit” a Primary Account number (PAN)? If yes, in scope.
2. Can the system be used to “directly manage” (i.e., make changes) on a system component in #1? If yes, in scope.
3. Does the system provide ancillary services (e.g., DNS, NTP) to a system component in #1? If yes, in scope.
4. Is the system segmented? Host-based firewalls restrict all other traffic, so out of scope.

Once I determine that a system/application is in scope, I use the following questionnaire to figure out what requirements need to be met by the component:

1. Does it ”store/process/transmit” a PAN? Then review the system component in view of all requirements (1-12). Example is front-end web server.
2. Can it be used to directly manage a system component in #1? Then review in context of Requirement 1, 2, 4, 5, 6.{1,2,4}, 7, 8, 10.{1-7}. Example is RightScale.
3. Does it provide services to a system component in #1 and do I own/manage it? Then review in context of Requirement 1, 2, 4, 5, 6.{1,2,4}, 7, 8, 10.{1-7}. Example is central log collection system.
4. Is it a 3rd party that provides services to a system component in #1 and I only have a SaaS/API interface to it? Then rely on contracts and review my configuration setting in context of Requirement 7, 8, 10.{1-7}. Example is DNS service.

Note: A realistic working definition of “connected to” (as defined in the PCI DSS) has never been made IMHO, so I used a pragmatic/risk-based definition in my scoping process. At some level, only an air-gap would suffice, which is ridiculous.

The Top-Level PCI DSS Requirements and Public IaaS Cloud

I’ve listed the 12 top-level PCI DSS requirements along with a brief “gist” of how I did it (or would do it if it applied) for RightScale. The full document is 37+ pages - too long for a blog post. The good news is that you can get the full paper here on PCI DSS requirements and public IaaS cloud.

Summary

Having worked with a number of customers on their PCI compliance strategy, I am definitely of the opinion that you CAN be PCI compliant operating in a public IaaS cloud. A lot of the work to get there is actually relatively standard and the hardest part is knowing what you need to do and what you have to rely on your partners to do.

As is common practice, you need to have proof for what you assert. When it comes to partners, you have two mechanisms to get assertions from the partner: They can get onto the list of PCI approved Service Providers or they can be transparent and willing to work with you to document their compliance adherence. In reality, both options require you to do your due diligence on the partner, one just makes it a easier in some regards.

The other key aspect of PCI compliance is making sure you manage the system components correctly. The industry knows how to manage traditional environments, but the nuances of public IaaS cloud can make mistakes more egregious. Thus it is critical that you manage the systems components correctly. I believe that the functionality that RightScale gives me in terms of management and governance of system components is invaluable (otherwise I would be working elsewhere). With that said, there are other management options (other vendors, do-it-yourself, or a combination) that you can leverage to make it happen. Just make it happen.

PCI compliance in a public IaaS cloud is a very touchy subject, and it should not be. This is my attempt to shed some light on an area that I think has too much mystery around it. I hope you find it useful.