I have written about PCI compliance on several occasions over the past two years. The Payment Card Industry (PCI) Data Security Standard (DSS) is the worldwide information security standard for organizations that handle cardholder information for debit, credit, prepaid, e-purse, ATM and point-of-sale (POS) cards. The sole purpose of these standards is to reduce credit card fraud due to the exposure of the sensitive information contained on the card. This information is printed, encoded in the magnetic stripe, or in some active or passive embedded device (e.g., RFID chip) on the card. This information is necessary to complete the financial transaction, and when stolen can be used to commit that fraud. Based on the volume of such transactions, organizations must have an annual audit by an external Qualified Security Assessor (QSA) or by a Self-Assessment Questionnaire.
Each card has a 16-digit number on the front called the PAN (primary account number). If your organization stores, processes or transmits the PAN, then you must be 100% PCI compliant 100% of the time. Failure to be compliant can be expensive, with an average cost to your organization of over $200 per lost record, plus the potential of significant fines and lost good will.
Because of the nature of the DSS requirements, I have been counseling organizations subject to PCI compliance to either eliminate their requirement to be PCI compliant, or ignore the Cloud as an opportunity for that processing.
It turns out that many companies handle the PAN for no good reason. In many cases, it is because of history: when they started out they were handling the order screens themselves and thus had the PAN at least moving through their systems and therefore were required to be PCI compliant, even though they never actually stored the PAN. Other companies have stored the PAN either to make recurring payments easier for them, or with the really bad idea of using the PAN to identify a customer. Never use any identifier created by a government or financial entity as your internal customer id. It exposes you to far more security risk than you can afford to deal with. Even small companies can accept credit cards for on-line payments with no PCI exposure through companies like PayPal, and several companies (including PayPal) offer credit card readers and software for smart phones that are PCI-DSS compliant.
Note that using one of these smart phone credit card payments options does not remove your PCI compliance requirement – you are still handling the PAN. Your employee is holding and can see the card, and the PAN is transmitted through your device. However, unless you are the size of Apple with over 300 stores each averaging 75 employees and doing over US$30M per year, you should be OK with a relatively simple self-assessment questionnaire. Your primary security issues are training your staff on the security requirements and procedures to handle the card, and confirming the certification status of the reader and software you are using with the device vendor(s).
Even though I have been preaching that the Cloud is constantly evolving, and what should not go in the Cloud six months ago might be OK today, I was surprised to see a webinar by Phil Cox sponsored by RightScale that talked about being PCI-DSS compliant in the IaaS (Infrastructure as a Service) Public Cloud.
Phil is currently the Director, Security and Compliance, at RightScale. He has been on all sides of the PCI compliance issue, with years of experience as a QSA and as a merchant, as a contributor to the PCI virtualization supplement, and as a member of the PCI Cloud SIG (special interest group).
Why would you want to go to a Public Cloud in the first place?
- To save a lot of money, and only pay for what you use.
- To gain significant agility, the ability to grow or shrink your infrastructure to almost any level in minutes to match your current requirements.
- To get rid of some of the aggravation of running an IT infrastructure securely and reliably. Often, companies get a significant security boost by moving to the Cloud because most Cloud Service Providers are really good at managing IT – it is their core competency.
Importantly, there is no guidance from the PCI Security Standards Council as to how their requirements and controls are to be met and validated in a Cloud environment. Many PCI-DSS experts that I have talked to believe that almost by definition you are not compliant if you are using the Cloud. Yet there is actually no mention of the Cloud in the PCC-DSS.
There are many important steps to moving your PCI processing to the Public IaaS Cloud. Here are four to think about initially.
- A good rule for designing a system involving PCI data is to keep it simple, independent of the environment. The fewer parts, the better. If your cardholder data is scattered in multiple applications on multiple servers in multiple physical locations, you will have a very difficult time proving you are PCI compliant. In general, you want your cardholder data only in one place. When you move to the Cloud, put all of your cardholder data in your Cloud provider, don’t leave any “at home.” Part of achieving simplicity is to completely separate your development and test (dev/test) environment from your production system and include absolutely no real cardholder data in your dev/test environment. This means your dev/test environment is completely outside of the area that needs to be compliant, and you only need to worry about your production system. It also means that your test cardholder data is manufactured, not simply a transformation of some real cardholder data. It must be impossible to recreate any actual data from your test data.
- Choose your Cloud Service Provider carefully. Ideally, they will be on the “Approved Service Providers” list for one of the major card brands. If they are not listed but have done a Level 2 assessment and will share their Report on Compliance they may be acceptable. Check with your QSA. Alternatively, have them sign a contract that they will protect cardholder data according to the PCI DSS to the extent that it applies to them. Again, let your QSA guide you.
- Choose your QSA carefully. If they do not understand the Cloud in general and Public Cloud IaaS in particular, they will likely fail you in one of two ways: either by simply saying “no” to the Cloud, or certifying you when you really do not have everything in place to be compliant.
- Keep your stakeholders informed. Many Cloud implementations fail not because they were badly implemented, but because someone with a title in the organization stopped it. The way to prevent that, or at least determine you are trouble before you have spent a lot of effort, is to get your stakeholders involved early, listen to their concerns, address the issues, and keep the stakeholders informed throughout the journey. At a minimum, your stakeholders are your CEO, CFO, CIO, the head of information security, the person in charge of internal audits, your QSA if you have one, and your legal department.
A few years ago I attended a Cloud Symposium sponsored by a major player in the Cloud space. One question from the audience was, “What about Amazon as a Cloud Service Provider?” The Cloud expert on the panel responded with, “Would you trust your business to a bookseller?” That generated a laugh. But, think about it. The Amazon IT infrastructure is designed to routinely handle up to 500,000 transactions per second, and has peaked at close to a million transactions per second. Their 2011 revenue was about the same as eBay plus Google, and more than twice TJX, which includes the TJ Max, Marshalls, and Home Goods in the US. That is essentially the infrastructure you are running on when you use AWS, the Amazon Cloud. Not surprisingly, AWS has achieved PCI DSS Level 1 Compliance. This is the highest level, applying to merchants processing over six million transactions per year.
For more information, I suggest you read Phil’s “How I Did It” blog.
Compliance, unfortunately, does not equal security. Every year we hear about companies that had just passed their internal or external PCI audit and were still hacked. But companies seem to be getting much better at being secure as well as being compliant. Last year only 4% of organizations that lost PCI-protected information to cybercriminals were certified, down from 21% just two years earlier.
We are only considering PCI compliance in this post. Even if you do not handle the PAN and are not responsible for PCI-DSS compliance, you may still have information that subjects you to government privacy and other compliance requirements.
No matter how you handle it, security is your responsibility. If something goes wrong, it is your problem to fix, your fines to pay, and your customer relationships that are damaged. Your CSP will likely help to investigate the problem, but the CSP will not take responsibility nor accept any liability. Make sure you and your own security and compliance team are satisfied with your total PCI-DSS compliance status, including your partners.
The last word:
I will be giving a free one-hour Cloud Security webinar as part of the Arrow ECS – IBM Business Partner webinar series at 2PM EDT on Tuesday, 9 October. You may register if interested.
Comments solicited.
Keep your sense of humor.
Walt.
