PCI Compliance

From NewHaven Software Wiki

(Difference between revisions)

Revision as of 23:57, 29 March 2010

Overview

Every company using CMS, in fact any company that accepts credit cards, has or will soon be faced with having to respond to their merchant account provider and their request that you be "PCI Compliant."

In this article we will supply you with what you need to know about configuring CMS for compliance as well as provide guidance and a few valuable links to help you understand and address the other aspects of PCI compliance.

In short, if you are unsure what PCI is or what you have to do to comply, this article should serve as a primer for you to get you started on the right path. One thing is certain though: PCI cannot be ignored. PCI's significance is now akin to that of death and taxes; it's not a matter of if, but when.

Definitions

There are many related terms and acronyms thrown around on this subject. We've listed several of them below with basic definitions.

PCI DSS = Payment Card Industry Data Security Standard (applies to the merchants) At the time of writing this article, version 1.2 is the current standard which replaces the older 1.1 version of PCI DSS.
PA-DSS = Payment Application Data Security Standard (applies to software that stores credit card data, like CMS)
PCI SSC = Payment Card Industry Security Standards Council - A council formed by Visa, MasterCard, Amex, etc. to standardize on the requirements put forth in PCI and PA DSS. Even with this 'standardization' each company may have their own individual requirements, penalties or enforcement means.
Merchant = You - A company that has been given a credit card processing (merchant) account to accept credit card payments
Gateway = The software CMS communicates with for credit card processing. (e.g. Authorize.net, ePay, PCCharge)
PAN = Primary Account Number (the credit card number)
CHD = Cardholder data (e.g. PAN, expiration date)
SAQ = Self-Assessment Questionnaire
QSA = Qualified Security Assessor (licensed auditing agency that can certify PCI DSS compliance)
ASV = Approved Scanning Vendor (licensed agency that performs internet vulnerability scans)
PCI Compliance = Short form of PCI DSS compliance. An adherence to the established PCI DSS rules and best practices
CISP = Cardholder Information Security Program - Established by Visa to ensure the security of cardholder information as it is being processed and stored by merchants and service providers. CISP has been replaced by PCI DSS which is sponsored by Visa and the other card companies to standardize on security solutions/requirements (although each company maintains their own requirements)
PABP = Payment Application Best Practices, the predecessor of PA-DSS
VNP = VisaNet Processors (a more generic form of this would just be 'processors')
PED = PIN Entry Device
PIN = Personal Identification Number
PII = Personally Identifiable Information
IT GRC = IT Governance, Risk and Compliance
SMB = Small and Medium sized Business

PCI demystified

Over the years Visa has worked with the other card issuers to figure out ways to reduce their risk and exposure to fraudulent or stolen cards. This started as CISP, a list of recommended best practices, and has since evolved into the PCI DSS you are now being asked to adhere to.

We have monitored this evolution, always wary that the day would come when "compliance" was no longer just a good idea, but a requirement. To that end, we have continually enhanced CMS to include related features and safeguards such as data encryption, credit card masking (on-screen and printing,) deleting security codes after processing, as well as using secure connections with our newer payment gateways. As such CMS can be deployed in a compliant manner, if properly configured, but the requirements are becoming more stringent and we have more work to do in future releases. (discussed below)

Compliance, however, is not limited to your deployment of CMS. It goes on to cover all aspects of your operation including your network, company policies and/or anything else that could possibly impact the exposure of sensitive credit card data. In short, if a credit card number or the security code (CVV2) is ever visible/accessible beyond the moment it is needed to process (i.e. if it is printed, in an unencrypted file or unencrypted database, etc.) then you are not compliant. This is an over-simplification but is a good rule of thumb to help you get your head around the core issue that drives the PCI Compliance requirements. The PCI DSS link provided above in the Definitions list will outline all aspects of compliance.

A great series of videos is available from Mercury Payment Systems on the topic of PCI. It starts with an overview, much as this article does, and subsequent videos cover the various aspects of compliance in more detail. Highly recommended viewing. http://go.mercurypay.com/pcipartner/resources.htm

