As you may be aware, the Software Security Framework (SSF) was released in 2019 and is set to replace the Payment Application Data Security Standard (PA-DSS) over the next couple of years. Stakeholders, such as merchants, application vendors, acquirers, security assessors and card brands should start planning for the transition, including creating awareness around the PA-DSS program deadlines.
Humble Beginnings (long before the Software Security Framework)
It all started back in October 2007 when Visa announced that all applications accepting Visa payments must adhere to the Payment Application Best Practices (PABP) starting January 2008. The PABP, rather than being a standard, was a set of 14 general security goals, rather than a set of specific requirements that needed to be met.
While this was a welcome addition to the security of payments, it only addressed the security of Visa payments. This was responded to by the Payment Card Industry Security Standards Council (PCI SSC) who jointly, with the other payment brands, issued the first version of the PA-DSS in April 2008.
The PA-DSS was a much more comprehensive approach to payment application security compared to the PABP, however, the first version of PA-DSS was never enforced on applications.
The version issued in April of 2008 was updated to version 1.2, which was released in October of 2008. This was the first official version of PA-DSS.
Version 1.2 of the standard was backed by all PCI-connected card brands and was highly successful in ensuring the security of payment transactions.
Payment Application Data Security Standard (PA-DSS)
Version 1.2 was succeeded by version 1.2.1 in July of 2009, then updated to version 2.0 in October of 2010. While these version changes were somewhat minor, the update to PA-DSS 3.0 in November of 2013 changed the game of how to approach compliance for payment applications.
Version 3.0 of the standard did not change as much in the requirements that needed to be met, but it required a much more wholesome approach by the security assessor to document testing and findings, which automatically put more onus on the effort required to validate any given requirement.
The PA-DSS was updated in May 2015, and again in May 2016 as direct responses to newly discovered vulnerabilities affecting protocols that were once thought of as being secure, such as Secure Socket Layer (SSL). The combination of PA-DSS being written as a standard with fixed requirements, paired with an ever-evolving threat landscape, required that payment application security needed to be more flexible.
This led to the successor of PA-DSS being released in 2019, the Software Security Framework.
The release of the Software Security Framework (SSF) in 2019, and the announcement of it superseding PA-DSS, is a welcome change from a security perspective. A framework, unlike a standard, contains the intent of the requirement rather than a set number of targets that need to be met. This allows for significantly higher flexibility by vendors and assessors when it comes to meeting and validating any given requirement, but with flexibility comes also increased complexity of how to perform validations.
Apart from the additional knowledge skills required by assessors, vendors must be much more involved in the validation process compared to PA-DSS. Readers of the new standard will realize that the vendor must test and produce evidence for each control, before being tested by the assessor. This allows the assessor to gain an understanding of the vendor’s security posture and maturity of their processes.
It’s important to note that the SSF is not a standard in itself. It contains two standards covered by the framework, the Secure Software Lifecycle (Secure SLC), and the Secure Software Standard.
The Secure SLC is a brand-new standard that allows vendors to validate their secure software development processes and be listed as a certified Secure SLC on the PCI SSC website. A validated Secure SLC vendor will be allowed to manage no-impact and delta changes to their applications themselves, without the involvement of an assessor. High-impact changes will require the software to be assessed by a Secure Software Assessor.
The Secure Software Standard is the successor of PA-DSS, while some requirements will be similar to those in the PA-DSS, it is truly a new standard and a new approach to compliance compared to what vendors and the market have been used to for the past 12 years.
While the name of the standard is indeed standard, it is a framework with security goals that need to be met, in whichever method is appropriate for the technology used. The Secure Software Standard contains a baseline set of requirements that apply to all applications. This is then tied to specific modules that are intended to be used for the type of software under review. The initial release of the standard only contains one module, which covers security requirements for securing account data. In 2020 a Request For Comments (RFC) went out for applications running on hardware terminals and is expected to be the next module to be added to the Software Security Standard in the upcoming months.
Transitioning to SSF
Vendors that have previously been validating against PA-DSS as well as new vendors should be aware of the dates for transitioning to the SSF. PA-DSS has a determined sunset date of October 28, 2022, with new validations being accepted through June 30, 2021, between July 1, 2021, and October 28, 2022, only application changes will be allowed by the PCI SSC.
As the new standard is very different from what we’ve seen in the past, vendors should plan for additional time to complete the first round of validations as compared to what they’ve been planning for PA-DSS.
SecureTrust is geared to assist you with any queries you may have, reach us at SSF@securetrust.com.
SecureTrust, a Trustwave division, leads the industry in innovation and processes for achieving and maintaining compliance and security. SecureTrust delivers world-class consulting, compliance and risk assessment services and solutions for the enterprise market as well as tailored merchant risk management programs and solutions for merchant program sponsors around the globe.
CLICK HERE to contact us for all Enterprise Compliance, Merchant Risk Management and Compliance Technology needs.
Johan Hagdahl is a part of SecureTrust’s Global Management Team. In addition to the management role Johan delivers compliance assessments, information security consulting, IT governance consulting, security gap analysis and risk assessments as a CISSP, CISA, CISM, Qualified Security Assessor and SSF Assessor, QSA including PA-QSA, QSA (P2PE) and PA-QSA (P2PE) enabling both solution provider and application validations.
He is also appointed the role as the director for PA DSS and P2PE globally, focusing on management, service delivery, methodology improvement and customer satisfaction efforts.