View source

==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 = Payment Card Industry
*DSS = Data Security Standard
*[https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml 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.
*[https://www.pcisecuritystandards.org/security_standards/pci_pa_dss.shtml PA-DSS] = Payment Application Data Security Standard (applies to software that stores credit card data, like CMS)
*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)
*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.
*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

==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, over the years, 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

Nevada is going so far as to make PCI DSS compliance a law. http://blog.elementps.com/element_payment_solutions/2009/07/nevada-mandates-pci-dss-compliance.html

==When?==
When we recently researched this, it was hard to come by any published deadline dates. That question was, however, #1 in [http://selfservice.talisma.com/display/2n/index.aspx? 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 [http://usa.visa.com/download/merchants/payment_application_security_mandates.pdf 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 next 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 is around the corner has not moved 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 enforcement approach the payment card industry (PCI) has taken is to break 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 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 either level 3 or 4 merchants. You can see a detailed description of what constitutes these levels [http://usa.visa.com/merchants/risk_management/cisp_merchants.html here.] Knowing what level you are may be helpful as you work through your compliance steps.

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: 
*http://www.pcicomplianceguide.org/
*http://searchsecurity.bitpipe.com/rlist/term/Payment-Card-Industry-Data-Security-Standard-Compliance.html

==CMS and PCI==
''CMS configuration''

The majority of CMS merchants will be required to fill out a self-assessment questionnaire 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. Either way, use of the following options will help ensure compliance as it relates to CMS:

*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.)

''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 next year, before the July 1st deadline, we will release a new version of CMS that is PA-DSS validated. 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 [http://multichannelmerchant.com/opsandfulfillment/0401-credit-card-transactions-compliance/index.html 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 it goes away. It will be ever-present as a logistic we all need to deal with, likely forever more. 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.

[[Category:Published]]