PCI Compliance

From NewHaven Software Wiki

Overview

Every company using our CMS (Commerce Management System) software, and in fact any company that accepts credit cards, must comply with regulations created by Visa and the other card brands to ensure the secure handling of card holder data (CHD). The card brands have formed an organization called the PCI Council to standardize these requirements, named the PCI DSS (Payment Card Industry Data Security Standard.)

While you may not have had any exposure to this yet, it does not absolve you from having to comply. If you accept credit cards, you must comply. It is that cut and dry. Ultimately the PCI Council leaves it up to the company that has provided you with your merchant account to determine when and how to enforce the requirements but our experience has shown that these companies are not all forthcoming with PCI information or assistance. Don't use that as an excuse to wait though. What we have learned over the years is that PCI is about managing liability and if you've not achieved your PCI compliance you can be subject to crippling fines and fees in the event of a breach, severe enough to put some companies out of business. As the owner or member of your company's management team you must take it upon yourself to understand these regulations and ensure your business is protected. Of course your customers will appreciate your efforts too, particularly now with so much public exposure of other breaches (Heartland, Target, etc.)

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

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 represents security and best practices that must be adopted and will figure into the operation of your business for as long as you continue to accept credit cards.

Definitions

There are many acronyms thrown around in reference to PCI. We've listed several of them below with basic definitions which should help you navigate through PCI documents and videos with a little more clarity.

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 (Information from the front of the card like PAN and expiration date)
CDE = Cardholder Data Environment
SAD = Sensitive Authentication Data (Information from the back of the card like mag stripe data and CVC/CVV2)
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 = Information Technology Governance, Risk and Compliance
SMB = Small and Medium sized Business
EMV - Stands for Europay, MasterCard, Visa and refers to the chip now embedded in most phsical cards, used in lieue of the magstripe as a more secure solution.
P2PE - Point to point encryption, a technique used by some POS devices to encrypt the card as it is swiped and only sends the encrypted card to the processor.

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/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. The requirements will continue to become more stringent as updated versions of the PCI DSS are released. The solution is to upgrade to CMS TEN, follow our guide for implementing this new version, and then address the remaining PCI DSS requirements. From that point on it should be reasonable to stay on top of the changing requirements.

To be clear, PCI compliance is not limited to your deployment/use of CMS. It goes on to cover all aspects of your operation including your network, access to servers, 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.

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 severe fines and fees 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. 92% of attacks are on level 4 (small) merchants
A high percentage of breaches are from human error, not hackers

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.

What next?

Follow our CMS PA-DSS Implementation Guide for proper configuration and use of CMS for PCI compliance. As mentioned above, there is much more to it. Detailed below is the self-help version of how to address your other PCI issues. We are also currently working with some other companies that can provide different levels of PCI assistance. These companies can help you complete your questionnaires, answer questions (you're sure to have some) and perform the required quarterly scans.

In the mean time, to get started, you'll need to know what your merchant level is and which of the four SAQ forms you'll need to complete. The following sections will explain how to find these answers and then how to proceed from there.

Your merchant level

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 mid-size companies that use CMS are now being required to comply.

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

**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.
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 breach that resulted in an account data compromise may be escalated to a higher validation level.

Which "SAQ Validation Type" am I?

The other key element you need to identify is which SAQ Validation Type you are and thus which version of the self-assessment questionnaire (SAQ) you'll need to complete. For a guide on how to identify which you are, see this doc on the PCI Council's site.

The answer, though, may be simple - If you are storing credit card data, like most of all of our customers do, you are then likely required to complete SAQ-D. Unfortunately SAQ-D is also the longest and most complex form but, if you store credit card data, our understanding is SAQ-D is required.

Quarterly Scans

As you read about PCI you'll likely read about having quarterly scans conducted. These scans must be conducted for merchants of all levels that have a broadband Internet connection (dial-up users are exempt.) Chances are your merchant account provider or processor will have an arrangement with one or more companies they can refer you to for these scanning services. Coalfire Systems, 403 Labs and Trustwave are examples of such companies.

Learning more

Once you know what level you are, please visit the following sites for guidance on the various aspects of PCI which should help you with your compliance and the completion of your SAQ:

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/documents/PCIDSS_QRGv3_2.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:

The PCI Council has also produced a cute YouTube animated video which is a very high-level overview of the requirements. Don't watch this if you feel your intelligence is easily insulted (think Schoolhouse Rock).

Trustwave, a company certified by the PCI Council to perform PCI and PA DSS security validations, has also produced a video explaining the PCI requirements in more detail and how to address the requirements - http://www.brighttalk.com/webcast/5884/44529

Cybrary has a really good set of videos (you have to register but is free) on the topic of PCI-DSS and the requirements that are really worth a watch to get you up to speed.

Others:

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 pivotal question: "Do you electronically store credit card data?"

This 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 (AES-256 in version 7.0 and later).

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 you will be upgrading to CMS TEN (v10.x) - a PA-DSS validated application. If your assessor knows you are moving onto a PA-DSS validated application it could simplify your compliance efforts.

You/they should also know that CMS includes these related options:

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.

Data retention policy - 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 was used in CMS version 6.x and previous)

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

