PCI-DSS and PA-DSS: It sounds painful, but it’s unavoidable. What does it all mean? And why does it affect every operator who runs a business with credit card transactions?
By Crystal S. Sulzer
TOMBALL, Texas — As with many of the articles that I have written over the years about security breaches and PCI Compliance, as well as understanding the credit card industry, I still get people consulting with me on a daily basis pleading their case as to why they don’t have to comply with the rules and regulations that the PCI SSC(Payment Card Industry Security Standards Council) sets forth, because their software is Compliant.
Let me start by saying PCI APPLIES TO EVERYONE WHO TAKES CREDIT CARDS….PERIOD!!!
There are two pieces to this puzzle. The first is the merchant side where PCI-DSS (Payment Card Industry-Data Security Standards), applies to all business regardless of size. In fact, bigger businesses have even more stringent requirements if they do more than six million Visa transactions per year. They are referred to as Level 1 merchants. Most business will fall into a Level 3 merchant that is categorized as any merchant processing between 20,000 to one million transactions per year.
The second piece is PA-DSS (Payment Application- Data Security Standard) which applies to all software companies that use credit card processing within their software that stores information.
• PCI-DSS has 12 simple requirements:
• Install and maintain a firewall configuration to protect cardholder data.
• Do not use vendor-supplied defaults for system passwords and other security parameters.
• Protect stored cardholder data.
• Encrypt transmission of cardholder data across open, public networks.
• Use and regularly update anti-virus software or programs.
• Develop and maintain secure systems and applications.
• Restrict access to cardholder data by business need to know.
• Assign a unique ID to each person with computer access.
• Restrict physical access to cardholder data.
• Tract and monitor all access to network resources and cardholder data.
• Regularly test security systems and processes.
• Maintain a policy that addresses information security for employees and contractors.
PA-DSS has 13 not so simple requirements:
• Do not retain full magnetic stripe, card verification code or value (CAV2, CID, CVC2) or PIN block Data.
• Protect stored cardholder data.
• Provide secure authentication features.
• Log payment application activity.
• Develop secure payment applications.
• Protect wireless transmissions.
• Test payment applications to address vulnerabilities.
• Facilitate secure network implementation.
• Cardholder data must never be stored on a server connected to the Internet.
• Facilitate secure remote access to payment application.
• Encrypt sensitive traffic over public networks.
• Encrypt all non-console administrative access.
• Maintain instructional documentation and training programs for customers, resellers and integrators.
So how do companies that use software know that the software they are using adheres to the PA-DSS rules and regulations and how do they maintain their compliance as well?
This is an ongoing process that never stops. It includes scans, surveys, password changes, updating software, taking patches, etc. Ultimately it is up to you as a merchant to make sure that not only the software that you are using meets the PA-DSS requirements, but also to make sure you have passed your SAQ (Self Assessment Questionnaire) based on accurate answers.
The relationship between PCI DSS and PA-DSS can be confusing, but by following a few guidelines, set forth by the PCI Security Standards Council, it will help you get on the right track. The requirements for both PCI & PA DSS can be found at the PCI SECURITY STANDARDS COUNCIL WEB SITE, which details what a payment application must support to facilitate a customer’s PCI DSS compliance:
Traditional PCI DSS compliance may not apply directly to payment application vendors since most vendors do not store, process, or transmit cardholder data. However, since these payment applications are used by customers to store, process, and transmit cardholder data, and customers are required to be PCI DSS compliant, payment applications should facilitate, and not prevent, the customer’s PCI DSS compliance.
Just a few of the ways payment applications can prevent compliance follow:
“Storage of magnetic stripe data and/or equivalent data on the chip in the customer’s network after authorization; applications that require customers to disable other features required by the PCI DSS, such as antivirus software or firewalls, in order to get the payment application to work properly; and vendors’ use of unsecured methods to connect to the application to provide support to the customer.
“Secure payment applications, when implemented in a PCI DSS- compliant environment will minimize the potential for security breaches leading to compromises of full magnetic stripe data, card verification codes and values (CAV2, CID, CVC2, CVV2), PINs and PIN blocks and the damaging fraud resulting from these breaches.” — as quoted from the PCI PA-DSS Requirements and Security Assessment Procedures, v2.0 dated October 2010.
In other words, your software cannot prevent you from maintaining your compliance in order for it to work. It can’t store all the magnetic stripe data; it can’t disable your firewalls in order to use it; and all communication via IP must be secured and not able to see full PAN number through that connection.
Most merchants can’t even answer the question as to why they try to hold onto cardholder information. Consider outsourcing your credit card storage and processing, especially as a software company. Yes it may cost a little more to store, but in the long run it releases you of the liability and responsibility of securing data.
One of the biggest arguments I hear is that they should be able to see the full credit card number. Once again this is a very gray area. If you are a software that communicates through the Internet (IP), the requirements state in requirement No. 9 that cardholder data must never be stored on a server connected to the Internet and therefore, should never see full card information.
But when the PAN is displayed, the first six and last four digits are the maximum number of digits to be displayed. (This requirement does not apply to those employees and other parties with a legitimate business need to see full PAN. But this requirement does not supersede stricter requirements in place for displays of cardholder data. For example, point of sale receipts.) If you can log into your software and see the full number without using a masking tool to unmask the PAN, your software is NOT PCI Compliant and puts you as risk.
No matter what Payment Application you use, make sure they are taking the proper precautions to adhere to what the guidelines state. Remember a payment application is referred to as any application that stores, processes or transmits cardholder data as part of an authorization or settlement.
A few solutions if your software is not compliant:
• Use an old fashion terminal to key in the information.
• Use a virtual terminal that is certified compliant to process your cards.
To sum the above up in basic terms, if a software company is not doing everything necessary to protect the card holder information and is not adhering to the 12 requirements of PCI-DSS guidelines themselves, they are putting you at risk for a security breach leaving you holding the bag if there is a compromise.
The bottom line is for you to know and understand the requirements to safeguard your business from potential compromises. If you have questions about PCI compliance, please check with your processor for more information.
Source: Crystal S. Sulzer