RightScale Blog

Cloud Management Blog
RightScale 2014 State of the Cloud Report
Cloud Management Blog

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

Posted by Phil Cox   Ι   July 24, 2012

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.

4

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.

5

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

6

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

7

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

8

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.

9

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.

10

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.

12

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.

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.

Comments

Having been through this in the past without any clear guidance at the time, this post and the comments are highly valuable to anyone struggling with these issues. For me, the Cloud Provider and their true degree of compliance was key. The lesson- assume nothing, do the research as mentioned. Also, there is always the option of calling the payment provider directly - outside of your system - so the compliance issues are almost entirely thiers at that point. Thanks for writing this and I will make it part of my library on PCI DSS compliance with Cloud Providers.
A PCI Compatible VPC Topology: http://www.emind.co/ultra-secure-cloud-deployment-based-on-aws-vpc/
Had a couple of personal email regarding the "Listed Service Providers" and those that go through the rigor of ensuring compliance internally, but not the cost of hiring an external QSA. We are at the same point. I tried to get that across. So let me state it again, either of the two is acceptable to me: 1. On list of approved service providers **OR** 2. Willing to be transparent and help you adequately evaluate their compliance to PCI-DSS Do not dismiss a potential partner because they are not on the list. If you are going to dismiss them, do it because they are not transparent.
Posted by Phil Cox   Ι   July 24, 2012   Ι   08:51 AM
Phil, great piece. Well written in light of all of the public cloud bashing, and discussion on how you can't be 'secure' in a public cloud. IaaS is a particularly interesting example because of the shared responsibility, which ends at the hypervisor... How do you feel about making the statement that being COMPLIANT in a public IaaS cloud is "good enough" to be considered 'secure', based on your steps? I think you've provided more than just a checkbox outline for compliance, but rather a path to building a low-risk environment in a public shared IaaS - which is a fantastic thing. My one worry is as I pointed out on Twitter, in the very first paragraph you make the distinction between production and dev/test environments ... and state that you're making the assumption that dev/test won't have CHD - unfortunately all too often we find that not to be the case even though policy forbids it. What do you suggest organizations do to go beyond "thou shalt not use CHD in dev/test" and actually try and enforce this? May test systems require *real data* (or stuff that looks like real data) to adequately test - will something like DM (data masking) or TDM (test data management) systems work? Thanks, and great piece!
Response by Phil Cox   Ι   July 24, 2012   Ι   10:40 AM
Raf, Thanks. As to your "good enough", it is my stance that if you follow the intent of my comments, then: 1. You have reduced risk to an acceptable level (so yes to me "secure") 2. You can meet the requirements of PCI-DSS Note that I do not equate the 2 :) As for the test data. There are test PANs that can, and should, be used. If there is no PAN, then no CHD. If you pull prod back into test/dev, then you need a sanitizing process to replace real PAN with test ones. It is that simple. While there may be exceptions, that is the rule that should be followed.
Response by Josh (@iam_joshd) (not verified)   Ι   July 24, 2012   Ι   11:01 AM
First off, great post, really enjoyed reading it. Regarding Rafal's comment around production and dev/test environments... this is something that has always been a battle for me strictly around the functional design in some of the applications to provide users the ability to load their own data into Dev/QA. Although users are educated to not load production data into these systems, we all know things get rushed, not properly reviewed, etc... and production data tends to leak into these systems. I am now looking/hoping to have the dev teams construct an administrative option in the application's to specify whether data masking is to be performed during the data load/massage stage. For me, this would be the best solution so that even if applications are moved from production back to dev/qa then the switch can be simply turned on and off. Now there is also data that is "automatically" loaded into the dev/qa environments by these applications with no user-intervention. For these processes data masking is automatically performed before the data even reaches the application, so the moment it reaches the dev/qa environment then you can be sure it's masked. I also fully support and agree with the point around having a defined process in place on how to sanitize existing data, not just new data, as it traverses backward and forward. It should be part of the spec that is used when training users on data management.
Choosing the right provider is step #1. I have heard it said that, “PCI compliance should be the salesman of the year.” In other words, don’t just view PCI compliance as a “check box” prerequisite for entry, take that next step to better understand what the CSP in question is actually claiming when they state PCI compliance. What have they actually scoped in versus what is still the responsibility of you the customer? This demarcation line will also vary depending on the XaaS at hand, the higher up the stack, like a SaaS offering, the more the CSP is responsible for and vice versa for IaaS. So although it should be straightforward…PCI compliant, is not PCI compliant, is not PCI compliant. Ultimately it is you the customer that has to “face the auditor”, so you need to understand exactly what your CSP is claiming. Checking to see if they are posted as an approved service provider is an important first screening step. Then spend the time, buckle down and review their ROC in detail, to ensure you understand what you can rely on the CSP for and what you cannot. Note, I work for Dell and this is my opinion
Posted by Kevin Linderman (not verified)   Ι   July 24, 2012   Ι   11:24 AM
Response by Phil Cox   Ι   July 24, 2012   Ι   11:33 AM
Kevin, Good points. From a pragmatic stance, there are very few folks that will review the AWS RoC and understand the details. Larger folks, and those with QSA's on retainer can do that (need to get a copy of the RoC first). Getting a copy of the RoC has not typically been an easy thing to do, unless you are a large customer. For those of us that are not in the multi-millions of $ range, we are usually left with what is publicly available, hence "off the list" or "willing to show you the internals" are the only option for 90% of the PCI community. I know Dell has a Public Cloud IaaS offering, and I am in hopes that you can set the stage for transparency at the IaaS CSP level. Until all the folks, not just the ones paying bank, can get access to the detailed info, we are where we are.
[...] Cox (@sec_prof) described PCI Compliance in the Public IaaS Cloud: How I Did It in a 7/24/2012 post to the RightScale [...]
[...] make a path for others to follow, that the adoption rates will increase. I have attempted that with PCI in public cloud, and NASDAQ is forging with truly critical financial [...]
Hi Phil, Great post. The delineation of responsibilities between service providers and consumers of those services is well described. I think this delineation and the identification of shared responsibility for various controls is often missed when selecting service providers. Following on from the compliance of IaaS cloud offerings is the SaaS offering and the manner in which compliance can be ascertained for the cloud application stack as the cloud infrastructure management environment is all in scope and there's also the consideration of multi-tenanted systems. As for Raf's point on dev/test environments, where a business must use live data for test purposes, cloud infrastructure and the use of snapshots should allow the business create a separate stack with applicable controls in place to perform this function. However, test data (card numbers and other PII) is built to prove the requisite functionality without requiring production data. Andy Mac

Post a comment