What is the New PCI Software Security Framework?

by Jason Zaffuto | Aug 30, 2022 | Compliance

A Presentation of Software Security Framework (SSF)

Most sectors have codified standards in place to safeguard workers, members of the general public, and specific organizations. The PCI, which comprises the five prominent credit card companies, ensures compliance with these requirements for software developers working in the retail sector. While PA-DSS has been the primary focus of attention for over a decade, it is scheduled to be decommissioned in October 2022.

The PA-DSS will be phased out and replaced by the new PCI Software Security Framework, which will become the principal compliance framework for payment application developers and software providers.

To be ready for the approaching change, you will need to be aware of the following things:

What are some of the differences between the SSF and the PA-DSS?
What brand-new criteria are being implemented?
When will the SSF be implemented, and what is the schedule for this?

An Examination of PA-DSS to the New PCI Software Security Framework

The PA-DSS was unofficially released in 2008, although the majority of developers have already been aware of the requirements that it contains. The SSF is the most recent standard released by the PCI, debuting in 2019. This new standard offers a higher level of data security and consumer safety.

PA-DSS

The Payment Application Developers and Service Providers (PA-DSS) standard were developed by the Payment Card Industry. It presents a comprehensive list of 14 precautions that must be satisfied to comply.

Protecting cardholder data (CHD) and personally identifiable information (PII), protecting network infrastructure against cyberattacks, testing software for vulnerabilities, and educating employees, customers, resellers, and end-users are the primary focuses of all of these precautions.

The PA-DSS will continue to be supported until the official sunset date of October 2022, when it will be replaced by the PCI Software Security Framework. This date does not change the PA-DSS sunset date.

SSF

The PCI Software Security Framework, which debuted in January 2019, is intended to completely replace the PA-DSS. PCI believes SSF to be an entirely distinct and different set of rules, even though it incorporates numerous components from PA-DSS and expands on many of the components of its predecessor. Both of these facts are true.

The overall objective of the SSF is to further standardize the process of developing payment software, reinforce the mechanisms for security, and create a more user-friendly experience for everyone. It does this by adding the following to the requirements that were first set in PA-DSS:

Increasing the robustness of data and software security across the board
Providing support for a more diverse selection of payment software
Streamlining the process through which developers may integrate next-generation security for payment applications
Increasing the degree to which software may be customized without compromising the safety of user information
Increasing the amount of openness and transparency across the software testing stages
Advancing innovative techniques for software development and programming
Keeping up-to-date official lists of the licensed software and reputable providers

In addition, the Secure Software Standard and the Secure Software Lifecycle Standard are fresh new additions made possible by the SSF. The former specializes exclusively in software for processing payments.

The Secure Software Standard and the Secure SLC Standard.

The PCI Software Security Framework is a framework that was designed to assure strong data and consumer security, and it includes two separate standards in its overall architecture. Although they are focused mainly on payment application software, they also apply to supplemental apps included with the original payment software. This is the case regardless of whether or not the additional applications store or process any sensitive data.

Secure Software Standard

This standard will protect the customer’s confidentiality and data integrity during every financial transaction. This standard is quite similar to PA-DSS in terms of its structure and content in many respects. For a software provider to pass this test, they must submit themselves to the entire examination and many interim assessments, sometimes known as “delta” examinations.

A Standard for the Secure Software Life Cycle

The Secure Software Lifecycle (Secure SLC) Standard assures that suppliers manage data security from the design and development stages to “end-of-life,” whereas the Secure Software Standard focuses on individual transactions.

To comply with the PCI Software Security Framework, software developers and suppliers may choose whether or not to take part in secure SLC evaluations. The results of an assessment are good for three years before another evaluation is necessary.

Maintaining adherence to the SSF Transition Timeline

The new PCI Software Security Framework includes a transition timeframe for developers, suppliers, and retailers. This was done to simplify the process for everyone involved and to limit the possibility of any possible service delays or loss of revenue.

The PA-DSS will be retired in October of 2022, which is the last event on the timeline:

January 2019: The PCI Software Security Framework is made available to the general public for the first time.
June 2019: The first papers associated with the SSF are available online.
October 2019: Applications for organizations to become competent SSF Assessors were made available. These applications were made available in October 2019.
February 2020: The first round of training for SSF Assessors gets underway.
July 2020: Saw the publication of the very first Secure SLC listing.
January 2021: Saw the publication of the very first piece of Secure Software.
June 2021: We will no longer be accepting any new PA-DSS entries.
October 2022: The conventional PA-DSS program will be formally terminated.

