Understanding PA DSS

Payment applications have their own specific set of protocols to keep data safe. 

The Payment Application Data Security Standard (PA DSS) is a set of rules for anyone who makes or sells electronic payment processing software. The Payment Card Industry Security Standards Council (PCI SSC) introduced it in 2008 to guide the safe development of any application that stores, processes or transmits cardholder data. Known as Visa’s Payment Application Best Practices until its widespread adoption by all the major credit card brands, the main objective of PA DSS is to lower the risk of credit card fraud in the payment processing system.

How Does it Relate to PCI DSS?

Merchants, merchant service providers and financial institutions look to the Payment Card Industry Data Security Standard (PCI DSS) to keep their credit card security measures up to date, and PA DSS is one branch of that standard. An application’s PA DSS compliance doesn’t guarantee a business is PCI DSS compliant, but it’s one step toward achieving it.

The PCI SSC trains and licenses Payment Application Qualified Security Assessors (PA-QSAs) who review and test each part of payment applications for compliance with the PA DSS. If a merchant’s payment application is in compliance with PA DSS, PA-QSAs complete a Report of Validation (ROV) for the business—basically a good report that goes to the PCI SSC and lets everyone know the application operates by industry standards to keep credit card information safe from fraud. PA DSS applies to third-party applications, not to software developed by merchants for use in their stores only.

PA DSS has 14 Requirements Outlined by the PCI SSC:

1. “Do not retain full-track data, card verification code or value, or PIN block data.” Full-track data is the information found on a credit card’s magnetic stripe or EMV chip. The verification code is the three- or four-digit number found on the front or back of the card. The Personal Identification Number (PIN) block is a format used to mask sensitive PIN numbers. Even if it’s encrypted, this data can never be kept after a transaction.

2. “Protect stored cardholder data.” A payment application can store the Primary Account Number (PAN), expiration date, service code and cardholder name if they’re properly encrypted or masked and therefore meaningless to hackers.

3. “Provide secure authentication features.” An application has to require unique user IDs and strong passwords, which have to be encrypted when stored. Users should have limited access to data—ideally the minimum amount necessary to do their jobs.

4. “Log payment application activity.” There has to be a way to link all payment application activity back to individual users. The payment application has to keep track of who does what, from where, at what time.

5. “Develop secure payment applications.” Every move that goes into making new software has to be a proven, PCI-compliant process. For instance, real credit card data cannot be used to test software during its development. Security reviews have to be performed before any software, or software update, hits the market.

6. “Protect wireless transmissions.” Exploiting wireless technology is a common form of credit card data theft, so any payment application that incorporates wireless technology has its own set of safeguards such as changing vendor default settings like passwords and encryption keys.

7. “Test payment applications to address vulnerabilities and maintain payment application updates.” A vulnerability management system has to be in place so that weaknesses can be recognized, ranked, prioritized and repaired.

8. “Facilitate secure network implementation.” Payment applications are not allowed to interfere with other PCI DSS requirements. For example, when a business introduces a new payment application into its network, the payment application has to be tested to make sure it doesn’t hinder other processes, like anti-malware updates. Everything has to work in harmony.

9. “Ensure that cardholder data is never stored on a server connected to the Internet.” Cardholder databases, where sensitive information is stored, have to be in a separate network zone than the web server. Any storage component of a payment application has to be on a different server than the public-facing web server.

10. “Ensure two-factor authentication for remote access to the payment application.” Two-factor authentication requires a user to enter a password and an additional identity-confirming factor to access an application. The additional factor can be something the user has, like a swipe card, something the user knows, like the answer to a personal question, or a biometric, such as a fingerprint. Remote access is any access from outside a company’s premises.

11. “Encrypt sensitive traffic over public networks.” Data transmission over public networks (internet, satellite, wireless or cellular) is at greater risk to data thieves so extra security measures, like higher level encryption, are required.

12. “Encrypt all non-console administrative access.” Any web-based or otherwise non-console administrative access has to be heavily encrypted.

13. “Maintain a PA-DSS Implementation Guide for customers, resellers and integrators.” This is an instruction manual and describes how to safely add a payment application into a PCI DSS compliant system without disturbing other parts of the system. A new guide has to accompany every update to an application.

14. “Assign PA-DSS responsibilities for personnel, customers, resellers and integrators.” Data security training programs ensure that buyers of payment applications can properly use them.

Consult www.pcisecuritystandards.org for more information on each requirement and a list of approved payment applications.