To assist stakeholders in their migration from PA-DSS to the Software Security Framework, PCI Security Standards Council (PCI SSC) is publishing a series of blog posts to guide payment software vendors and assessors through the key differences between PA-DSS and the SSF. In Part One of our multi-part blog series, PCI SSC’s Sr. Manager, Public Relations Alicia Malone sits down with PCI SSC’s Sr. Manager, Emerging Standards Jake Marcinko to discuss some of the conceptual differences between PA-DSS and the Software Security Framework that stakeholders should be aware of as they work to transition between programs.
What is the PCI Software Security Framework?
Jake Marcinko: The PCI Software Security Framework (SSF) is a collection of security standards and associated validation and listing programs for promoting software security in the payments industry. The SSF is comprised of the Secure Software Standard and the Secure Software Lifecycle (Secure SLC) Standard.
The Secure Software Standard defines the security features and attributes that payment software must possess, and the Secure SLC Standard defines the security processes and capabilities that a software vendor must have in place to ensure its software is developed securely.
The SSF replaces the PCI Payment Application Data Security Standard (PA-DSS) which is being retired in October 2022.
Why was the Software Security Framework created and why is PA-DSS being retired?
Jake Marcinko: PA-DSS was one of the first standards and programs of its kind. It laid the groundwork for software security in the payments industry, and it has served the payment industry’s needs for over 10 years. Those needs, however, have evolved to the point that it no longer made sense to make incremental changes to an aging standard and program. A new approach was needed to support modern payment software architectures and software development methodologies, and to protect payment software from increasingly complex software attacks.
What benefits does the Software Security Framework provide over PA-DSS?
Jake Marcinko: The SSF builds on many of the concepts introduced in PA-DSS but is designed to provide both software vendors and assessors a more dynamic, faster-to-market approach to security validation for a broader array of software types compared to PA-DSS.
In PA-DSS, the scope of software eligible for validation and listing was limited to software that facilitates payment authorization. Under the SSF, the eligibility criteria for software validation has been expanded to include software providing additional functions such as fraud monitoring or cardholder authentication. Additionally, by separating software requirements and vendor requirements into different standards, vendors who produce software that is ineligible for validation to the Secure Software Standard are able to demonstrate good software security hygiene through independent Secure SLC validation.
PCI SSC recommends that software vendors with eligible payment software products have both their software development lifecycle (SDLC) practices and payment software validated to the respective SSF standards. Validating to both standards not only demonstrates that a vendor’s payment software is secure upon validation, but also demonstrates greater assurance that the software will remain secure throughout its lifetime. To encourage validation to both standards and to support faster time-to-market strategies, the SSF provides a more streamlined listing management process to Secure SLC qualified software vendors with validated payment software. This process enables qualified software vendors to manage and publish updates to their validated payment software listings more quickly than previously supported under PA-DSS.
More information on these and other benefits can be found in the respective Program Guides under the Software Security section of the PCI SSC Document Library.
What are ‘objective-based’ requirements in the Software Security Framework and how are they different from PA-DSS requirements?
Jake Marcinko: PA-DSS requirements specify the practices and security controls that must be implemented to meet a particular security objective. The SSF supports a newer approach among PCI security standards, including the PCI 3-D Secure (3DS) security standards and the Customized Approach in PCI DSS version 4.0, where security requirements are expressed as security objectives that provide greater flexibility in how requirements are met. This approach is referred to as ‘objective-based’ and recognizes that there are often many different ways to satisfy a particular security objective.
How does the objective-based approach provide software vendors more flexibility?
Jake Marcinko: The objective-based approach enables software vendors to choose the practices and methods that best meet the security objectives given the entity’s unique business requirements and capabilities, rather than having to implement the specific practices and methods stipulated in more prescriptive security standards such as PA-DSS.
For example, where PA-DSS requires the use of specific password complexity parameters such as minimum length and composition, the corresponding control objective in the Secure Software Standard requires that authentication methods be ‘sufficiently strong and robust to protect authentication credentials from being forged, spoofed, leaked, guessed, or circumvented’ in accordance with industry-accepted methods. This enables software vendors to choose which industry-accepted authentication methods to implement to meet the control objective rather than having to implement the password complexity parameters stipulated in PA-DSS.
How does the objective-based approach benefit security assessors?
Jake Marcinko: The testing procedures in PA-DSS specify the verification methods that assessors are required to use to validate security requirements, with limited flexibility. The SSF permits assessors to deviate somewhat from the methods stated in the test requirements where necessary. This is referred to as ‘alternative testing’ and it permits assessors to use alternative verification methods if the stated methods aren’t sufficient to properly validate the control objectives.
For example, many SSF test requirements require examination of software vendor documentation and evidence to validate control objectives. In certain circumstances, it may be more appropriate to validate a control objective using interviews or other assessor-provided tools. Under the SSF, assessors are permitted to use such verification methods even if those verification methods aren’t explicitly stated in the test requirement. This provides assessors greater flexibility in determining how best to confirm control objectives have been met. The use of alternative testing does not allow assessors or software vendors to change what the test requirement is verifying, or to reduce the thoroughness of the testing.
How does the Software Security Framework’s support for PCI DSS differ from PA-DSS?
Jake Marcinko: PA-DSS was developed explicitly to facilitate PCI DSS compliance for entities implementing payment applications in a cardholder data environment. The SSF was developed with broader applicability in mind and covers a broader range of security topics and data assets than PA-DSS and PCI DSS. The SSF is also intended to apply to payment software and software vendors regardless of whether PCI DSS applies to the environment in which the payment software is deployed.
For these reasons, the security requirements in the SSF standards do not map directly to PCI DSS requirements like the PA-DSS requirements do. With that said, the SSF security standards still support an entity’s PCI DSS compliance by enabling entities who use qualified software vendors and/or validated payment software to potentially meet some PCI DSS requirements without the need for additional detailed testing.
For example, bespoke or custom software provided by a Secure SLC qualified software vendor is confirmed to have been developed in accordance with a rigorous set of secure software development best practices. The use of such software by a merchant or service provider (who may also be the Secure SLC qualified software vendor) may satisfy a number of sub-requirements under PCI DSS Requirement 6 without the need to have those sub-requirements retested by a QSA.
Similarly, payment software that has been validated to the Secure Software Standard is confirmed to possess robust sensitive data protection mechanisms. Use of such software by a merchant or service provider may satisfy corresponding requirements in PCI DSS for the protection of cardholder data and authentication credentials during storage and transmission.
Entities anticipating the publication of PCI DSS v4.0 should expect even greater alignment between PCI DSS and the SSF standards with the introduction of the Customized Approach. Please refer to the PCI SSC website for more information on PCI DSS v4.0.
How will the differences between PA-DSS and the Software Security Framework impact vendors of currently validated PA-DSS applications?
Jake Marcinko: It is possible that some vendors with PA-DSS validated applications may need to upgrade their software or software development practices to meet applicable SSF requirements. This isn’t intended to undermine the value that PA-DSS validation has provided over the years. Given the increasing complexity of modern software and the sophistication of modern software attacks, the SSF standards contain additional requirements that weren’t included in PA-DSS.
PCI SSC recognizes that there are a number of important differences between PA-DSS and the SSF, and a lot of information about the Secure Software and Secure SLC standards and programs that stakeholders must absorb. To assist with the transition between PA-DSS and SSF, PCI SSC is offering informational training classes for software vendors; details can be found in the Training and Qualification section of the PCI SSC website. Software vendors with validated PA-DSS applications are also encouraged to start working with a qualified SSF assessor company to help understand the differences and to begin the transition to SSF before PA-DSS is retired in October 2022.
Coming Soon: In Part Two of this blog series, we will discuss some of the key technical differences between PA-DSS and the SSF, including what critical assets are and why they are important; how cryptography and data storage requirements are different; and how the concept of the PA-DSS Implementation Guide has evolved. If you have any questions or topics related to the PA-DSS to SSF transition that you would like us to clarify in guidance, please forward those to software@pcisecuritystandards.org.
Read more about the Software Security Framework.
