PCI-DSS - What is it all about and why should a merchant care?
PCI-DSS stands for Payment Card Industry Data Security Standard, which is a standard dictated by the PCI Security Standards Council. The council is made up of members from all the major credit card brands including: Visa, MasterCard, Discover, etc. PCI-DSS was originally and set of guidelines but it has evolved into being a mandate.
This mandate affects anyone that accepts credit cards as a form of payment for goods and services. This includes but is not limited to government agencies, institutions, restaurants, hotels, ecommerce websites and even charitable organizations. Once again, this includes both small and large merchants, State and Federal Agencies and institutions and the once a year fund raiser! The PCI-DSS compliance standard is for ALL.
The fact is, very few organizations understand the ramifications of PCI-DSS. As well, many merchants are operating in the blind relative to new State Privacy laws varying from state to state, which directly affects merchants selling their goods and services via the Internet.
PCI-DSS assumes a significant level of IT understanding on the part of the merchant, which they may of may not have. In many cases, this translates to a lack of knowledge and skills possessed by the merchant to comply with the standards.
As much as merchants dislike implementing PCI-DSS it is ultimately for their protection. A parallel would be States legislating that drivers must have liability insurance - it's a cost you have to pay, but at the end of the day it has been put in place to protect all citizens.
Merchants need to understand that if they fail to comply with PCI-DSS, it is not a simple case of saying "oh, well � I'm just out of compliance". For the merchant that is out of PCI-DSS compliance there are real risks:
- The merchant could have fees and fines levied form the card association.
- The merchant could have their merchant account terminated, meaning they lose their ability to accept payment cards for purchases of goods and services.
- The merchant could suffer a reputational risk associated with a breach where PCI-DSS mandates have not been followed
Merchants have to be concerned, not only about what their fines and fees might be for non-compliance with PCI-DSS, but what their true exposure to a breach might be.
What are some of the differences between Privacy Legislation and PCI-DSS Compliance?
There are approximately 29 States that have enacted Privacy Legislation. This should draw the attention of merchants for the following reason: The issue is not whether you reside in one of these 29 states, but rather does your company do business in any of these States. For example, if my company resides in the State of Georgia, but I am doing business in Massachusetts, then I am subject to the Privacy Legislation of the State of Massachusetts.
The scope of PCI-DSS is limited to data defined as "Payment Card Sensitive". This translates to data fields like card number, expiration data, cvv2, etc.
Privacy legislation changes this scope dramatically and in some States it extends that to address ANY information that might contribute to compromising someone's identity.
By changing the scope form PCI-DSS to Privacy Legislation many fields of data you might be collecting in a shopping cart, for example, you now have to be VERY concerned about from a privacy standpoint.
PCI-DSS is governed by an industry Council which publishes a standard (PCI-DSS). With PCI-DSS the merchant is exposed to fees and fines and in extreme cases having their merchant account turned off, leaving them unable to process payment card transactions. On the other hand, Privacy Legislation is governed by State Law. Therefore, with Privacy Legislation you are potentially exposing yourself to criminal prosecution if a breach should occur.
How does CFXWorks' offerings help the merchant mitigate their risk?
The issues that affect PCI-DSS and Privacy legislation can be grouped into the following categories:
- Application Software
- Operating System level software
- Policies and Procedures
As the developers of CFX_NOVA_JAVA we have addressed those issues that are embedded in the gateway itself. That is, the software that securely connects the merchant to Elavon's payment gateway and how we secure data in transit and data at rest. CFXWorks has worked with Trustwave a leading provider of on-demand and subscription-based information security and payment card industry compliance management solutions to complete a 3rd Party review of our source code. Our software was found to be implemented consistent with PCI-DSS standards. Further more; CFXWorks has completed Elavon certification to Elavon's network.
Who is the gatekeeper on PCI-DSS certification?
The payment card industry has made the processors, for example Elavon, the gatekeepers for PCI-DSS. They have done this by forcing the processors to validate that all merchants using their merchant services are PCI-DSS compliant.
How does PCI-DSS impact software vendors like CFXWorks?
- Almost all processors require that software vendors certify their software to the processor's network. This offers proof that the software vendor has implemented the processors network specification correctly and that they have correctly implemented the security features supported by the processor including but not limited to AVS, CVV2, Verified by Visa, MasterCard Secure and HTTPS.
- Before the processor certifies the software vendor to their network they require a Qualified Security Assessor (QSA) to validate that the software vendor's solution has been implemented consistent with PCI-DSS. This may or may not require the software vendor to complete PA-DSS.
Depending on how a merchant deploys the vendor's software, one might require the vendor's code to be implemented consistent with PCI-DSS or PA-DSS compliant. Here are the facts:
- Software vendors can't be PCI-DSS compliant - Only 3 of the 12 PCI-DSS requirements can possibly be implemented by a software vendor. For example, does your software vendor install and maintain your firewall? Probably not. Then if someone else is implementing 9 of the 12 requirements, how can the software vendor be PCI-DSS compliant?
- The merchant needs to add to or modify the vendor's code - Most merchants add to or modify the vendor's code. For example they integrate their shopping cart or back office systems with the vendor's code or perhaps they add or modify the vendor reports. Now the merchant not only has to address the 9 PCI-DSS issues the software vendor couldn't address, they also have to validate that the code they added or changed is consistent with PCI-DSS. In this case, the software vendor's code functioned as a toolkit or component. Therefore, a merchant should require that their software vendor successfully complete a source code review performed by a QSA and that they can provide proof that they completed this review and that the QSA judged that their code was implemented consistent with PCI-DSS.
- The merchant needs a drop-in-solution (NO ADDITOIONS AND NO MODIFICATIONS ALLOWED) - This is where PA-DSS applies. However, who installs payment solutions without modification or additions. Perhaps this applies to very small merchants who have no IT resources. But make any change or addition and you are right back to option 2 above.
A final word of caution
Why is it so important to know who your gatekeeper is? Because the only way you will know if the claims of your software vendor are legitimate is to call your processor and ask to speak to their certification department and ask them if the solution you are considering is certified to their network and what the PCI-DSS status is relative to the solution. The bottom line is: will the processor board the merchant account or not! If the answer is no, then run for cover! If the answer is yes then you know that the software vendor has done their homework. The individual you should speak to at Elavon is Jay Forthman. His contact information is: