PCI Compliance in the Public IaaS Cloud: How I Did It

You’ve reached an archived blog post that may be out of date. Please visit the blog homepage for the most current posts.

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 and understands cloud governance 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” or cloud governance 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 cloud governance and 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.

ReqDescriptionMy Summary
1Install and maintain a firewall configuration to protect cardholder data
  • Rely on CSP for HW->Hypervisor related compliance.
  • Design the application and communications flows so they can be secured.
  • The state of networking features make cloud “different” than traditional environments. This will have an affect on how you provide isolation for scoping. Currently host-based firewalls or similar hypervisor based technology are the most likely solutions to implement appropriate restrictions. It is what I use.
  • Review/audit regularly to make sure design and implementations have not changed. Since hosts come and go more frequently, so the need for regular review is increased. One nice aspect of the cloud is that since automation is part of the DNA, automation of these reviews is easier.
2Do not use vendor-supplied defaults for system passwords and other security parameters
  • Rely on CSP for HW->Hypervisor related compliance.
  • Make sure to change the defaults- I use RightScale ServerTemplates™ to enforce this, as well as provide version control of configurations.
  • Note: The cloud actually helps you with in this area (usually), as you should have had to think how to build systems. There is not “throw in the CD, plug in the cable, and leave it”. So you should have a leg up in this area when using a cloud technology.
3Protect stored cardholder data
  • Rely on CSP for HW->Hypervisor related compliance.
  • Gets down to not storing what you don’t need, good crypto selection, and proper key management.
  • For non-DB-based encryption, use of a third party like TrendMicro SecureCloud (or similar) is a big help here.
  • Note: Cloud really is not an issue here, as you have many of the same concerns in a managed hosting environment. The main difference is between owned or third-party infrastructure.


Encrypt transmission of cardholder data across open, public networks
  • Rely on CSP for HW->Hypervisor related compliance- Use SSL to the Load Balancer, private network behind that.
  • Use well-vetted VPN if linking networks.
  • Note: No huge difference between cloud or hosted here. The cloud issues in this area are more around maturity of the networking stacks (e.g., arguably easier to slap in a physical VPN concentrator and hookup networks). This will change as the technology matures.


Use and regularly update anti-virus software or programs
  • Rely on CSP for HW->Hypervisor related compliance
  • Not much specific to a “cloud” deployment, except that servers come and go more frequently, so you need to make sure the AV solution is operating correctly. If I had Windows systems for servers, I’d be using RightScale ServerTemplates to make sure things were configured correctly
  • Note: Nice aspect of the cloud is that since automation is part of the DNA, automation of this should actually make it easier to meet the requirements


Develop and maintain secure systems and applications
  • Rely on CSP for HW->Hypervisor related compliance
  • The “what” (securing systems) is not really a “cloud” specific problem, but the “how” is. I use RightScale ServerTemplates and built in versioning to makes it easy and provide change tracking. You can choose how you want to do it, just do it
  • Note: Nice aspect of the cloud is that since automation is part of the DNA, automation of these should actually make it easier to meet the requirements


Restrict access to cardholder data by business need to know
  • Rely on CSP for HW->Hypervisor related compliance
  • Again, not the “What to do” that is the issue, but “How to do it”. I use the Role-Based Access Control (RBAC) and ServerTemplate features of RightScale and a strict provisioning policy to get this done. You can choose any method that works
  • Note: Really no different than a hosted environment


Assign a unique ID to each person with computer access
  • Rely on CSP for HW->Hypervisor-related compliance.
  • Another “Not What but How.” You guessed it: I use a combination of RightScale, policies, and regular audits. You can choose any method that works within your cloud governance guidelines.
  • Note: Really no different than a hosted environment.


Restrict physical access to cardholder data
  • Rely on CSP for HW->Hypervisor-related compliance.
  • You need to worry about user systems and any hard copy.
  • Note: Really no different than a hosted environment.


Track and monitor all access to network resources and cardholder data
  • Rely on CSP for HW->Hypervisor-related compliance.
  • Use RightScale to configure systems and send local system and application logs to central log server. You can choose any method that works for you.
  • Note: Public cloud does make this different. The lack of transparency into some of the devices you don’t have access to (e.g., hypervisor logs) needs to be taken into account.
11Regularly test security systems and processes
  • Rely on CSP for HW->Hypervisor -related compliance.
  • I do internal as well as third-party testing.
  • Note: Coordination with the CSP when doing testing may be something that is new and require modification of your process.


Maintain a policy that addresses information security for all personnel
  • Rely on CSP for HW->Hypervisor-related compliance.
  • Ensure policy states the requirements for need to know access to CHD.
  • Ensure that if you share CHD with others, contracts state they must protect CHD in accordance with PCI DSS.
  • Have an incident response plan and make sure it works!
  • Make sure you have appropriate policies and can prove that you are doing what they say.
  • Note: The policies need to exist with or without the cloud. The biggest difference here is ensuring appropriate language is included in contracts.


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.