What Are Some Distinctions Between PA-DSS and the PCI SSF

Within the PCI SSF, no standards may be considered “prescriptive.”

You will be informed precisely what criteria need to be satisfied for the payment application to be approved by the PA-DSS, which has stringent standards.

Your developers could frame your program more easily around a static set of controls, and your assessor just needed to evaluate whether or not those controls were there.
If they weren’t, the payment application wasn’t fulfilling the condition in question. The investigation yielded a definitive result: either it was in place, it was not in place, or it did not apply.

The PCI SSF operates differently. It allows suppliers to define their specific security goals while still adhering to the standard. All your assessor has to do is verify whether or not the controls are effective.

Having more freedom is desirable, but it also comes with potential drawbacks.
If you are interested in implementing the new framework, the freedom it provides implies that you will need to pay more attention to the controls you have in place and get buy-in from the stakeholders involved in your program.

In contrast to the PA-DSS, which has consistently delivered a binary decision and has never permitted compensating measures, the PCI SSF has adopted an objective-based approach, which means that any solution that reduces risk will be considered compliant with the standard.

What does that imply for you moving forward? When it comes time for your assessment, you should have a thorough grasp of how you are fulfilling each control target and be prepared to back up your controls with a rigorous risk assessment based on the threat analysis they have provided.

The testing for the security goals of the PCI SSF will build upon testing for other purposes.

If the PCI SSF enables you to set your own security goals, you need to make sure you have them in place for your assessment to succeed. You may ignore this requirement if the PCI SSF doesn’t allow you to determine your security objectives.

Let’s look at another example of this:

To complete this evaluation, you must determine which assets are essential.
Because the relevant security goals will need your assessor to evaluate them based on the critical assets you identify, it becomes an issue if specific linked objectives are not developed. This is because the relevant security objectives require your assessor to test them.
Your assessors will not be able to evaluate the great bulk of your software if you do not have each security target in place, which is terrible news for your compliance.

The source code will be reviewed as part of PCI SSF.

Although the PA-DSS does not explicitly call out the need for assessors to undertake source code evaluations, the requirement is indicated within the PCI SSF.

Your assessor will conduct a source code assessment of your program, particularly relevant to Control Objective 5.2. This study aims to check the ways of accessing essential assets you have previously established.

Not only should you be ready for a source code review if you want to go through PCI SSF, but you should also be ready to assist in the review in a manual or automated fashion. You should be ready for both if you plan to go through PCI SSF.

The Random Number Generator (RNG) entropy testing is a part of the PCI Security Standards Supplement.

Your assessor will be needed to acquire data from the software manufacturer and perform tests to determine the strength of the RNGs that your program use, by the new PCI Security Standards Council (PCI SSC) guidelines.

In particular, the criteria for the test instruct the evaluator to collect a minimum of 128 megabytes’ worth of data generated from each random number generator integrated into the system.

If you already know that obtaining your RNG data will be complex or you’ve never given it any thought, you should begin to plan for this issue well in advance and discuss it with your assessor to determine the most effective strategy in preparation.

(Also, keep an eye out for additional in-depth posts on testing RNGs and the technical details of what is expected from Schellman in the future.)

The terminology used for documents has changed.

The notion of an implementation guide was first presented by the PA-DSS validation, and it is anticipated that the PCI SSF will continue to retain this format.

Having said that, there has been a shift in the semantics.

The goals formerly covered by a single implementation guide are now referred to as “guidance documents” in the PCI SSF standards. This change was made to make the criteria broader about what you may supply to achieve these objectives.

Because of this change, you will now have the choice during testing to either supply a single implementation guide or numerous papers to fulfill the goal’s requirements.

The PCI SSF mandates more stringent forensic testing and the incorporation of “transient sensitive data.”

Anyone who has been through the PA-DSS validation process has prior experience with forensic testing. (At the very least, this shouldn’t be the case.)

However, beginning immediately, testing for PCI SSF will include both permanent and transitory sensitive data. Your auditors will also analyze any potential data exposure points, such as the following:

Prepare to talk about where you store sensitive data, both permanent and temporary, and be sure to have examples ready. You should also be ready to help install forensic software inside the testing environment. This software will enable your evaluator to witness data retention and secure the erasure of sensitive data. You should be ready to assist in this installation.

How Can Artifice Security Help?

Looking to find vulnerabilities in your PCI network? Let Artifice Security be your next professional penetration testing service company to secure your network.

see all posts