Navigating PCI Validation

July 7, 2023

Everyone has heard of Payment Card Industry Data Security Standard (PCI DSS). It is synonymous with cardholder data (CHD) and processing credit cards. However, have you heard of the Payment Application Data Security Standard (PA-DSS)? Did you know it has been replaced?

The PA-DSS, which was released April 15, 2008, has had numerous revisions up until it was retired in October 2022. PA DSS was used to validate payment application software through extensive testing and analysis by a Payment Application Qualified Security Assessor (PA-QSA). The new standard is the Secure Software Framework (SSF), which applies to software vendors who sell payment software that stores, processes, or transmits cardholder data. Not all software will qualify for the SSF and be listed with the Payment Card Industry Security Standards Council (PCI SSC). Under the most recent version of the Secure Software Program Guide, even internally developed payment software not resold to customers can be assessed against the SSF standard.

 

Image

Figure 1: PCI DSS and merchant e-commerce process flow

 

The PCI SSC established the Payment Card Industry Software Security Framework (PCI SSF) Assessment to evaluate the security of software used to process payments made with credit and debit cards. The PCI Secure Software Assessment is part of the PCI Software Security Framework (SSF). Software validated through this assessment is designed to help merchants and service providers comply with the requirements of the PCI Data Security Standard (DSS) and ensure the protection of sensitive cardholder data.

 

Image

Figure 2: Credit card transaction process breakdown

 

Both the previous standard (PA-DSS) and the new standard (SSF) are tedious endeavors. The assessor is required to use either their lab or go onsite to the vendor’s location to perform all of the work associated with validating an application. Additionally, each platform that the application is designed for has to be tested. So, if the application can be run on Windows or Linux, then the assessor must establish and use two labs.

The assessor must install the software and all dependencies using vendor-provided documentation called “implementation guidance.” Such documentation involves taking forensic captures to analyze the baseline state and ensure that cardholder data is protected at all steps of the transaction before secure post-transactional deletion. The assessor must also complete a penetration test of the environment to confirm the absence of vulnerabilities. If vulnerabilities are present, the assessor is then required to provide mitigation controls defined within the implementation guidance to address the risk.

Assuming that all issues are resolved, the assessor completes the Report on Validation (ROV). The ROV must initially go through the assessor’s SSF QA program to eliminate errors and ensure clear, comprehensive documentation. Once ready for submission, the ROV is sent through the PCI SSC’s Assessor Quality Management (AQM) process, where there are a minimum of two rounds of review. If there are issues with the ROV, an iterative cycle begins to address questions from the PCI SSC. If the ROV successfully passes all PCI SSC AQM processes, then the submitted application will be listed on the PCI SSC website. Unlike the former PA-DSS standard, the SSF has an annual revalidation requirement to the PCI SSC.

The PCI Secure Software Assessment is composed of specific requirement modules, which allow the program to be expanded as new technology evolves. The core requirements (Core Modules) are composed of the general security requirements that apply to all types of payment software, regardless of software function, design or underlying technology. These other modules include:

 

Image

Figure 3: PCI Secure Software Assessment Modules

 

At a minimum, payment software must be assessed to the Core Requirements. Additional modules are included in the assessment when the software meets the applicability criteria for those additional modules.

Many security requirements do not specify the level of rigor or frequency for periodic or recurring activities, such as the maximum period in which a security update must be provided to fix known vulnerabilities. In such cases, the software vendor may define the levels of rigor or frequency appropriate for its business needs. However, these levels must be supported by documented risk assessments and the resultant risk management decisions. Additionally, the software vendor must demonstrate that its implementation provides ongoing assurance that the software security controls and security activities are effective and satisfy all relevant control objectives.

The results of the Secure Software Assessment are the Report on Validation (ROV) and Secure Software Attestation of Validation (AOV), which the PCI Security Standards Council (SSC) reviews. Unlike regular PCI Reports on Compliance (ROC) and Attestation of Compliance (AOC) reports, the SSA reports are processed by the SSC, which is similar to how PA-DSS assessments were evaluated.

SSA applications are valid for 3 years and listed on the PCI Security Standards website. The vendor must confirm the status of the application for an annual attestation requirement. The three types of attestation include:

For all three of these attestation types, the vendor must submit an updated AOV to the SSC and pay a fee (unless the vendor is Secure Software Lifecycle Qualified Vendor). In the program guide, the PCI Security Standards Council outlines High Impact changes to the validated payment software that require a full SSA assessment for the application.

Meeting the requirements of the updated Secure Software Assessment does not have to be overwhelming. For organizations already familiar with the PA-DSS validation process the new SSF validation process will feel very similar. Ongoing engagement with your Secure Software Assessor throughout the year and/or between validations will help you efficiently navigate the lab testing and the validation process.