Another very good series is available from Visa at: http://usa.visa.com/merchants/risk_management/data_security_demo/m1/index.htm

Bah, humbug!

We get that a lot. Many merchants, particularly smaller ones, don't think they need to bother with PCI compliance. You may think that you've been running your business just fine for many years, your procedures are fine and you've never had to mess with this PCI nonsense. "Why should I pay any attention to it now?" You may also think, as a small business, you are not a target of hackers or thieves.

Your merchant account provider will make compliance a requirement if they haven't yet. Further, there are crippling fines if you are compromised (customer credit card data stolen from you.) Either way, if you do not think you are a target or that this will affect you, please take a moment to read the following article:

http://www.pcicomplianceguide.org/merchants-20090416-cost-data-breach.php

Key points here are:

Small businesses are targets. 80% of attacks are on level 4 (small) merchants
A high percentage of breaches are from human error, not hackers

The following video (~10 min) is also helpful and outlines some PCI basics and includes a case-study of a small retail merchant. This video is focused on a small retail (brick and mortar) store but still is applicable:

http://www.mercurypay.com/go/rspa/

Even the Federal government is involved and, in short, they think the PCI rules are too lax. http://chuvakin.blogspot.com/2009/04/thoughts-and-notes-from-pci-dss-hearing.html

Minnesota and Nevada are going so far as to make elements of PCI DSS compliance a law.

When?

When we recently researched this, it was hard to come by any published deadline dates. That question was, however, #1 in FAQ section of the council's site:

What are the deadlines for complying with PCI DSS?

"Compliance is mandated by the payment card brands and not by the PCI Security Standards Council. However, for most merchants, the deadlines for validating compliance with the PCI DSS have already passed. You should check with your acquirer and/or merchant bank to check if any specific deadlines apply to you, based on merchant transaction volume (level) as determined by the card payment brands. All entities that transmit, process or store payment card data must be compliant with PCI DSS."

Per their recommendation, we went to the 'card brand' site (e.g. Visa) and found some dates published there which have been summarized here:

Phase 1 - 1/1/08 - Newly boarded merchants must not use known vulnerable payment applications, and VisaNet Processors (VNPs) and agents must not certify new payment applications to their platforms that are known vulnerable payment applications.
Phase 2 - 7/1/2008 - VNPs and agents must only certify new payment applications to their platforms that are PA-DSS compliant
Phase 3 - 10/1/08 - Newly boarded Level 3 and 4 merchants must be PCI DSS compliant or use PA-DSS compliant applications. Now that this deadline has passed, Acquirers are turning away new merchants not using software listed as PABP/PA-DSS compliant.
Phase 4 - 10/1/09 - VNPs and agents must decertify all vulnerable payment applications. VNPs and agents must decertify these within 12 months.
Phase 5 - 7/1/10 - In this final phase, Processors and Acquirers must ensure their merchants, VNPs and agents use only PA-DSS compliant applications

You can see that these dates are not just about the merchants but also include everyone up the chain from the merchant. We are working on CMS now to prepare you for this year's phase 5 deadline. As stated elsewhere in this articles and its linked articles, however, compliance is not limited to the software you use. We advise moving forward with the other aspects of your other compliance right away.

Perhaps an important point to make on these dates is they are not likely to change. The previous dates were set and did not move. The October 2009 deadline has just passed and did not move and by extension I think we can assume the July 2010 date isn't going to change either. The question then becomes how it will be enforced. What will really happen if you are not on a PA DSS validated application by July 1, 2010? A fair question and we can only guess at the answer.

Perhaps a better question to ask yourself is if your business can survive its enforcement. It's hard to imagine they would pull the plug on your merchant account but there is no sense putting the fate of your business in their hands. We're not going to wait and find out. We'll make sure you have a PA DSS validated version of CMS available to you before the deadline. In the mean time, get started on addressing your other PCI DSS compliance issues.

What next?

