Published on
Ever since its formation in 2006, the PCI Security Standards Council (PCI SSC) has worked to improve the security of payment solutions and protect merchants against the latest security threats. In order to accomplish these goals, PCI SSC regularly updates their standards to keep up with emerging technologies that continue to revolutionize the software development industry.
The Payment Application Data Security Standard (PA DSS) has been the go-to framework for becoming PA compliant for many years. In contrast to PCI DSS, which is mandatory for all organizations that process, store, or transmit credit card data, PA-DSS is only required for applications involved in the payment process. Further, PA-DSS compliance is only necessary if the application is sold, distributed, or licensed to third parties.
To stay aligned with emerging technologies and development methodologies, PCI SSC is retiring the original PA DSS model and replacing it with the PCI Software Security Framework (SSF). This change became effective at the end of October 2022.
What is the PCI Software Security Framework?
The new PCI Software Security Framework (PCI SSF) is a collection of standards and programs for the secure design and development of payment software. While similar to the original PA DSS, this new standard was built to support both traditional software development practices and modern agile methodologies.
PCI SSF is focused on particular software security details. It was created with the understanding that software security should be addressed throughout the entire software development lifecycle -- not just at the end.
The framework consists of two standards:
- Secure Software Standard -- designed for traditional application testing. It is a revamped version of PA DSS, with modern requirements that support the latest technologies and a wide range of payment software types.
- Secure Software Lifecycle (Secure SLC) Standard -- an optional standard that focuses on implementing security concepts and activities throughout the entire software development lifecycle.
This article discusses the Secure SLC Standard and explains its benefits and objectives.
Overview of the Secure SLC Standard
In the last few years, new software development practices such as continuous integration/delivery (CI/CD), Agile, and DevOps have been widely adopted by development teams. Thus, the release of a new, modern security standard that supports these practices was needed.
The Secure SLC is the first PCI standard that focuses not on the payment application itself but on the vendor’s software development process and methodologies. The goal of this standard is to incorporate payment application security principles early in the vendor’s development process and offer better security guidelines that can be easily implemented within current industry-accepted SDLC practices.
Secure SLC is designed to support a wider range of technologies, payment software types, and development methodologies compared to PA DSS. This new standard addresses key security principles such as governance, threat identification, vulnerability detection and mitigation, security testing, change management, secure software updates, and stakeholder communications.
As PCI SSC Chief Technology Officer Troy Leach notes, “this provides confidence to businesses using the payment application that their software vendor is providing ongoing assurance to the integrity of the software development and confidentiality of payment data as change occurs.”
The PCI Secure SLC Standard is intended for software vendors that develop software for the payments industry. Being Secure SLC certified demonstrates you have a mature secure software development lifecycle in place, including security awareness training for developers.
This results in software that is secure by design and capable of withstanding attacks in order to protect payment transactions and sensitive user data. “Achieving this validation demonstrates an understanding and commitment to those continuous changes throughout a payment application’s lifecycle,” says Leach.
What’s different?
There are several important differences between the Secure SLC Standard and other previously released PCI standards.
A new approach
The Secure SLC Program was built on an objective-based approach and a modular design to offer more flexibility for vendors. This approach acknowledges there is no silver-bullet solution when it comes to software security and vendors should be allowed the flexibility to choose the secure practices that best fit their organization's software development process.
However, the standard does require a robust risk-management practice as part of a vendor's’ business routine to ensure efficiency. This implies the vendor should adapt their software security controls based on newly identified threats.
While this approach offers a certain level of flexibility, the vendor must still provide clear evidence showing how the implemented controls are supported by the results of their risk-based decision making. Otherwise, the adherence to the requirements within the Secure SLC program may not be validated.
Also, there are requirements where PCI Secure SLC does not define a minimum frequency for recurring activities or a specific level of rigor. In those situations, it is up to the vendor to choose the level of rigor or frequency based on their business needs. However, the decision must be backed up by evidence that demonstrates effectiveness.
Self-attestation for low impact changes
To prove compliance with the new Secure SLC standard, a PCI-certified assessor evaluates the vendor’s secure software lifecycle management practices. The assessment takes into consideration all the vendor’s security procedures and focuses on vendor’s capabilities regarding threat modeling, vulnerability detection and mitigation, and security testing.
One interesting change that comes with the new Secure SLC standard is that an SLC-certified vendor is authorized to self-attest to low impact changes to its software without the need for re-validation by an assessor.
Additionally, the SLC certification process offers new certification options that previously were not available under PA DSS. Secure SLC certifications are valid for three years.
Security training is at the core
The purpose of the Secure SLC Program is to embed modern security mechanisms and procedures into the vendor’s software development process from the start. In order to preserve the integrity of payment transactions and the confidentiality of sensitive data, the standard takes a “shift left” approach. Security awareness training for developers and all others involved in software development becomes a fundamental necessity and this secure development training must be considered a top priority.
In the new Secure SLC Program, this training falls under the first Control Objective:
“The vendor’s senior leadership team establishes formal responsibility and authority for the security of the vendor’s products and services. The vendor allocates resources to execute the strategy and ensure that personnel are appropriately skilled.”
Therefore, the first requirement to be able to develop and maintain secure by design software is to have security trained team members. The Secure SLC standard requires organizations to implement and maintain a mature process for ensuring and managing software security skills for software development personnel.
This means that everyone in the SDLC should have at least a basic understanding of general software security concepts and best practices. Those in specialized roles with discreet responsibilities should also possess specialized skills relevant to the functions they perform.
For example, both a software developer and a software architect should have a basic understanding of security, but the software developer should also possess PCI secure coding skills and the software architect should be knowledgeable in secure software design.
Continuous Testing and Monitoring
One important aspect of the Secure SDLC framework is continuous testing and monitoring. In the context of the Secure SDLC, this is an automated, ongoing process that enables a vendor to detect and mitigate security and performance threats in a timely manner. It also provides the opportunity to provide ongoing improvements.
Additionally, vendors also have to provide evidence that continuous threat monitoring technologies are in place and the process is mature enough to adapt to changing conditions (e.g., emerging threats).
In order to be compliant, vendors can use Interactive Application Security Testing (IAST) tools that automatically identify and diagnoses software vulnerabilities in web applications. The main advantage of these testing tools is that they provide a higher level of accuracy by combining Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) without sacrificing software development speed.
Hygiene for open source software is now a requirement
Open Source Software (OSS) components such as frameworks, libraries, or modules are a useful resource for software developers as they can significantly speeding up the development process while reducing costs. However, implementing OSS components into a codebase comes with additional security risks, as they are highly exposed and may contain vulnerabilities.
According to Open Web Application Security Project (OWASP), the problem of using components with known vulnerabilities is highly prevalent. Moreover, the Open Source Security and Risk Analysis report claims that nearly 60% of all codebases used by enterprises contain at least one vulnerability from open source components.
But whose responsibility is to keep the open-source components bug free?
The new PCI standard makes clear it is the vendor’s responsibility to ensure the security of any OSS components used. Additionally, the vendor needs to provide relevant evidence of proper management of OSS components, including:
- inventory of OSS components used in the software
- explanation of how OSS components are monitored to determine when new vulnerabilities are identified
- appropriate patching strategy
In order to be compliant, vendors should start by creating an open source software policy that is easily understood by employees. The policy should clearly state which OSS components are allowed to be used, how they should be incorporated responsibly without damaging code quality, when they should be patched/updated, and how to prioritize vulnerabilities.
Additionally, all OSS components must be monitored throughout the entire product life cycle. Since you cannot fix a vulnerability in an OSS component that you don't know about, keeping an inventory of when and where OSS components are used becomes essential. Fortunately, there are numerous Security Orchestration, Automation, and Response (SOAR) tools to help you identify threats faster and make mitigation efforts easier.
Nevertheless, all your efforts to maintain a healthy OSS policy will be in vain if you do not have an appropriate patching strategy. The best patching strategy is to move fast on critical and high security vulnerabilities. As soon as you discover a vulnerability in your OSS component, patch it in a timely manner.
To emphasize just how important that last point is, keep in mind that the main cause for the Equifax data breach was not the vulnerability itself. It was the failure to fix a critical vulnerability that was publicly available three days prior to the breach.
When does Secure SLC go into effect?
The original PA DSS expired at the end of October 2022, and was replaced by the new SSF framework. Since the Secure SLC Program is part of the new SSF framework, it follows the same timeframe.
Until PA DSS was retired, both frameworks were simultaneously available and vendors could still apply for PA DSS validation. After October 2022, all PA DSS validated applications have a “Valid for pre-existing deployments only” status. All new deployments will require the new SSF validation.