Stronger access control to ensure sensitive settings and data are only available to administrators and that the actions of those administrators are logged.

In CMS TEN a new feature was introduced 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 the processor or gateway's servers. You will have the freedom to reference and use that card in the future (again, back orders, returns and even future purchases.) This would appear to be the wave of the future and the best way to minimize PCI compliance issues while still retaining the convenience of having customer's credit card on file. The Tokenization option is presently only available with our Vantiv/Worldpay payment processor.

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.

Utilizing eCMS

eCMS is a module used in conjunction with CMS which allows CMS to communicate directly with your site. Typically this connection is done via TLS (a secure connection) and thus your order data never is downloaded to an unencrypted file. Instead the order data flows directly into CMS where the card data is immediately encrypted and managed per PA-DSS and PCI requirements.

That said, our experience has been, even situations where you are downloading to an unencrypted file and then importing into CMS, that you can still be compliant as long as there is a documented and observed process to ensure that the file containing unencrypted card data is immediately and permanently deleted (e.g. file is imported immediately after download, is immediately deleted, and cannot be restored from Windows' Trash Bin). This type of procedural solution is referred to by the PCI Council as a "compensating control". Compensating Controls are used to ensure that the best possible procedural solution has been documented and implemented in lieu of having technical solution that would otherwise enforce/ensure compliance. Your goal should still be to implement a solution where the card data never exists unencrypted but, while you are working in that direction, you can still achieve compliance. You should review this with your QSA to be sure as PCI regulations and enforcements continue to evolve.

Network Segmentation

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 and easier to isolate your CMS database server in this way than it is to try an make your whole network compliant.

The PCI Council has recently published a guide on network segmentation that is a valuable reference - https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf

PCI Help

We all have our day jobs and nobody has been sitting idle in their office waiting for a fun project like PCI to come along. Nevertheless it is something that must be tackled to ensure the safety of your customers' data and the viability of your business. Thankfully there is help to be had. Coalfire Systems, the company that NewHaven Software has worked with for all of our PA-DSS assessments, is also available to work with merchants like you to help you navigate these confusing waters to achieve PCI compliance. They have a low cost self-help project management tool (called NAVIS) to help guide you through the process. It also includes some consulting from a QSA. Alternately you can engage them for more hands-on assistance. Read more about their services here:

https://www.coalfire.com/Solutions/Audit-and-Assessment/PCI/Facilitated-Self-Assessments

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/document_library?category=saqs#results.

Your SAQ will cover many topics, only some of which pertain to CMS. NewHaven Software publishes a document called the CMS PA-DSS Implementation Guide which covers in more detail how CMS helps you meet PCI requirements and how CMS must be configured to accomplish this. You may download the latest copy of this document from Support Downloads. A sample of the information there includes:

Enable credit card encryption - Admin>Database Maint>Encryption (CMS v9 and earlier only)
Enable credit card masking - Setup>Order Entry>Order Entry Options>"Use Credit Card Masking" should be checked (CMS v9 and earlier only)
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 is masked in CMS TEN+. 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.

The credit card data is transmitted via a secure connection (established by Windows, e.g. TLS 1.2) which satisfies section 4.1 for secure transmission.
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. Once the data retention policy is set in CMS, it will delete card data nightly based on your selected policy.
Use strong passwords for anyone with administrative access. Strong passwords are 7+ characters and must be a combination of letters and numbers. These must be used for anyone with access to the PCI Administrator user.

Also, questions you'll be asked on PCI should only apply to your location and CMS. You have an additional responsibility in ensuring that vendors you work with handle your data in a compliant fashion.

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 AES (triple-DES for CMS v6 or earlier) 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 but track data is never stored, even pre-authorization)

PCI and PA-DSS

A good article from an industry guru, Ernie Schell, was published in MultiChannel Merchant magazine and is also available on their site. 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 (MPS, ePay or Authorize.net) and have followed our recommendations for configuring CMS in a compliant manner, this is only a 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 matter of you becoming compliant and then you're done. It will be ever-present as a logistic we'll 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.