As you are probably aware, the Payment Card Industry Security Standards Council (PCI SSC) announced it would be phasing out the Payment Application Data Security Standard (PA-DSS) this year, which has been in place since 2008 for a new framework called PCI SSF (Payment Card Industry Software Security Framework).   

Introducing a Modern, Modular Security Assessment  

PA-DSS was created from the Visa’s Payment Application Best Practices (PABP) standard to help software vendors develop secure payment applications that remain in compliance with the Payment Card Industry Data Security Standard (PCI DSS).  The PCI DSS framework is a set of security standards to ensure all companies maintain a secure environment that have the ability to transmit, process, store or can affect the security of the credit card information.   

The intention of the PCI DSS framework standards is to give organizations that require payment applications a level of assurance that an application can be run in a compliant manner. It also provides clear instruction from the vendor to the software user on how the software should be configured to be compliant.   

Certification via PA-DSS provides validation for a three-year cycle and is specific to assessed versions of software and to the platform it was tested on — meaning that every time a new major version is released or new platform is supported, PA-DSS would require a full validation and submission to the PCI SSC.  

Since its development in 2008, the payment industry has changed drastically. Today there are a variety of different technologies to consider, like kiosk systems and cloud systems, among others. Even mobile applications were in their infancy at the time PA-DSS was developed. As a result, this standard became more limited as it did not allow for a lot of flexibility to accommodate newer payment technologies. Given this, a new and more modular framework was needed to encompass the security needs of more application types.   

Introducing PCI SSF, which modernizes the assessment process and allows for more flexibility and development in the future. A key change within SSF is a separation of the secure development lifecycle and the secure software assessment into two different assessments. This change allows organizations to validate their Secure Software Lifecycle and ensure proper controls are in place prior to reviewing any specific application. It also offers vendors that complete a Secure Software Lifecycle validation more flexibility to perform their own delta assessments and report back to the PCI SSC directly for those applications assessed under the Secure Software program and can reduce the need to engage an SSF company every year.  

The new PCI SSF includes two fundamental components:   

• The Secure Software Lifecycle (Secure SLC) Assessment which applies to the software development lifecycle of the organization developing a payment application  
• The Secure Software Assessment which covers the security of specific payment software packages itself   

It’s important to note that these two components are mutually exclusive, and while an organization may require an assessment of its payment application, it does not necessarily require a separate assessment of the entities Secure Software Lifecycle. However, there are benefits gained from obtaining a Secure SLC validation prior to assessing individual software packages under the Secure Software Assessment from incentives the council provides to vendors who achieve both compliance validations.    

So, what does this mean for you? Let’s take a deeper look at the Secure Software Lifecycle (Secure SLC) portion of the new framework.   

The New PCI SSF: Secure SLC Standard  

The Secure SLC portion of the PCI SSF addresses the development practices under which software products are built. The standard calls for proper policies and documentation, rigorous testing, training, and other secure development controls to help software vendors protect sensitive data, minimize vulnerabilities, and defend software from attacks throughout the entire development lifecycle.   

The Secure SLC requirements apply to more than just development practices; they also extend to the technologies used and any personnel involved in design, development, deployment, or maintenance of the software product.   

To pass assessment under the new Secure SLC guidelines, vendors must adhere to requirements categorized into four main sections:  

1. Software Security Governance   

A formal governance program must be established to demonstrate the vendor’s commitment to building secure software and protecting sensitive data. The governance program must include clearly assigned responsibilities throughout the team and ensure that team members have the proper skills and training for their role. Further, the program must ensure that the vendor properly identifies and monitors relevant security and compliance requirements and documents specific rules related to how products will be developed in a secure manner.  

2. Secure Software Engineering  

This section of the requirements focuses on protecting critical software assets and ensuring software is resistant to attacks. Threats to software design must be continuously identified and assessed throughout the development process, and controls must be put in place to minimize those threats. There are also a variety of elements included in this section of the requirements related to detecting and fixing vulnerabilities in a timely manner.  

3. Secure Software and Data Management  

To comply with this section of the requirements, vendors must have a process in place to identify, assess, and approve software changes, and formally track software versions. An additional component to this section is to set boundaries around data collection. Doing so ensures that software vendors only collect and retain data throughout the development process when there is a legitimate business or technical need.   

4. Security Communications  

To comply with the Security Communication aspect of the Secure SLC requirements, vendors must set up proper communication channels to receive information about security issues and report information about mitigation options in a timely manner to all necessary parties. This section also calls for a summary of changes to be provided to stakeholders upon release of any software updates.  

Exploring PCI SSF’s Modular System   

As we mentioned, the new PCI SSF also includes a Secure Software Assessment. The Secure Software Assessment is a modular system and includes variable certification elements for different types of products as it relates to the security of the payment software itself.   

The combination of the Secure SLC and the Secure Software Assessment allows the program, as a whole, to accommodate the evolving landscape of payment applications and services. It enables any newly developed applications to leverage these controls to help ensure an organization’s compliance to the secure software standard. It also provides a benefit allowing organizations to submit their own annual revalidation for administrative and low impact changes (Delta changes) and submit those directly to the PCI SSC without requiring review and submission by a PCI-qualified Secure Software Assessor Company.   

Those software vendors that are not a Secure SLC Qualified vendor, will require a Secure Software Assessor to submit their Delta reviews. For all software vendors, high impact changes will require a full software validation by a Secure Software Assessor Company.   

How to Prepare for Secure SLC and the Secure Software Assessment  

For existing PA-DSS certified software vendors, our team can also assist you with mapping a transition to the new framework promptly, so you can maintain compliance without risking any gaps after PA-DSS is officially expired in October 2022. Always remember, those who engage early have a significant advantage. Organizations often underestimate the amount of effort required or have competing priorities that come up at the last second, which leads to project delays. So getting ahead of this change will ensure no negative impact on your current listings and help you manage this transition so it goes smoothly. The PCI SSC reviews for each submission can take some time, so plan ahead to ensure you maintain compliance in a timely manner.   

The best thing you can do to make sense of the new requirements and prepare for the Secure SLC and/or the Secure Software assessment is find a true partner that is certified as a Secure Software Assessor Company, such as A-LIGN, to help your team. Our team of experts have years of development experience and have met the rigorous new standards set forth for all SSF assessor companies.   

We also will utilize our existing technologies, such as A-SCEND, to help manage the assessment process from start to finish and help streamline the assessment process for your organization. This gives us the ability to map all common controls within our A-SCEND platform between both the Secure Software Lifecycle and Secure Software Assessment and with other standards as well, such as the new NIST 800-218. Our A-SCEND platform will put you in a better position to meet new compliance demands that your customers or partners bring to you in the future.  

Keep an eye on our blog for a follow-up post where we dive into the Secure Software Assessment aspect of PCI SSF in more detail.  

Does your organization need assistance mapping your approach to the new PCI SSF before your current PA-DSS application officially expires? A-LIGN’s Qualified Security Assessors (QSA) are available now to assist you with any of your PCI SSF needs. Contact us today at [email protected] or 888-702-5446.