PCI compliance anxiety ratchets up

In the last few weeks our office phones have been ringing with calls from clients concerned about PCI compliance. A mounting realization that enforcement of these credit card standards is indeed coming, the October deadline to use compliant applications, and widespread confusion about what the standards are and who they apply to, is bringing the issue of credit card security to a boil. [UPDATE: I've created an entire page of PCI information at: http://membersonlysoftware.com/pci ] The background: PCI is an association of the major credit card issuers. The PCI Data Security Standard (PCI-DSS) is a list of twelve security requirements that merchant account holders must meet. According to the standard, "PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply." In other words, if you ever send a credit card number through to the bank for processing, you've got to pass muster. Validation of compliance may require an on-site audit, or may be done by self-assessment and a notarized attestation. And while 12 requirements does not sound like much, the sub-points of each requirement make it clear that the standard affects pretty much every aspect of your IT system and your payment processes. The biggest misconception we see among our clients is the idea that if they are using the right credit card processing system or software, they are compliant. Of course there are requirements that payment applications must meet. Failure to use compliant software is a sure path to flunking your compliance audit. But using compliant software does not begin to guarantee that you the merchant are yourself compliant. The entire security of your computer system comes under the purview of the PCI. In addition, any paper systems that might contain account number data are also involved. Failure to use compliant software is a sure path to flunking your compliance audit. But using compliant software does not begin to guarantee that you the merchant are yourself compliant. Let's look at one example. Requirement #1 reads "Install and maintain a firewall configuration to protect cardholder data." You might think the fact that you have an industry standard firewall product installed gets you a pass on this one. But that is just a starting point. The requirement's details indicate that you need a written policy on how any change to the router or firewall configuration is approved and made. a network diagram that shows all connections and all devices and a process to make sure the diagram is up to date. documentation of the business case for all ports that are open and all protocols that are in use. a formal review of all firewall and router settings every six months. But back to the your software applications. Requirement 6 simply reads "Develop and Maintain secure systems and applications." How is secure defined here, and how do you prove it in a PCI audit? Software applications that are sold "off the shelf"" can apply for the PA-DSS certification. (The Payment Application Data Security Standard - this is a separate standard governing just the software that management credit card payments). Software that is customized for a user organization cannot receive the PA-DSS designation. Instead custom software comes under the scope of each user's PCI compliance audit and may require a code review. The best solution for a customized application is for it to avoid ever coming into contact with a credit card account number, and simply delegate all card handling to a certified PA-DSS compliant application. This is a bigger deal than you might think. For example, if you want to capture the credit card number for a donation in page you have carefully designed and branded, you will need to code review and validate this page as part of your compliance even if all it does is pass this number to a PA-DSS certified payment app. But your greatest exposure arises if you store credit card numbers for any reason after the moment of the transaction. For example, many non-profits charge sustaining donors' pledges against their credit cards on a monthly basis; YMCA's often charge for their dues this way. The requirements for protecting credit card data of this sort are daunting. Maintaining this sensitive data in an encrypted database using the latest encryption technology may not be enough if you cannot document your procedures for controlling access to the keys, monitoring physical access to the server, and so on. The best solution, is to hand off ALL credit card storage as well to a PA-DSS certified application that stores the numbers out in the internet cloud, far from your server, and your liability. We've selected to partner with CAMcommerce, for example, whose PA-DSS certified xCharge application is a dream to integrate with and will provide Members Only users with the security they need. All of this demands that custom applications find new ways of interfacing with payment software. For example, a very widely-used method for interfacing with payment applications involves the business application creating a batch file that is submitted to the payment app. This file contains credit card numbers written out in plain text. And the application returns a batch of response data, again with the number in plain text. This approach is certainly not compliant with the new security requirements. Like Y2K a decade ago, PCI and PA-DSS compliance are going to keep programmers busy for a while. Additional Information: The PCI Security site is full of information about the standard and compliance testing. "Navigating PCI-DSS" is a fifty page introduction to the terms of the standard and the meaning and intent of each clause. It's the best thing to read to get a sense of what this is all about. The Full PCI_DSS specification can be downloaded from this page. And when you are ready, you can also find the self-assessment questionnaire here.