Ever since its formation in 2006, the PCI Security Standards Council (PCI SSC) has been striving to increase the security of the payment solutions and protect merchants against the latest security threats. In order to achieve this, PCI SSC had to continuously update their standards to keep up with the technologies that have emerged and revolutionized the software development industry.
The Payment Application Data Security Standard (PA-DSS) has been established as the go-to framework for becoming PA compliant. In contrast to PCI-DSS, which is mandatory for all organizations that process, store, or transmit credit card data, PA-DSS is required for applications taking part in the payment process. PA-DSS compliance is only necessary if the applications are sold, distributed, or licensed to third parties.
For example, if you open an online store to sell goods, your e-commerce application is covered under the PCI-DSS scope. On the other hand, if you want to create an off-the-shelf e-commerce solution to sell, then you need to comply with the PA DSS guidelines.
To better align with the latest technologies and development methodologies in use today, PCI SSC announced on January 16th, 2019, the release of a new security framework for payment software vendors that will eventually replace the current PA-DSS by 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 PA-DSS, this new standard was built on a different approach that supports both traditional software development practices and modern agile methodologies.
Therefore, PCI SSF is more focused on particular software security details and was created with the understanding that software security should be addressed throughout the entire software development lifecycle, and not just at the end.
The framework consists of two standards:
- The Secure Software Standard which was designed for traditional application testing. Basically, it is a revamped version of PA-DSS, with modern requirements that support the latest technologies and a wide range of payment software types.
- The Secure Software Lifecycle (Secure SLC) Standard which is an optional standard that focusses on implementing security concepts and activities throughout the entire software development lifecycle.
This article discusses the Secure SLC Standard and touches on its benefits and objectives.
Secure SLC Program - Overview
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 much needed.
The Secure SLC is the first PCI standard that focuses on the vendor’s software development process and its methodologies and not on the payment application itself. The goal of this standard is to incorporate payment application security principles early in the vendor’s development process and to offer better security guidelines that can be easily implemented within current industry accepted SDLC practices.
PCI 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” (PCI SLC).
As the PCI SSC Chief Technology Officer Troy Leach says, “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 that you have a mature secure software development lifecycle in place. This results in software that is secure by design and capable of withstanding attacks in order to protect payment transactions and users’ sensitive data. “Achieving this validation demonstrates an understanding and commitment to those continuous changes throughout a payment application’s lifecycle,” says Leach.
There are several important differences between Secure SLC Standard and other previously released PCI standards:
Different approach compared to PA-DSS
The Secure SLC Program was built on an objective-based approach and a modular design to offer more flexibility for vendors. Therefore, this approach acknowledges that 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 requires a robust risk-management practice as part of vendors’ business routine in order to ensure efficiency. This automatically implies that the vendor should adapt their software security controls based on newly identified threats.
While this approach offers a certain level of flexibility, the vendor needs to 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 this situation, it’s up to the vendor to choose the level of rigor or frequency according to their business needs. However, this decision should also 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 of 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 some low impact changes to its software without the need for re-validation by an assessor.
Additionally, the SLC certification process offers some new certification options that previously were not available under PA-DSS. It also worth mentioning that the SLC certification will have a three-year validity period.
Security training at the core of the standard
The purpose of the Secure SLC Program is to embed modern security mechanisms and procedures into the vendor’s software development process from the very beginning. In order to preserve the integrity of payment transactions and the confidentiality of sensitive data the standard takes a “shift left” approach. Thus, security training for all personnel involved in software development becomes a fundamental necessity and should be considered a top priority.
In the new Secure SLC Program, employee 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 personnel. The SLC standard requires organizations to implement and maintain a mature process for managing software security skills for software development personnel. This means that all personnel should have at least a basic understanding of general software security concepts and best practices, while individuals with specialized roles and responsibilities should additionally 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, and additionally, the software developer should possess secure coding skills, while the software architects should be knowledgeable in secure software design.
Continuous Testing and Monitoring
One important part of any Secure SDLC framework is continuous testing and monitoring, and this new standard highly emphasizes this aspect. Continuous Testing and Monitoring, in the context of the Secure SDLC, is an automated, ongoing process that enables a vendor to detect and mitigate security and performance threats in a timely manner.
This step is critical to continually review the organization’s processes for adherence to and deviations from their intended levels of security and to provide ongoing improvement.
The SLC standard requires vendors of payment software to continuously test their application security mechanisms. Additionally, they 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., new 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 PCI 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 a codebase comes with additional security risks, as they can contain vulnerabilities and are highly exposed.
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 clearly claims that it is the vendor’s responsibility to ensure the security of the used OSS components. Additionally, the vendor needs to provide relevant evidence of proper management of OSS components which includes:
- an inventory of OSS components used in the software
- how OSS components are monitored to determine when new vulnerabilities are identified
- an appropriate patching strategy
In order to be compliant, vendors should start by creating an open source software policy that can assist employees in certain situations. This policy should clearly state what 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 need to be monitored throughout the entire product life cycle. Since you cannot fix a vulnerability in an OSS component that you are not aware of, keeping an inventory of the OSS components becomes an essential step. Fortunately, there are numerous Security Orchestration, Automation, and Response (SOAR) tools that can help you identify threats quicker and make mitigation efforts much easier.
Nevertheless, all your efforts to maintain a healthy OSS policy will be 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 components, patch it in a timely manner. To understand how important this is, keep in mind that the main cause for the Equifax data breach was not the vulnerability itself, but not fixing a critical vulnerability that was publicly available for three days prior to the breach.
When does it come into play?
Since the Secure SLC Program is part of the new SSF framework, the following information is applicable to the entire SSF framework and not just to the SSLC Program.
As mentioned previously, PA-DSS is set to expire at the end of October 2022, when it will be completely replaced by the new SSF framework. Until then, both will be available and vendors can still apply for PA-DSS validation. After October 2022, all PA-DSS validated applications will have a “Valid for pre-existing deployments only” status.
The transition to a new compliance framework can be a painful process, so vendors are encouraged to start adapting to the new standard as soon as possible to avoid falling out of compliance when their PA-DSS certification expires.
Fortunately, the PCI team helps make this process as smooth as possible, and the three-year transition period should give vendors enough time to adjust their processes and align with the new standards.
Learn about HackEDU’s training to help meet Secure SLC compliance here: https://hackedu.io/secure-development-training.