The PCI Council has broken down merchants into four "levels" with a level 1 being the highest volume and level 4 being the lowest. They started enforcing their PCI requirements with those level 1 merchants first and have been working their way down to the point where the small to midsize companies that use CMS are now on their radar.

All CMS users are usually level 3 or 4 merchants unless you are a division of a larger organization. You'll want to know what level merchant you are before proceeding. Here is a description of what constitutes those levels:

2 Any merchant-regardless of acceptance channel-processing 1,000,000 to 6,000,000 Visa transactions per year. 3 Any merchant processing 20,000 to 1,000,000 Visa e-commerce transactions per year. 4 Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants-regardless of acceptance channel-processing up to 1,000,000 Visa transactions per year. *Any merchant that has suffered a hack that resulted in an account data compromise may be escalated to a higher validation level. Once you know what level you are, please visit the following sites: The requirements for PCI DSS are outlined at https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml and this should serve as a good overview of the 12 categories of compliance you'll need to address. Further, an explanation of each requirement is at https://www.pcisecuritystandards.org/pdfs/pci_dss_saq_navigating_dss.pdf. This document will provide some clarity on what is being asked of you for each step. The following sites are good resources for FAQ's, information and related videos:

Ways to reduce your compliance costs and efforts

Not storing card holder data

When you are going through your PCI DSS certification or completing your self-assessment questionnaire (SAQ) you will be asked a key question: "Do you electronically store credit card data?"

The question is key because companies who store credit card data must adhere to more rigorous PCI requirements than companies who do not. CMS does store card data (this is clarified elsewhere in this article) so for the moment you must answer Yes to this. Presently CMS needs that card data for processing returns and backorder fulfillments but we do encrypt the card data using Triple DES so it is pretty secure.

We are working on a number of ways to both help and reduce your compliance requirements. Before making a rash decision to not process credit cards through CMS, please read on to learn of the short and mid term solutions coming that will help on this front.

Something you should share with your ASV or QSA is that in the next few months you will be upgrading to CMS version 7 which will be our PA DSS certified version. We are working with a company named Coalfire who is certified by the PCI Council to perform such certifications of software like ours that handles credit card data. If your assessor knows you are moving onto a PA DSS certified application it could simplify your compliance efforts.

You/they should also know that in CMS version 7 we will be introducing options to:

Allow you to not store credit card data - If you choose this option CMS will automatically delete credit card data as soon as the card has been captured (when all back orders or future ships have been fulfilled.) Using this means you'd have a much lower level of PCI compliance to adhere to but it also means you'd have to contact your customers for their card number if you needed to issue a refund to their card.

Option to choose how long to store data. If you have a 60 day return policy, you can tell CMS you want to store the data for 61 days and then CMS will nightly clear all data past that threshold. Some processors we've spoken with are saying that a data retention policy like this is as good as not storing card holder data and thus still allows them to comply at the lower PCI DSS level. That will have to be determined by your merchant account provider or security assessor however. We think this is up to their interpretation and not specifically stated in the PCI DSS documents.

Credit card encryption will be done with AES using dynamically created keys (replacing Triple DES that we currently use)

Audit logging of all who access credit card data (among the myriad of other things we have to do to satisfy PA DSS)

After version 7 is released, we will also be exploring a new option called tokenization which is the best of both worlds. With this option card data is no longer stored in CMS (thus reducing your compliance requirements) but it is stored securely at Authorize.net. You will have the freedom to reference and use that card any time in the future (again, back orders, returns and even future purchases we think.) We're still exploring this option and it is not clear if/when it can be done but we do think this is the wave of the future and the best way to minimize PCI compliance issues while still retaining needed functionality.

While your software only affects a portion of your overall compliance, whether or not you store card data does have a big impact. If your assessor knows of the changes coming soon for you, we'd imagine they would have you focus on other areas of compliance first and give you time to implement the improved software solutions.

Isolating your server

Another way you can reduce your compliance is to put your CMS database on its own server, one that is not serving other functions (like being a file server,) and then lock it away so it is not physically accessible.

