As a security consultant, one of the biggest misconceptions I see is companies that process credit cards but feel they do not have to meet the Payment Card Industry Data Security Standard (PCI DSS). This risky assumption gets exasperated with the adoption of public cloud. I’ve seen quite a few organizations that think they have “outsourced” that responsibility to someone else. To be clear, if you are accepting credit cards from your customers, it is 99.9% certain you have some level of culpability in meeting the PCI DSS requirements. In this series of blog posts I will walk you through assessing your exposure, reducing it when possible, and addressing controls that can be a bit of a challenge to comply with in a public cloud environment.
This blog post is intended to be a step by step guide in achieving compliance with the Payment Card Industry Data Security Standard (PCI DSS) in a public cloud environment. We will walk through where to even start and how to assess which controls are applicable to your organization. We will cover how you can reduce the scope of your attestation. From there we will move into how to perform a gap analysis on your public cloud provider’s environment in order to ensure all of the PCI DSS controls are in place. Finally, we will look at how to solve some of the more difficult controls which revolve around implementing network based intrusion detection within a public cloud environment.
Experiencing a credit card incident can feel like falling off a cliff. One day it is business as usual and the next you could have a clear line of site to bankruptcy. The repercussions can be financially devastating. Individual banks and credit card institutions may each begin fining you $5,000 to $100,000 a month for non-compliance. An increasing scale is used, so the longer the problem exists the greater the fines. Card institutions may even choose to no longer let you accept credit cards for payment. If a data breach is involved, there may be additional fines levied on a per transaction or per customer basis. If the event is made public, you will also have to deal with negative branding and the erosion of customer trust.
Note that this is experience is very different from most infrastructure problems. For example, if a server runs out of storage or a Web site starts performing slowly, a degradation is experienced that gives you time to react. You can delete files to free up storage which buys you time to increase storage capacity. You can put proxies or a Content Delivery Network (CDN) in front of the Web server giving you time to upgrade the hardware. Credit card incidents are very different in that once the problem becomes obvious you are already on a very destructive trajectory. This is why it is sometimes important to get compliance right from the start.
The first step in achieving compliance is understanding exactly how you are processing credit cards. Details matter here, so do not assume or guess. You will want security, development and operations expertise involved in this process. At a minimum, you should be able to answer each of these basic questions:
Knowing how many credit cards you process on an annual basis will allow you to determine if you require an external audit for compliance. If you are generating six million credit card transactions or more on an annual basis, you need to contract a Qualified Security Assessor (QSA). If you are below six million, you can perform a self assessment, by completing a Self Assessment Questionnaire (SAQ). While a self assessment is obviously cheaper, it is typically performed by less experienced individuals. This may mean that while you think you are compliant, you are actually not. Again, this may not be made apparent until some form of credit card event occurs.
The rest of the questions help identify the “scope” of the assessment. For example if we are storing raw credit card numbers in a database, then that database, the server it runs on, the network the server connects to, and all of the procedures used to maintain each can be considered “in scope” and required to meet all related PCI controls. If however we are storing tokens, then the database, the server and the network may be considered “out of scope” and thus require less scrutiny.
Now that we understand the systems and processes responsible for processing credit cards, we need to determine which Self Assessment Questionnaire (SAQ) is applicable to your environment. As of the time of this writing, the current version of PCI is 3.2. You may wish to check the PCI Security Council Web site to see if a newer version has been released. The chart in Figure 1 is from the PCI SAQ Instructions and Guidelines documentation. This identifies which SAQ documentation is applicable to your organization, depending on how you process credit card information.
Figure 1: This chart can be used to identify which PCI SAQ documentation is appropriate for your organization.
If you are an e-commerce site, here is what you need to know:
Our scope is going to define how many PCI control we are required to meet, as well as what systems and processes must adhere to these controls. This can have a huge impact on the amount of work required to achieve PCI compliance. For example assume we have outsourced credit card processing, but still store credit card information on servers located within an onsite data center. We would need to comply with SAQ D, which describes over 360 different security controls. This means we would need to be able to produce evidence that all of these controls are in place and compliant. These controls impact everything from physical security all the way up to security testing of our software.
Now let’s assume we decide to change our workflow such that all credit cards are processed and stored by our upstream processor. We will no longer store any credit card information onsite, but instead use tokens issued by our processor. In this case we may qualify to use SAQ A-EP for our assessment. This SAQ only describes about 140 controls. So just by changing where we store credit cards, we can considerably reduce the amount of work in achieving compliance. If we further stop rendering the payment page, and use an iFrame to let our credit card processor render the page for us, we may qualify to use SAQ A for our assessment. This will reduce the number of controls to 22. So one of the best ways to reduce the amount of work involved with achieving PCI compliance is to reduce our interaction with any credit card information.
Another method of reducing scope is to essentially outsource PCI responsibility to a third party vendor. This method is a bit controversial as it has only been an option for about five years. Some may argue that “you can’t outsource liability for protecting credit cards”. The argument is that if I entrust a third party with my customer’s credit cards, and that third party is compromised, I could potentially share in the liability for that breach. While the argument is technically true, from a practical perspective PCI immediately becomes irrelevant if this is ever enforced.
The PCI Council has built an entire infrastructure around supporting organizations that need to process credit cards. They keep track of Individuals and companies that are certified to perform audits, process credit card information and perform security scans. They even list approved software and hardware products. The entire system is built on trust, in that you are okay so long as you are working with PCI verified vendor. This is why one of the questions asked in the SAQs is:
“Merchant has confirmed that all third party(s) handling storage, processing, and/or transmission of
cardholder data are PCI DSS compliant;”
So what happens if that trust breaks down? For example let’s say a cloud provider who has properly received a PCI attestation as a service provider is compromised, and their customers are also found to be liable. If paying a premium to work with a PCI listed service provider yields no reduction in liability or risk over working with a non-compliant vendor, why spend the extra money? If organizations stop caring about PCI compliance in their service providers, why should the service provider invest the time and money into becoming compliant? See where this is going? This becomes a slippery slope into PCI no longer providing any value. So the bottom line is outsourcing PCI responsibility to public cloud vendors is fine, provided you do it properly.
When you outsource systems or processes to public cloud vendors, you essentially set up a shared responsibility model for meeting the security controls defined by PCI DSS. How much of that responsibility falls on you versus your vendor depends on the deployment model the vendor is using. Figure 2 shows the three cloud service models and roughly the point of responsibility delineation in each model.
Figure 2: The delineation of responsibility between tenant and provider in each of the three cloud service models.
As an example, PCI defines a number of physical security controls. It also identifies how network and server hardware is to be secured. If you locate your in scope servers within a room at your office, you are responsible for meeting each of these controls on your own. However, if you are working with a cloud vendor, they would assume the responsibility for those controls, thus reducing the work you need to perform in order to be compliant.
Note that even with the SaaS model you cannot completely outsource all of your responsibility for PCI compliance. There will always be some number of controls for which you need to assume responsibility.
Also note that the line of delineation is a bit fluid when it comes to PCI. For example in the above Figure, IaaS cloud providers are responsible for everything from the hypervisor on down. PCI DSS control 11.4.a requires that a network based intrusion detection system be used. Most IaaS cloud providers will not assume responsibility for this control. So even though the “Network” layer is clearing below the line in Provider territory, you will need to implement that control on your own. Later, I’ll provide some tips on how to meet this specific control within a public cloud.
So let’s assume you want to leverage a public cloud to reduce the amount of work involved in meeting all of the PCI controls. You’ve identified the systems and processes that are involved with processing your customer’s credit cards. You would like to move these to a public cloud environment in order to shift responsibility for some of the controls to the provider.
You first need to check to ensure the cloud provider is PCI DSS compliant. You can usually find this information on one of their sales or security pages. PCI DSS compliance is a selling point, so the provider will use compliance with this attestation as a marketing tool. Be careful here, as the vendor’s PCI attestation may not apply to their entire environment. For example Amazon has achieved a PCI DSS attestation for their AWS EC2 environment. However at the time of this writing, they do not yet have one for their AWS Lambda environment. So to ensure you are compliant, all of your resources would need to be running within EC2.
You will need to ask your vendor for two documents. The first is their PCI DSS attestation. Make sure their Attestation of Compliance (AOC) is as a service provider, not a merchant. These are two different documents with two different use cases. The second document is their Report on Compliance (ROC). This documents the provider’s compliance status for each PCI DSS Requirement. Some vendors may also include a scope and responsibility document which is essentially an easier to read version of the ROC.
You can typically get these documents through the provider’s sales or support personnel. It is not uncommon for a vendor to first insist that you be a customer in good standing and that you sign an NDA prior to them releasing the documentation. This is a common practice as the documents include sensitive security information.
First, check the date on the PCI DSS attestation. Attestations are good for one year. In fact you may want to set a reminder to talk to them annually to ensure you always have their latest attestation on file. Next, you will need to perform a gap analysis on the ROC and scope and responsibility documentation id one was provided. These documents will define which PCI controls the vendor is accepting responsibility for, and which controls will be the responsibility of their customers.
For an example, please see Figure 3. Note that the specific PCI DSS control will be referenced, as well as a brief description of the control requirement. The provider will also include a description of whether they are assuming full responsibility for the control, or if the customer maintains some level of responsibility. For example in the Figure the provider is specifying that while they will provide a compliant firewall, the customer is responsible for deployment and management of the firewall.
Figure 3: PCI scope and responsibility example. This document identifies the PCI controls for which the vendor will accept responsibility, and which controls must be maintained by the customer.
Once you complete your gap analysis, you need to implement each of the controls not covered by your vendor.
Earlier I mentioned that PCI DSS control 11.4.a specifies that a network based intrusion detection system be in place. Controls 10.6.1 and all of 11.4 do so as well. Further, controls 1.1.3, 12.3.3, 12.5.2 and many of the 10.x controls can also be satisfied by a device that monitors network traffic flow. However we have a bit of a quandary. In a public IaaS environment, the provider manages the network layer. This makes it extremely difficult to monitor packets on their network. There is no public cloud equivalent to span or mirror ports. While we could route all traffic through a dual homed server running network based intrusion detection software, this introduces latency and causes availability concerns.
One of the easiest solutions is to simply process any network flow data the vendor makes available. For example, Amazon makes VPC flow logs available to their EC2 customers. While these are recorded in a non-standard format, it is possible to convert them so the data can be easily monitored. Alex Barsamian has written a great article on how to retrieve and convert VPC flow logs to IPFIX format. However, there are a number of ways to attack this problem, which I will cover in my next blog entry.