Achieving PCI compliance can be a complex, time-consuming, and expensive undertaking, but the right approach can make it substantially less burdensome. In this brief paper we provide some critical background and recommendations intended to help you make the best possible decisions regarding PCI for your PaaS-based application. If you currently accept, or are contemplating accepting a payment card on your web application, this document is for you.
Many of the applications running on Engine Yard are primary revenue sources for their owners. While some companies monetize these applications via advertising, many of them deliver premium services or process transactions that require payment from the end-user. To facilitate these transactions, applications must provide a payment mechanism, and in the online world these transactions are often conducted using payment cards (cards or devices that bear the logo of American Express, Discover Financial Services, JCB International, MasterCard Worldwide, or Visa, Inc. 1 ) Given the potential for fraud in the fast-moving, often-anonymous environment of the Web, it is not surprising that there is substantial regulation and oversight of payment card use designed to protect both companies and consumers. “PCI DSS” is shorthand for the Payment Card Industry Data Security Standard, the regulatory body and standard for ensuring that the use of payment cards is as secure as possible.
PCI certification is required for any organization that processes, transmits, or stores cardholder data. This includes merchants and service providers. The certification is designed to safeguard payment card data from theft through increased controls and processes over how the data is handled and protected. The standard applies to all organizations that hold, process, or exchange payment card information from any branded card. If a company’s systems handle a payment card number, even if it is just for a brief moment (e.g. customer types credit card into the company’s web form; company stores credit card in memory; company sends credit card to payment processor; company deletes credit card from memory), the company is required to be compliant. The number of requirements necessary to be compliant is the same no matter how many payment card transactions that you process, however the attestation approach will be different based on your annual volume.
To achieve certification, a company must first understand and document its cardholder data environment (CDE), including all systems that process, transmit, or store payment card numbers. Along with these primary systems, the organization must take note of all other support systems that may interact with the CDE (e.g. security monitoring, key management, LDAP, etc.), as well as all other systems that may not be directly involved in the payment card transaction, but which are not separated by network controls. In general, if a particular system interacts or can reach the CDE, that system needs to be documented. Once documented, the network diagram will guide the organization’s PCI scope. With the scope defined, the company must ensure that specific control activities are designed and operating effectively for PCI’s key security objectives:
The type of testing required, and the level of assurance to be demonstrated is related to the number of payment card transactions executed annually:
|Merchant Level||Merchant Description||Requirement|
|Level 1||> 6,000,000 transactions per year across all channels, including e-commerce||
|Level 2||1,000,000 – 5,999,999 transactions per year across all channels, including e-commerce||
|Level 3||20,000 – 1,000,000 e-commerce transactions per year||
|Level 4||< 20,000 e-commerce transactions annually and < 1,000,000 transactions per year across all channels||
Achieving PCI certification is difficult for many reasons:
According to Verizon’s “2011 Payment Card Industry Compliance Report”3 on PCI, “only 21 percent of organizations were fully compliant at the time of their Initial Report on Compliance (IROC).” In our experience, PCI compliance is often expensive, difficult, time-consuming, and simply cannot be successfully tackled as a one-off project. PCI is not something that can be “crossed off the list” once you attain your initial certification. If you are going to tackle PCI compliance, the effort must be a part of your ongoing compliance program in order to maintain a successful year on year certification.
There are two fundamental paths a merchant can take to achieve PCI compliance for an ecommerce application. The first, which we highly recommend, is to outsource all payment card data handling to a compliant third-party thus greatly reducing your compliance burden. The second path, achieving PCI compliance directly, is best attained through technical solutions that focus on reducing your compliance scope.
First, you should rigorously evaluate your cardholder data handling needs and practices. Ask yourself:
Depending on the results of this evaluation, consider streamlining or altering payment or other processes in order to reduce the number of payment card data repositories and systems that are need to be compliant. Modifying these business processes to not collect and retain PCI-relevant data can have a significant impact on scope reduction, and lowers your overall risk profile.
Due to the demands of PCI compliance, most of the traditional payment processors, along with a number of technology companies, have pushed heavily into offering up full or partial outsourcing models for payments. These include:
If outsourcing will not work for your business situation, the alternative is to attain PCI compliance directly. Realize that no matter how well attested and compliant the platform and infrastructure underneath your application is, you still will be responsible for drafting a Report on Compliance. Thus, no IaaS or PaaS provider, including Engine Yard, can achieve compliance on behalf of a customer. Rather, what a cloud provider can do is maintain effective security architecture and supporting security management practices such that they do not prohibit you from meeting your compliance obligations. For example, PCI requires that all interactions with the Cardholder Data Environment (CDE) be logged. In order for you to meet this obligation, your cloud provider would be required to log the interactions of their employees against your systems, and be able to demonstrate this to you or your Qualified Security Assessor (QSA). Additionally, you will want to consider if the cloud provider’s architecture supports a PCI compliant solution, and if so, how? For example, what considerations would need to be made if your cloud provider deploys with a multi-tenancy versus single-tenancy approach?
Depending on the architecture, you may need budget time and money to develop compensating controls.
As stated earlier, if you prefer to not utilize an outsourcing approach, you should direct your attention to scope reduction. You can consider a variety of technical options; however note that none of these will reduce the PCI requirements, just lessen the number of systems and applications where the requirements may apply. These approaches include:
Segmenting the CDE from the remainder of the corporate network is not a PCI DSS requirement, however it is recommended as a method to reduce PCI scope, cost, and risk. Proper network segmentation can ensure the following:
Organizations can create segmented networks using a variety of methods including network-based controls (e.g. FWs, VLAN or ACLs), logical partitions (LPAR), or virtual segmentation.
Network segments must be locked down such that only traffic that has a business justification is allowed into or out of the defined PCI network. This includes validating that:
Payment tokenization is the process of substituting sensitive cardholder data (i.e. the Primary Account Number) with a unique, non-PCI relevant surrogate value (or token). Cardholder data cannot be derived from the token, as the token is generated using an additional element other than the account number. The only association between the cardholder data and the token is through a reference table stored in a secure repository. With the exception of the first six digits or the last four digits of the Primary Account Number, the cardholder data is never in clear text form on any system outside of the entry point and the tokenizing application. Payment tokenization can be performed in-house, and developed as an Enterprise service, or it can be outsourced through a secure payment gateway.
Point-to-Point Encryption is the encryption of cardholder data from one point (e.g. the point of input or acceptance) to another point (e.g. a point beyond the merchant or accepting entity’s network). The information traveling between two points is encrypted, and the merchant does not have access to the decryption keys or process.
In summary, before moving forward with PCI, take a moment to consider your business processes, your compliance goals, and what opportunities may exist to either fully outsource the payment process or reduce your scope. Taking the time to perform this analysis can save you a lot of pain later on.
As Cloud adoption has grown from niche uses, to larger scale operations, security and compliance concerns have also trended upwards. Initial reaction to compliance in the Cloud usually was best summarized as, “No chance”. However, security processes and technologies continue to mature, and the security of the Cloud has caught up, if not surpassed, what can be provided within a traditional data center environment. With that said, the PCI burden will remain extensive whether you decide to move your payments to a Cloud environment or not.
With the Engine Yard PaaS model, Engine Yard and its customers maintain joint responsibility for aspects of security. For example, both our support organization and our customers have the ability to perform super-user level functions on specific instances. Additionally, both parties have the ability to provision accounts that can access these instances. To maintain compliance, Engine Yard and its customers need to ensure that accounts that have access to the customer’s instances are appropriate, and that there is a defined process to procure and remove access. You should work with your PaaS to understand the delineation of security responsibilities, and what their security management processes are.
Additionally, have an open dialogue with your PaaS about the state of security on their platform. Cloud security is an evolving field, and your PaaS provider should have a point of view and a vision. Evaluate:
Engine Yard provides multiple platforms that can grow with your organization. Through our design, we provide a number of security controls that help to keep your application protected. We listen to our customers, participate in the cloud security community, and continue to develop and evolve our platform to meet your security needs. When considering compliance in your current cloud provider, or considering moving to a Cloud environment, consider both the inherent security benefits of the Cloud, but also the security design and process decisions the PaaS provider has made. Engine Yard’s strengths include:
Your business is on the Web either because it is either fundamentally a new type of offering that is uniquely enabled by the Web or because the Web is the best way to market and/or deliver your offering. In either case, you need to make money and be paid for your offering, and often there is no better way than the fast, selfservice payment card transaction. Depending on your payment strategy, there are a number of ways to address PCI compliance. We look forward to working with you to find a solution that meets your needs on the Engine Yard