If you isolate the storage of your card holder data to a locked room and put it behind an internal firewall that would only allow CMS to access it, you effectively have removed the whole rest of your network from most of the security requirements in PCI DSS. This should eliminate the need for having video cameras at access points, for example.

You very well may find that it is cheaper to isolate your CMS database server in this way than it is to try an make your whole network compliant.

CMS and PCI

CMS configuration

The majority of CMS merchants will be required to fill out a self-assessment questionnaire (SAQ) that covers not only their use of CMS but in fact all aspects of their business processes and network. Larger merchants may have to pay to have a licensed auditor come in and complete the assessment for them. If you will be filling out the SAQ form you should know there are multiple versions available based on how you process and store charge card data. Currently, CMS users would be considered validation type 5, since CMS is storing card holder data, and thus will need to complete SAQ form D which can be downloaded from https://www.pcisecuritystandards.org/saq/instructions_dss.shtml.

Your SAQ will cover many topics and of those, you'll find requirements 3 and 4 pertain to CMS. Please use of the following options to help ensure compliance to requirements 3 and 4 (pages 11-13):

Enable credit card encryption - Admin>Database Maint>Encryption
Enable credit card masking - Setup>Order Entry>Order Entry Options>"Use Credit Card Masking" should be checked
Disable debug log - Setup>Payment>EDC>Options>"Create Debug log" should be unchecked
If you are using a CMS invoice (as opposed to a Crystal invoice) make sure you are not using the print task "Payment - Charge Card Number". All of our Crystal invoices and other CMS print tasks will only print the last 4 digits of a credit card number.

This print task will be masked in a future version. All other tasks in CMS that print credit card numbers, like the 'charge message' task have had their card numbers masked for years and still do today.

If you are using ePay or Authorize.net (not PCCharge) the credit card data is transmitted via SSL so it is secure and satisfies section 4.1 for secure transmission.

PCCharge has been certified compliant on the old 1.1 standard but the method of integration they use requires CMS to drop a file into their directory with unencrypted credit card data. As such, this integration method is not and cannot be made compliant. PCCharge users will need to switch onto a different payment gateway to facilitate compliance. Please contact NewHaven Software to discuss your options.

As a merchant, you'll need to create a data retention policy per item 3.1 in PCI DSS to outline how long you plan to store the card data. We can assist with helping you purge old card data per whatever policy you decide on. We would do this by providing SQL to replace old card data with generic equivalents (e.g. 4444 4444 4444 4448.) Please contact NewHaven Software Tech Support for assistance with this. (We are looking to automate this in some fashion in our version 7 release.)

Also, questions you'll be asked on PCI should only apply to your location and CMS, not eCMS. Since CV3 hosts eCMS sites, the PCI liability for your stores falls upon them. You should confirm this with your security assessor but that has been our understanding. If you were hosting your own site, however, you would then also be accountable for storage of card data on your web servers.

User Habits

In addition to properly configuring CMS for PCI DSS compliance, you will also need to train your staff on how their actions affect compliance. Here again this extends beyond their use of our software and would include the proper handling of credit card data in any form. Some common habits we see that you'll want to look out for and change include:

Placing credit card numbers or CVV2 numbers in text fields like Primary, Invoice Notes, call history notes, or email. This is not allowed to be stored in any form, even encrypted, after the card has processed.

Writing credit card information down on paper. Do what you can to encourage live entry of orders into CMS or even your website so that the credit card information never has to be put to paper. CMS has been optimized for the fast entry of orders and even allows for multiple orders to be entered simultaneously on the same workstation or temp saved for completion later. Please contact us if you'd like to schedule training with your staff on how to speed up your order entry and avoid writing orders on paper.

Email credit card numbers. Credit card data should never be in an electronic format unencrypted. If it is stored/saved, there must be policies in place for proper security and deletion of that data after it is no longer needed. As a rule, credit card data in email should be considered off limits.

What does CMS store?

