Cloud Security Blog

I've spoken with quite a few folks that are having trouble wrapping their brains around how to achieve a PCI compliant environment within a public IaaS cloud. While the process can seem a bit daunting, it is actually not that bad once you understand the process. True the process is different than achieving compliance in a private data center, but with a proper task list you can work through the problem pretty efficiently.

Getting Started

In a private data center, you are 100% responsible for all PCI controls. In a public cloud however, your cloud service provider (CSP) will be responsible for some portion of these controls. Which controls and how many the CSP will be handling will vary by depending on the cloud service model you will be using. Luckily the PCI Cloud Guidance includes some extremely helpful information. Here's a copy of Figure 3 from that document:

Note that the first column lists each of our 12 main control categories from PCI DSS. The remaining columns identify responsibility based on the cloud service model you will be using. In this context "client" means you, while "CSP" obviously means the cloud service provider. When responsibility is labeled as "Both", this could mean that both the client and the CSP shoulder some level or responsibility for the control, or it could mean that complete responsibility may fall to one or the other. Remember that each public cloud varies based on features, so expect the "both" designation to be a bit fluid. However, this graphic is a great starting point to get a handle on what you will be responsible for.

Pick a CSP

Our next task is to select an appropriate CSP. We have two choices:

• Go with a CSP that is already PCI compliant
• Go with a CSP that is not PCI compliant

The first choice is by far the easiest. At least half of the compliance work will already be done; you just need to line up the proper documents for your auditors. The second option however is the reason the PCI cloud guidance ended up being such a huge document. This is the path that will cause you to question both your sanity and career choice. It is arduous, expensive, and at the end of the day you may find it to be an impossible task. In short, if your CSP is not PCI certified, your auditors will need to certify their environment as well as part of the process. Trust me when I say you don't want to go down this road if at all possible. So we're going to think happy thoughts and assume you go with option one.

Validate Compliance

So let's assumed you've shopped around and found a CSP that claims to be PCI compliant. The first thing you will want to check out is their Attestation of Compliance (AOC). This is effectively the CSPs proof that they are in fact PCI compliant. An even better document is to try and obtain their Report on Compliance (AOC). This is a report by the Qualified Security Assessors (QSAs) that certified the environment and will give you a better understanding of the compliance testing that was performed. The CSP may require that you be an existing customer and/or sign a non-disclosure agreement before they will let you view these documents. This is worth doing, as your auditors will require access to both as part of your audit.

Gap Analysis

Next you will want to receive a copy of the CSPs scope and responsibility documentation. Different CSPs may have different names for this document, but it is essentially a spreadsheet that lists out every PCI control. The CSP then fills in which controls they will take responsibility for, and which controls they expect their client to fulfill. Expect to sign an NDA before a CSP will share this document with you as well.

Let's look at an example. Check out this figure:

Here we have a scope line item for a fictitious CSP named "FUBAR Cloud Services". The specific PCI control being addressed is 9.1. Note the item includes a description of this control. What we really care about is the last column. Note that FUBAR is accepting responsibility for this control. So we have a bit of paperwork to organize that I'll cover in a minute, but essentially we don't have to worry about this control because the CSP is taking care of it.

Let's look at another scope example:

For this control the CSP is placing the responsibility for firewall management and design squarely on their clients. The last column states that clients must appropriately design their environment as well as create acceptable firewall rules.

Assigning Responsibility

Next, let's sort out responsibility as defined in the CSPs scope document. Each control that the CSP has accepted responsibility for (like 9.1 above) should be recorded in one list. Each control where the CSP has allocated responsibility to the client (like 1.3.1 above) should go in a second list.

For all of the controls in the first list, you'll need to hand your auditors a copy of the CSPs AOC, ROC and scope document. At this point you are done with all of these controls as they have been previously blessed by another QSA. The process is similar to how you handle a payment processor. If your auditor validates the payment processor has a valid AOC and ROC, your work is done. This is covered by the "Third Parties/Outsourcing" section on page 11 of the PCI DSS standard.

For all of the controls in the second list, you will need to prove to your auditors that you have met the requirements of each control. At this point the audit is not all that different than if you were working through an audit of a private datacenter. You may need to reference the PCI cloud guidance documentation to appropriately adapt a control to a cloud setup, but all the info you should need can be found in that document.

Summary

The process of achieving PCI certification in a public cloud is different than what we've dealt with in the past. For the experienced admin, security guru or auditor, this can make the process seem a bit confusing. Personally I find that taking it in baby steps makes life far easier. ;-)

--Chris Brenton