PCI Software Security Framework: All You Need to Know
Table of Contents
The goal of the PCI Software Security Framework is to provide developers of payment applications better security guidelines while providing the companies using payment applications with better tools to assess the security of the software they are using.
In many ways, this framework is similar in intent to the Payment Application Data Security Standard (PCI PA-DSS) that was first released in 2011. However, the PCI SSC felt that a fresh framework is needed to address new methods and practices adopted by software developers.
PCI’s CTO Troy Leach explains that, “Software development practices have evolved over time, and the new standards address these changes with an alternative approach for assessing software security.”
These practices include heavily relying on open source components and integrating security tools into the DevOps pipeline in order to speed up development and meet shorter time to market. Another change is the entry of new security technologies enabling more proactive and impactful layers of defense.
With any new set of standards or regulations that impact an industry, especially one as sensitive as payments, there are bound to be plenty of questions about what the new guidelines are and why are they needed. Even if a system has its flaws, change are often met with a healthy measure of skepticism.
What is in the PCI software security framework?
Under the PCI Software Security Framework, we now have two new sets of standards for assessing the security of payment industry software: the PCI Secure Software Standard (PCI SSS) and the PCI Secure Software Lifecycle Standard (PCI Secure SLC).
The first standard, the PCI SSS, outlines security requirements and assessment procedures to help ensure that payment application developers adequately protect the integrity and confidentiality of payment transactions and data.
The second standard is the PCI Secure SLC which aims to guide development teams on how to maintain a good application security throughout the software development lifecycle (SDLC).
These standards deal directly with the continuous security needs of developing payment applications, putting in place an ongoing process with clearly defined steps for the use of testing tools. “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,” says Leach.
PCI SSC and open source
It is now universally accepted that it is simply nearly impossible to develop commercial software without using open source components nowadays. It is also been established that ensuring the open source components in your software are secure requires different tools than securing your proprietary software.
While the PCI Secure SLC guidelines requires integrating software vulnerability testing tools and implementing processes to ensure the integrity of the code, it also makes a specific citation of the need to use tools that secure and manage the open source components in your applications.
Under the old guidelines of 6.1-6.5 of PCI-DSS, the thrust was far more focus on responding to security vulnerabilities after they were already discovered, putting an emphasis on the responsibility to patch within a month.
In section 3.2b of the new PCI Secure SLC document, the guidelines take a different approach, stating that:
Where open source software components are utilized as part of the software, the assessor shall examine vendor evidence, including process documentation and assessment results to confirm these components are managed as follows:
An inventory of open source components used in the software is maintained.
A mature process exists to analyze and mitigate the use of open source components with known vulnerabilities.
The vendor monitors vulnerabilities in open source components throughout their use or inclusion in the vendor’s software to determine when new vulnerabilities are identified.
An appropriate patching strategy for the open source components is defined.
What stands out from a reading of these new guidelines in the PCI Secure SLC is that they are taking a distinctly shift left approach to security, encouraging vendors to continuously track which open source components they are using and block those with known vulnerabilities from ever entering their products. This approach seeks to head off risks before they become a threat to the product, and make them better prepared to respond quickly and efficiently when new vulnerabilities are discovered.
In order to achieve compliance, vendors will need to automate their open source usage management with Software Composition Analysis (SCA) solutions. SCA tools integrate into the SDLC (IDEs, repositories, build tools, CI servers, and more) and automate open source components approval processes, initiate remediation processes automatically, trigger real-time alerts, and generate on-demand reports along with other features.
Related: Open Source License Compliance
Will compliance with the new PCI software security standards be a bumpy ride ahead?
As noted above, change can be a painful process as vendors scramble to ensure that they are compliant with the necessary regulations.
Thankfully, the PCI team is making an effort to make the transition to the new standards a smooth one for vendors, laying out a timeline for implementation that they expect to be carried out over the next few years. During that time, measures put in place by vendors to be compliant under the existing PCI PA-DSS will continue to be honored.
In the lead up to this transition period, Leach says that assessor programs are, “Being developed to support these standards as part of the PCI Software Security Framework. We will provide more information on these new programs over the next few months.”
While this may leave many vendors feeling like their future is up in the air until the dust settles about how these guidelines are meant to be put into practices, there is hope as Leach says that they will work with vendors with the understanding that they need to “offer a progressive approach that allows for additional alternatives to demonstrating secure software practices.”
In the meantime, readers can review the full set of guidelines on their own by downloading the document from the PCI’s library.