CMS does store credit card numbers (PAN's) and expiration dates. If you have CMS configured properly, the credit card numbers will be encrypted using triple-DES which is an encryption method that satisfies compliance requirements.
CMS does not store security codes (CVV2) after the card is processed.
CMS does not store track data for swiped cards. (card swiping is supported in CMS's POS Module)

Validating CMS

As it relates just to CMS, software like ours is being held to a new standard called PA-DSS (Payment Application Data Security Standard.) We must have CMS validated/certified by July 1, 2010 and we estimate our related costs to be tens of thousands of dollars just for validation, not including our development costs. Again, not something we can ignore or take lightly. Death, taxes and PCI.

Some time this year, before the July 1st deadline, we will release a new version of CMS that is PA-DSS validated. This validation is being performed by Coalfire, a company certified by the PCI Council to perform such validations. Between now and then we will continue to provide education tools like this article to help you through the process. Just updating to the PA-DSS version of CMS is not enough for you to be compliant though and you should work on your PCI DSS plan for compliance now.

A good article from an industry guru, Ernie Schell, was published recently in MultiChannel Merchant magazine as well on their site. While the news is not great, the article is a good read and explains aspects of PCI and PA compliance and how they affect you. Please consider this article required reading. The most important point to take from this is that all merchants need to be running a PA-DSS certified order management system by July 1, 2010.

Summary

Compliance consists of many issues, only some of which involve CMS. We want to be clear that even if you are using a compliant gateway (ePay or Authorize.net) and have followed our recommendations for configuring CMS in a compliant manner, this is only a small portion of what needs to be done for your PCI DSS compliance. If your software is not compliant, you are not compliant. However, even if your software is compliant it doesn't necessarily mean you are.

PCI DSS is not going away nor is it a one shot compliance and then you're done. It will be ever-present as a logistic we all need to deal with. Take the time to read through the recommended sites and familiarize yourself with all of the steps. If you do not have time, assign someone in your organization to be your compliance expert and have them own this responsibility.

To assist you in your efforts, we will continue to update this article, publish training videos on our website, send emails and do whatever else we can to proactively help you over your compliance hurdles. Please watch for future communications from us on this topic.

**PCI Merchant Levels**
Merchant Level*	Description
1	Merchants processing over 6 million Visa transactions annually (all channels) or global merchants identified as Level 1 by any Visa region. Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.

@@ Line 83: / Line 83: @@
 The PCI Council has broken down merchants into four "levels" with a level 1 being the highest volume and level 4 being the lowest. They started enforcing their PCI requirements with those level 1 merchants first and have been working their way down to the point where the small to midsize companies that use CMS are now on their radar.
-All CMS users are usually level 3 or 4 merchants unless you are a division of a larger organization. You'll want to know what [[http://usa.visa.com/merchants/risk_management/cisp_merchants.html level] merchant you are before proceeding. Here is a description of what constitutes those levels:
+All CMS users are usually level 3 or 4 merchants unless you are a division of a larger organization. You'll want to know what [http://usa.visa.com/merchants/risk_management/cisp_merchants.html level] merchant you are before proceeding. Here is a description of what constitutes those levels:
+{| border=1
+|+'''PCI Merchant Levels'''
+|-bgcolor=yellow
+! Merchant Level* !! Description !!
+|-
+| 1 ||Merchants processing over 6 million Visa transactions annually (all channels) or global merchants identified as Level 1 by any Visa region. Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.
+|-
-Merchant Level 	Description
-Merchants processing over 6 million Visa transactions annually (all channels) or global merchants identified as Level 1 by any Visa region. Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.
 Any merchant-regardless of acceptance channel-processing 1,000,000 to 6,000,000 Visa transactions per year.
 Any merchant processing 20,000 to 1,000,000 Visa e-commerce transactions per year.
 Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants-regardless of acceptance channel-processing up to 1,000,000 Visa transactions per year.
+ *Any merchant that has suffered a hack that resulted in an account data compromise may be escalated to a higher validation level.
 Once you know what level you are, please visit the following sites: