PCI Compliance

From NewHaven Software Wiki

Revision as of 16:49, 18 June 2014

Overview

Every company using CMS, 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

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 9.0, 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.

A great series of videos is available from one of our payment processing partners, 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

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 is you feel your intelligence is easily insulted (think Schoolhouse Rock). <g> http://www.youtube.com/watch?v=xpfCr4By71U

Trustwave, a company certified by the PCI Council to perform PCI ad 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

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. 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, Nevada and Washington state are going so far as to make elements of PCI DSS compliance a law. Another article on Nevada's PCI law can be found here.

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 you 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 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 each of those levels:

*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, go to this link on the PCI Council's site.

The answer may be a simple one, however. If you are storing credit card data, like most of all of our customers do, you are then likely Validation Type 5 which requires that you complete SAQ-D. Unfortunately SAQ-D is 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/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/
• https://www.trustwave.com/webinars.php
• http://searchsecurity.bitpipe.com/rlist/term/Payment-Card-Industry-Data-Security-Standard-Compliance.html
• http://www.itgrcforum.com/index.php?option=com_content&view=category&layout=blog&id=267&Itemid=406
• http://www.pcipolicyportal.com/

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 in version 7.0).

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 version 9.0 - 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 2014 (CMS 10.0) we will also be implementing 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 the processor or gateway's servers. 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 think this is 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.

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 SSL (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.

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. For version 6 or earlier, please use of the following options to help ensure compliance to requirements 3 and 4 (pages 11-13). Version 7.0 of CMS will come with a PA-DSS Implementation Guide which will guide you through how to setup and use CMS in a PCI DSS compliant manner:

• 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 v1.1 PA-DSS standard but the method of integration they use requires CMS to drop a file into their directory with unencrypted credit card data. As such, it appears to us that 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. (This is automated in our version 7 release.)
• 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 CMS Setup or Admin. (In version 7, all PCI admin controls are grouped together in one screen.)

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