Transitioning from PA-DSS to PCI SSF: 6 Differences to Prepare For

Comic book enthusiasts have long debated what to call one of Batman’s signature tools—his grappling hook.

You might call it Batline or a Batrope or maybe even a Batclaw, but that’s not the point. Whatever it’s called, the Dark Knight uses this particular gadget when he wants to swing from one place to another.

He’s an ordinary guy—Batman—with no superpowers, so it makes sense that he needs a little help switching locations. If you’re in payment software, you too may need your own “Batclaw” to help you make the transition from PA-DSS to the new PCI Software Security Framework (SSF).

You might’ve already heard, but the latter is replacing the former, and you’ll need to be ready to make this compliance switch. Chances are you want to make your next, new assessment a smooth ride, and we are going to help.

We’ve already written about major gaps you’ll want to ensure you avoid when adopting the PCI SSF, but now we’re going to take it a step further.

The PCI Secure Software Standard (PCI SSS) is the part of the SSF that is meant to take over for the current PA-DSS standard. It will require robust testing of the payment software by your assessor. As one said assessor, we want to provide some insight on our perspective so that you have a better idea of the

In this article, we’re going to highlight the key differences between what you’re used to being tested under the PA-DSS and what will be looked at when the new SSS comes into play.

While there will be many other considerations you’ll need to make before your assessment, at the very least you won’t be blindsided by these changes. Using this “Batclaw” of information, you’ll be able to bolster your preparation ahead of your assessor coming onsite, making your transition to the new standard much easier.

6 Differences Between the PA-DSS and the PCI SSF

1. There’re no ‘prescriptive’ requirements in the PCI SSS.

Within PA-DSS there are rigid requirements that tell both you and your exactly what conditions needs to be met by the payment application:

• That made it easier for your developers to frame your software around a static set of controls that your assessor would just validate whether or not they were in place.
• If they weren’t, then the requirement was not being met by the payment application. The result was categorical – it was in place, not in place, or not applicable.

The PCI SSF is different. It provides flexibility for vendors to determine individual security objectives within the standard, and your assessor will just confirm the efficacy of those controls.

• More flexibility is nice but can be a double-edged sword.
• If you’re interested in adopting the new framework, such flexibility means you’ll need to pay more attention to your controls and secure buy-in from your software stakeholders.

While the PA-DSS always provided a binary outcome that did not permit compensating controls, under this new objective-based approach of the PCI SSS, any control mitigating the risk will meet the standard.

What does that mean for you? When it comes time for your assessment, you should have a comprehensive understanding of how you are meeting each control objective and be ready to back up your controls with a robust risk assessment based upon their threat analysis.

2. Security objective testing in the PCI SSS will build off other objectives.

If the PCI SSF allows you to determine your own security objectives, you need to ensure you have them all in place for your assessment to be successful.

Seems like a no brainer, so let’s illustrate this further:

• For your assessment, you will need to identify your critical assets.
• Since the relevant security objectives will require your assessor to test them based on the critical assets that you identify, it becomes a problem if certain related objectives are not established.
• Without each security objective in place, your assessors will not be able to test a vast majority of your software—bad news for your compliance.

3. Under PCI SSS, there will be source code review.

While PA-DSS did not explicitly call out the need for assessors to perform source code reviews, it is stated within PCI SSS to do so.

Particularly relevant to Control Objective 5.2, your assessor will include a source code review of your software to confirm the methods of accessing critical assets that you will have previously identified.

If you’re expecting to undergo PCI SSS, not only should you be prepared for a source code review, but you should also be ready to aid in the review via manual or automated means.

4. PCI SSS includes Random Number Generator (RNG) entropy testing.

Under the new PCI SSS, your assessor will be required to collect data from the software vendor and apply testing to measure the strength of the RNGs that your software uses.

Specifically, the test requirements ask the assessor to obtain at least 128 MB of data output from each random number generator implemented in the system.

If you know now that accessing your RNG data is problematic or you’ve never considered it, start thinking about this well in advance and talk with your assessor to figure out the best approach ahead of time.

(Also, keep a lookout for more detailed blogs from Schellman in the future on testing RNGs and the technical aspects of what is required.)

5. There’s been a shift in language regarding documentation.

PA-DSS validation introduced the concept of an implementation guide, and the same is expected to be maintained by the PCI SSS.

However, there’s been a change in semantics.

PCI SSS requirements now use the term “guidance documentation” to be more general regarding what you can provide to fulfill the objectives that were previously covered by a single implementation guide.

This change means that—during testing—you will have the option to either provide a single implementation guide or multiple documents to satisfy the objective.

6. PCI SSS requires more robust forensic testing and inclusion of “transient sensitive data.”

Forensic testing is not new to anyone who has gone through PA-DSS validation. (Or at least, it shouldn’t be.)

But now, PCI SSS testing will include both persistent and transient sensitive data. Your assessors will also evaluate locations where data could be exposed:

• Be prepared to discuss these locations where you house both persistent and transient sensitive data.
• You should also be ready to assist in the installation of forensic software within the testing environment that will allow your assessor to observe data retention and your secure deletion of sensitive data.

Next Steps in Your Transition to the PCI SSF

If you were hoping for a ‘drag and drop’ scenario in going from PA-DSS to PCI SSS, you now clearly understand that’s just not the case.

It’s safe to say that most or all the testing that took place under PA-DSS will still be included within a PCI SSF assessment, so there will be similarities between the two. But the latter expands upon a lot that you will be expected to have prepared for ahead of your assessment.

And now you have a head start since the above differences we mentioned should give you a good place to start in shoring up your controls. To ease this transition even further, make sure to read our other articles on the PCI SSF:

• Overview of the PCI SSF
• How to Manage Open-Source Software Vulnerabilities: Understanding the PCI SSF’s Approach

As we all continue adapting to these new practices, you may find that you have questions regarding your organization’s fit against the SSF. As a Secure Software and a Secure SLC Assessor, Schellman has already been through several of these readiness assessments with our clients. We are happy to set up a conversation to offer insight—please reach out to us so that we may help ease your concerns.