A step towards more security: Our expert’s examination of the PCI Software Security Framework

In January 2019, the PCI Security Standards Council first announced the introduction of the new Software Security Framework (SSF) which currently includes two new standards: The Secure Software Lifecycle Standard (Secure SLC) and the Secure Software Standard.

With the respective certifications, payment software providers can prove that both their payment software as well as their development processes meet comprehensive and strict security standards for the protection of payment data. The SSF will replace the Payment Application Data Security Standard (PA-DSS), the current security standard for payment software issued by the PCI Security Standards Council, within the next few years.

The Secure Software Standard consists of core requirements supplemented by specific requirements in the form of modules. Currently, only module A exists. It is used for payment applications that store, process or transmit credit card data. Further modules, for example tailored to specific technologies, will be added in the future.

The Secure SLC on the other hand is an optional corporate certification that allows software vendors to demonstrate that they have integrated comprehensive security measures into their full software lifecycle. The advantage of this integration is that security measures are not only taken into account during the implementation of the software, but already during planning and all following phases such as publication/delivery and subsequent maintenance.

As these are two independent certifications, the PCI SSC will maintain separate lists on its website containing payment software validated according to the Secure Software Standard as well as Secure SLC qualified providers. In order to perform the certification, both accreditations, as a Secure Software Assessor and Secure Software Lifecycle Assessor, are required.

Torsten Schlotmann, Managing Consultant PCI Security Services, has been certifying companies as an accredited PCI DSS and PA-DSS assessor for many years and has been following the development of SSF from the very beginning. We asked him some questions:

Torsten, why does the PCI Security Standards Council see the need to replace PA-DSS with new data security standards?

Torsten Schlotmann: The IT industry is constantly evolving due to technical innovations, such as new payment technologies. The current PA-DSS is not designed to reflect all aspects of technical change, methods and current practices in the industry.

To what extent does the SSF better respond to these developments?

TS: In contrast to the PA-DSS, the two SSF standards basically follow a result-oriented approach that does not focus on the manner but on the effect of a security measure. This opens up flexible, customized options for software manufacturers to implement and prove security measures instead of a standard solution.

For example, if a company is certified according to the Secure SLC, qualified, in-house employees are allowed to check certain changes to already validated payment software for compliance with the Software Security Standard. By comparison, PA-DSS requires to consult an external, accredited assessor even for minor changes to validated software if those changes affect the security of credit card data, for example. Thus, the Secure SLC particularly supports agile software development processes.

Moreover, a much wider range of payment software can be certified according to the Secure Software Standard. Only applications that store, process or transmit credit card data in settlement or authorization processes are certified according to PA-DSS. In contrast, software products that are also involved in, support or facilitate the payment process outside the settlement or authorization process, such as clearing applications, can also be certified under the SSF.

Are the efforts required to achieve a certification according to SSF greater than those required for PA-DSS?

TS: The framework comes with more requirements in a more detailed and greater depth of testing. However, we expect the efforts to shift rather than simply grow. In PA-DSS, the focus was primarily on the security of credit card data. This changes with the SSF, which requires extensive scoping. The aim is to identify assets worth of protection and critical assets that are not limited to credit card data. Subsequently, protection objectives (control objectives) must be checked for each identified asset. At first glance, this might sound like more effort. But SSF also offers software manufacturers completely new opportunities to make massive savings in regards to effort. Companies certified according to the Secure SLC, for example, have to resort to external assessors much less frequently.

What awaits companies that want to be certified according to the SSF in the future?

TS: Changing to a new standard is always associated with initial effort for affected companies. They have to review the new requirements in advance and ensure that their measures and processes conform to the the new standards. The PCI Council has planned a transition phase for this so that new applications can be certified according to PA-DSS until June 2021 and changes to already certified applications are even possible until October 2022. Parallel to this, the first SSF certifications are expected to be issued in the course of this year.

We advise our clients to familiarize themselves intensively with the new framework before the PA-DSS is ceased and to approach necessary changes as early as possible. We are happy to support them in this. Since we know that the requirement of the SSF are applied very differently for each company, we offer specific consulting and analysis services for preparation and, of course, also carry out the actual certification.

My colleagues and I have followed the standard from the beginning. We think the replacement of PA-DSS by the SSF is a good step towards more security.

You have questions about the Software Security Framework or need support? Contact us, we are happy to help!