On June 29, 2011 the PCI Security Council released a checklist outlining the types of payment applications that are eligible for PA-DSS validation:
https://www.pcisecuritystandards.org/documents/Applications_Eligible_for_PA-DSS_Validation.pdf
A series of 13 questions were outlined and if you answered “yes” to any of these questions, your payment application is not eligible for PA-DSS validation. Here are a couple of those questions that will likely impact many organizations who were considering or are in the process of having applications validated against the PA-DSS.
Question #3 – Does the application facilitate authorization or settlement, but has no access to cardholder data or sensitive authentication data?
This is a significant impact to those vendors that have spent both time and resources to implement a tokenization solution where they do not have access to cardholder data and therefore, their payment application would not qualify for PA-DSS validation. There is a caveat – applications deemed as “payment middleware” or “payment back office” that create the token value and therefore, have access to cardholder data, would qualify for PA-DSS validation.
The Council has developed a task force to address data tokenization/point-to-point encryption and is working to develop guidelines on how this impacts PA-DSS validation.
Question #9 – Does the application depend on other software in order to meet one or more PA-DSS requirements, but is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software?
“Other software” here is defined as software specific to your payment application. For example, if SQL Server or other third party software is required by your payment application but not “bundled” with it, this is not a concern and would not apply. However, this is yet another significant impact to what portions/modules of a payment application are in scope. As defined by the Council:
“PA-DSS does apply to payment applications provided in modules, which typically includes a “baseline” module and other modules specific to customer types or functions, or customized per customer request. PA-DSS may only apply to the baseline module if that module is the only one performing payment functions (once confirmed by a PA-QSA).
So what does this all mean? The “baseline” module of your payment application is in scope for PA-DSS even if it does not perform payment functions. Modules that perform payment functions, including the baseline module would be included in scope of the PA-DSS review.
As a best practice and general guidance: Develop your payment application with a base installation and isolate payment functions to only specific modules.
And of course, speak with your PA-QSA to ensure they fully understand your application – PA-DSS validation requires significant work and you don’t want to find yourself going down this road only to realize your payment application is not eligible for PA-DSS validation.
Shelina Samji, PCI QSA
Senior Consultant, PCI Compliance Services
PCI DSS Requirements
PCI DSS Requirement 5.4.1: Anti-spoofing controls such as DMARC, which stands for Domain-based Message Authentication, Reporting and Conformance, Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM) can help stop phishers from spoofing the entity’s domain and impersonating personnel.
Clarification on eCommerce Outsourcing PCI DSS requirements 6.4.3 and 11.6.1
Unpacking the New PCI DSS Password Standards
Is Your Organization Prepared for PCI DSS Automation – Requirement 10.4.1.1?
What is the PCI DSS v4 Authenticated Scanning Mandate – Requirement 11.3.1.2?
What is the PCI DSS v4.0.1 Requirement for PoLP – Requirement 7.2.5?
The New PCI DSS v4.0.1 Software Catalog Mandate – Requirement 6.3.2
How to Analyze An Attestation of Compliance (AOC)
PCI Compliance New Requirements and Targeted Risk Analysis (TRA)
RESOURCES & NEWS
Learn more about Penetration Testing and new exploits in HALOCK’s Exploit Insider.
The Dangers of Legacy Protocols
PCI Targeted Risk Analysis & DoCRA
https://www.halock.com/pci-compliance-new-requirements-and-targeted-risk-analysis/
HIPAA & Penetration Testing & Incident Response Plans
Top Threats in Healthcare
https://www.halock.com/top-cyber-threats-in-healthcare/
Cloud Security Risk Management
https://www.halock.com/prioritized-findings-and-remediation-in-cloud-security-reporting/
Penetration Testing Reports to Manage and Prioritize Risk
https://www.halock.com/a-threat-based-approach-to-penetration-test-reporting/
