5 Major Gaps to Avoid When Transitioning from PA-DSS to PCI SSF

Bear with us while we get nostalgic: do you remember the classic arcade game Frogger? The one where it was your job to guide your little amphibious pixels across a busy road full of obstacles? You had to shoot for the gaps every time to be successful, but some of those levels were tough.

In payment software security, navigating risk is a bit like Frogger considering the stakes are just as high. But whereas in the video game, you can merely spend 25¢ to restart the game after making a mistake, making one where your customers’ sensitive data is concerned can mean losing their business and worse—your professional reputation.

In payment software security, you want to actually avoid gaps, but as organizations navigate the transition of standards from PA-DSS to PCI SSF, that can be tricky.

October 2022 draws nearer, meaning that gap assessments and readiness work has been well underway for those of you looking to get listed under one or both of the standards under the new PCI Secure Software Framework (PCI SSF).

We’ve assessed all kinds of organizations against many of the PCI standards before, and now with the emergence of the PCI SSF, we’ve extended our services to include it. But no matter who you use for your evaluation, we want you to navigate this transition safely.

This isn’t a mere game of Frogger, but if you’re a software vendor trying to safely make it to listing under one of the PCI SSF standards, we want to offer you a cheat code of sorts. In this article we will outline 5 security gaps you’ll want to avoid during your own process, no matter who your assessor is.

While every organization is different with unique identifiable gaps, here are 5 of the major we’ve identified in many organizations looking to undergo PCI SSF.

1 . Lack of Critical Asset Inventory

This is our #1 for a reason—a lack of a formal and defined critical asset inventory is one of the biggest gaps that can derail your assessment. Why? Almost every other control objective within the standard relies on a proper inventory for the assessor to test. Without this inventory, the rest of the assessment cannot be completed.

A critical asset inventory is not the same as what PCI DSS calls a systems listing. But the good news is that they are very similar. And while we could write a book on how to properly document a critical asset inventory, here are two things you absolutely need to do here as a software vendor aspiring for PCI SSF compliance:

• Ensure you know exactly what it is your software relies on for its operation and security. You should list both hardware and software dependencies that are required.
• Identify the sensitive data elements, sensitive functions, and sensitive resources used for the operation of your software. We often get asked how to know what is considered critical—generally, if an attacker can compromise it and it would affect the security of the software, then you should consider it within the critical asset inventory. 

2. No Meaningful Threat Analysis or Risk Assessment

The second largest gap we’ve seen while performing gap and readiness assessments is a lack of a qualitative, quantitative, and mature threat and risk analysis process.

That’s a lot of adjectives, so let’s break down what the standard actually needs you to do to avoid a problem:

• Perform threat analysis to ensure that attack vectors are documented for your software. You would have performed a threat and risk assessment to determine your critical asset listing—make sure you document that as well.
• Ensure your process is repeatable and has been repeated/documented. That’s essentially what the standard means by “mature.” Your threat analysis and risk assessment process should be based on industry standards, and there should be substantive documentation to prove it.

You might already be familiar with the risk assessment requirements under PCI DSS, which, were arguably open-ended and left a lot up to you. But the PCI SSF standard requires much more substantial documentation and to meet those needs, you should expect to make major modifications and advancements to your threat analysis and overall risk assessment process.

3. No Sensitive Data Inventory

It’s another inventory problem. We wrote about what PCI SSF considers “sensitive data,” but here are further clarifications on what to include here so as to avoid any gaps.

While account data will always be considered as sensitive data, PCI SSF actually leaves the protection of other data open-ended for you to define in case you’re also looking to protect PII or ePHI.

But to avoid a gap, one thing you do need to address within your sensitive data inventory is whether or not the data is labeled as transient sensitive data or persistent data:

• Transient sensitive data is generally data that is not meant to be stored – data used for a period of time and then is deleted under the retention schedule you defined.
• Persistent data is data that may need to be stored for a longer period of time and is still covered under your data retention policies; however, it is likely tagged for business reasons to be retained.

A clear set with definitions for everything will help prevent problem areas here during your assessment.

4. Poor Data Retention Policies

This one might sound familiar—it seems to be a pervasive issue across the board for many PCI standards, including this new PCI SSF. When we ask our clients what their data retention policies are, we seem to get a lot of blank stares. Let’s help you keep clear of that situation.

Since PCI SSF is not a prescriptive standard, it does not expressly tell an organization that they can or cannot store certain data elements. Rather, the standard asks your assessor to test data retention based on what you defined.

With our clients, we hit assessment roadblocks because they had no idea where to point us because nothing was defined. For you to dodge a gap here, all you need to do is actually define your data retention somewhere, somehow.

5. Issues with Random Number Generators (RNGs)

If you’re familiar with the new framework, you might’ve noticed there are a number of tests that are more robust than they were in PA-DSS. Some of those tests include the random number generators that you use.

As an assessor, we’ve typically been asked to determine that these RNGs are sufficiently random. Under numerous PCI standards, that has meant checking proper key management to go with some testing of the RNGs.

But PCI SSF more explicitly asks us to get a sample of the RNGs being used—under it, we are required to test its ‘randomness’ and the strength of its entropy. That surprises a lot of people when we ask for this access, so here is your fair warning should you too be looking to undergo validation for one or more of the standards under PCI SSF.

More specifically, you should expect to be able to test and answers questions on your RNGs. Preparation here will mean that much more to avoiding a gap in your assessment.

Transitioning from PA-DSS to PCI SSF

Getting Listed Under the PCI SSF

If you’ve been operating in compliance with PA-DSS or PCI DSS, this new SSF was designed for broader applicability and, as such, covers a broader range of security topics and data assets. Trying to meet its requirements can be as tricky as an upper level of Frogger.

But now you have 5 big areas you know to address ahead of your own assessment. To sum it all up, the key to your success will lie in your defining and documenting everything, as the control objectives within this standard rely heavily on that.

With all that done, you’ll be set up for a successful assessment when that time does come. In the meantime, if you find you have more questions about getting listed under the PCI SSF and what its differences mean for your organization, please reach out to us so we can have a conversation to alleviate all of your concerns.