Consider this—you’re responsible for your teeth. While you do all the requisite things to take care of them yourself—like brushing and flossing—you also go to a dentist regularly.

Why? Because a dentist will give you an independent, professional, and thorough review of your efforts. You pay them to catch the issues you can’t or don’t before they severely impact your health or routines in life. But what if your dentist didn’t catch those things they weren’t experienced enough or trained correctly?

We’re not saying you can expect a literal root canal from compliance work. But the consequences can be similarly painful in payment security should your Secure Software Assessor (SSA) miss something.

Developers incorporate the principles of secure coding into their product, and you also routinely test for code flaws and vulnerabilities—that’s your brushing and flossing. For added insurance, you bring in an SSA to assess your software under the PCI Secure Software Framework (SSF). With a Report on Validation (ROV), you assure your customers that you’re sticking to a proven security standard.

You trust your assessor the same way you trust your dentist to help you protect your teeth. Unfortunately, sometimes they might miss things. From what we have come to know through our experience in these assessments, the range of experience among your chosen SSA matters. Inexperience can lead to missed gaps that don’t identify the vulnerabilities present, which can leave you unknowingly liable.

Now that we’ve spiked your anxiety, let us relieve it a little bit. Our PCI team has decades of knowledge in the payments industry combined, and we always want to provide the best insight for payment software vendors.

That’s why in this article, we’ll outline six problems that inexperienced assessors often miss. In pointing these out, we’re trying to help you get ahead of these gaps so you can take steps to fix them yourself.

We also want you to secure a competent potential assessor, so we’ll supply questions to ask all your potential third parties before you contract with them. That way, you’ll be better off—both in terms of your security and when choosing an assessor that will provide an accurate ROV.

Commonly Missed Vulnerabilities or Controls Within SSF Assessments

We preface these problems by saying that yes, they should be covered as a part of the penetration testing performed during software validation.

1. Improper Hashing/Encryption

Protecting authentication credentials and sensitive data is critical to preventing inadvertent exposure or unauthorized access, so you probably use encryption or hashing.

But these implementations must use supported libraries and include additional details that make their outputs secure. The most common errors are:

• Insufficient lengths for salts or initialization vectors when applied to hashing and block encryption, respectfully.
  • Salts should be as long as the resultant hash.
  • Initialization vectors should be as long as the encryption block.
• Hardcoded salts or initialization vectors
  • No, just no. Do not do this.
• Static salts or initialization vectors
  • Not as bad as the previous error, but close. Predictable inputs = predictable outputs = markedly higher chance for protections to be undone.
  • Use the built-in entropy functions that come with cryptographic libraries and hashing algorithms.
• Weak hashing or encryption algorithms
  • SSLv2, RC4, and MD5 are still in use.
  • Review vendor recommendations and update your code.
• Split knowledge and dual control not met in key generation or transmission
  • Deploy manual key-management operations which remove the possibility of a single individual from having access to the entire key. 

2.   Insecure File-Sharing for Client-Server Setups

Are you in the restaurant or hospitality industry? These sectors often use a client-server setup with customer-facing systems that communicate to an administrative back-end system.

Merchants love using Windows, which makes file shares a common means to exchange data. However, file shares without sufficient protections are an easy attack point for anyone who is on the network or compromises a system.

3.  Lack of Hardening/Unsecure Configurations Supported

For those of you in IT, this may seem basic. But we’ve actually seen systems in the wild with default or unsecure configurations in production environments that are somehow considered in a “finished state.”

If you don’t make any changes to the defaults on your deployed operating systems, you’re still likely vulnerable even if your assessor previously validated the system.

To change that, take advantage of the guides major operating system vendors provide for their recommended changes. You must harden those systems and change unsecure configurations. That way, you’ll remove this low-hanging fruit sought by malicious actors.

4. Unpatched Dependencies for Software Bundled with It

Your payment software may rely upon third-party software to function, whether it be an:

• Operating system,
• Data store (database or flat file); or
• Third-party libraries (OpenVPN, OpenSSL, FileZilla), among other things.

If you use third-party software, you need to ensure it receives patches and updates just like you do with your payment software. You’re responsible for the security of your software—that includes any component that provides security functions or can impact the security of sensitive data.

5. Software Does Not Verify the Integrity of Updates Before Installation

Though most language frameworks now include options to sign code, the hurdle to meet this control remains low. If you don’t have a digital signature control, hackers can introduce malicious code into software that merchants and service providers trust.

If that software has access to sensitive data, then the malware likely does too.

Digital signatures are just one means for end-users to verify the integrity of software updates. If you have not introduced them yet, we encourage you to do so.

6. Insufficient Logging

As a part of testing, your assessor needs to examine what is logged and the details included with those logs. This should include:

• Authentication controls
• Actions taken with privileged accounts
• Changes to security functionality
• Usage of critical assets

The Secure Software Standard is specific regarding the types of events that must create a log and software vendors must provide guidance to end-users (merchants) on how to centralize these logs. Your assessor should observe each of these activities in alignment with the testing performed.

Not every merchant knows how to centralize logs, we know. But that doesn’t give your assessor a pass on verifying that specific events generate logs.

What to Ask Your SSF Assessor Before Hiring Them

How can we know that these things are missed? Because we’ve seen them ourselves during forensic investigations, application testing, and product reviews. We’ve been shocked to find out-of-compliance issues such as:

• Middleware that facilitates or provides insecure functions, such as exporting cleartext card data
• Critical error conditions that provided zero notification to end-users (read as: not logged)
• Weak password hashes that were accessible to all user levels and cracked using a laptop in minutes
• Hardcoded passwords
• Default settings still in place for required software
• End-of-life, end-of-service, and unpatched software
• What appeared to be weak ciphertext, which upon review of the third-party code, the encryption operations held a note which read, “optional entropy not used.”

Leaving aside all the industry jargon, just know that these are all huge blunders—not just for an assessor to miss, but for that product’s security.

You rely on your chosen assessor to help protect you and aid your assurances to your customers. That’s why it’s so important that you find an experienced one who will hold your product’s metaphorical feet to the fire.

To avoid the kind of lapses we listed above, before going back to your previous assessor or, if you choose to find a new one, make sure to ask them the hard questions:

• Who is performing the testing and what is their experience?
• How does your team test random-number generators for entropy?
• What steps will they take to confirm that logs cover all of the necessary areas?
• How does the assessor alter executables with malicious code to see if it will run?

These details will give you a better idea of their knowledge regarding the standard as well as some insight into their methodology.

Next Steps For PCI SSF Compliance

While your assessor is decidedly not your dentist, you should be able to similarly trust their professional opinion. When it comes to their validation of your security against the PCI SSF, you need to feel comfortable with your assessor’s knowledge the way you trust your dentist regarding your teeth.

Now, you know some more difficult questions to ask when vetting your own. You also have some insight into the more common things these more inexpert professionals may miss so you can get started in clearing them up yourself.

For more insight into the entire PCI SSF, read our content that breaks down important aspects:

• PA-DSS to PCI SSF: 6 Key Testing Differences to Prepare For
• 5 Major Gaps to Avoid When Transitioning from PA-DSS to PCI SSF (and How to Avoid Them)
• SDLC Compliance: What Are the Benefits to PCI SSLC?

Prefer a conversation specific to your organization or software? We welcome you to reach out to us. We would be happy to discuss our methodology and approach to these assessments so that you can make the best decision for your organization.