The reality of PCI SSF: What Sellers, Entities (and Advisors) Keep Ignoring

This is the first article in a series dedicated to breaking down the PCI Software Security Framework (SSF). In future deliveries, we will delve into technical details and specific use cases, but today we start with the foundations.

In the payment security ecosystem, standards are not static; evolve to respond to threats that change on a daily basis. However, in my day-to-day life as an advisor, I have noticed a worrying disconnect. Even though the PCI Software Security Framework (SSF) For some time now, there is a widespread knowledge gap.

It's not just that Sellers or Entities are confused. The most alarming thing is that even some Advisors (QSAs) do not know how to correctly evaluate an application certified under this new framework.

Today I want to put aside the deep technicalities to speak clearly about what this framework is and address the "bad practices" that I see repeated, audit after audit, by all the actors involved.

What is PCI SSF?

To understand it easily: the PCI SSF is the natural and necessary evolution of security in the development of payment software. Unlike its predecessor (PA-DSS), this framework is more flexible and modular. It is divided into two distinct but complementary standards:

1. Secure Software Standard [The Software]: It focuses on the application itself. Assess that payment software is designed and built to protect sensitive transactions and data. It is the validation by laboratories that "the application is safe".
2. Secure SLC Standard [The Development Process]: It focuses on the seller's development life cycle. Here we do not validate a specific software, but the maturity of the manufacturer to produce secure software continuously. It is the validation that "the factory works safely".

So far the theory sounds good. The problem comes when we land this on the reality of implementations and evaluations.

Clarification note: Although there are certifications PCI Secure Software Standard (SSS) and PCI Secure Software Lifecycle (SLC), it is not correct to claim that an organisation holds an ‘SSF certification’ or that it is ‘SSF certified’. The PCI Software Security Framework (SSF) is not a certification per se, but a framework that brings together both of these certifications.

The death of the PA-DSS and the trap of the "Pre-existing Installation"

PA-DSS standard expired. Point. However, the PCI Council allows its use only forpre-existing facilities‘. Many cling to this clause as a lifeline, but here comes my professional opinion:

It's been too long since the expiration of PA-DSS. Technology is advancing very fast. It is highly likely that the infrastructure (hardware, operating system, databases) on which that original installation was approved has already changed, been updated or is obsolete.

If the infrastructure changed, that security validation no longer works. Maintaining PA-DSS software in a modern environment that does not correspond to its original certification is living with a false sense of security.

The big mistake: The Implementation Guide and the Consultant's Pleasure

All software validated under the Secure Software Standard comes with a Implementation Guide (Implementation Guide – GI). This is not a suggestion manual; It's a normative bible. The application must be installed exactly on the infrastructure and versions of the Operating System indicated in this guide and listed on the official portal of the PCI Council.

Colour Orange: Approved versions and dependencies and effective date.

Colour Green: Software standard and status.

Link PCI SSC Validated payment software: https://listings.pcisecuritystandards.org/assessors_and_solutions/payment_software

Link PCI SSC Validated SLC vendors: https://listings.pcisecuritystandards.org/assessors_and_solutions/software_lifecycle

I have witnessed on several occasions the following scenes:

1. An entity installs the software in a different version of the Operating System than the validated one or, failing that, installs a version of the application different to the one listed on the PCI Council portal.
2. The Seller argues: Other customers have been allowed to do so, they have this same implementation and their QSA accepted them as valid.
3. The Advisor or QSA that reviews the environment overlooks this detail, either for ignorance of how to consult the official list or for lack of rigor when comparing the implementation guide.

This is a bad practice that must end.

As advisors, we have a responsibility to be strict: if the PCI Council portal and Implementation Guide read "Version X.1", it cannot be "Version X.2". If the versions do not match, this implementation cannot be considered as ‘Quality’, regardless of what the seller says or whether a previous consultant has made the mistake of ‘giving him the go-ahead’.

Validating an application outside of its certified parameters breaks the chain of trust. The PCI SSF seal ensures safety in a controlled and tested environment; outside that environment, there are no guarantees.

Conclusion

The transition to PCI SSF is not just a change of acronym; is a change of mentality and rigor.

• To the Sellers: keep your validations up-to-date with modern infrastructures and offered to your customers, especially the commercial staff you are happy to sell without dimensioning the impact. It involves the staff carrying the certification to confirm that what they offer is indeed viable.
• To the Entities: do not accept excuses about "half-way" versions or compatibilities. Advise yourself with your QSA before installing, accepting different versions or changes in the application.
• And to my fellow Advisors: It is time to study the guidelines thoroughly. Our signature on a report should mean that alignment with the Official Implementation Guide has actually been verified.