Where Do PCI Requirements 6.5.1 – 6.5.6 Apply?

We’ve looked at PCI Requirement 6.5.1 through 6.5.6 together and learned about protection from injection flaws, buffer overflows, insecure cryptographic storage, insecure communications, improper error handling, and “high risk” vulnerabilities. But, where does PCI Requirement 6.5.1 through 6.5.6 apply? It’s important to know that PCI Requirements 6.5.1 through 6.5.6 apply to all internal and external applications.

PCI Requirements 6.5.1 – 6.5.6 Recap

PCI Requirement 6.5 requires that you address common coding vulnerabilities in software development processes by training developers on up-to-date secure coding techniques and developing applications based on secure coding guidelines. The PCI DSS states, “As industry best practices for vulnerability management are updated, the current best practices must be used for these requirements.” The following requirements outline common coding vulnerabilities that apply to all internal and external applications:

• 5.1: Injection flaws
• 5.2: Buffer overflow
• 5.3: Insecure cryptographic storage
• 5.4: Insecure communications
• 5.5: Improper error handling
• 5.6: All “high risk” vulnerabilities

Assessors want to see PCI Requirements 6.5.1 through 6.5.6 implemented in the application development process for all internal and external applications. In order to verify that your organization is complying with PCI Requirements 6.5.1 through 6.5.6, an assessor will examine policies and procedures related to application development, training records, and interview responsible personnel.

When we’re looking at PCI Requirement 6.5.1 through 6.5.6, those particular requirements apply to all applications, whether it’s executable on the inside of your organization or whether it’s web-facing application. From a development perspective, we expect to see that all of those items called out within the PCI DSS, 6.5.1 through 6.5.6, are handled and apply to all applications. 6.5.7 through 6.5.10 are for web-based applications only.

What are “High Risk” Vulnerabilities?

PCI Requirement 6.1 taught us how to establish a process for identifying security vulnerabilities. The PCI DSS explained that risk ranking allows organizations to identify, prioritize, and address the highest risk items and reduce the likelihood that vulnerabilities will be exploited. Risk ranking is a vital element of PCI Requirement 6.5.6, which states that organizations must have a process in place to determine how to protect applications from “high risk” vulnerabilities. Risk ranking is malleable because what’s vulnerable today could not be a vulnerability tomorrow, but it’s still crucial to have a process in place to determine how to protect applications from “high risk” vulnerabilities.

PCI Requirement 6.5.6 is sort of the catch-all requirement for “high risk” vulnerabilities. It simply states that you must identify and address these vulnerabilities during application development, but doesn’t give a ton of guidance or restrictions on how you do this. To verify your compliance with PCI Requirement 6.5.6, an assessor will examine your policies and procedures related to application development and interview responsible personnel to see that you have indeed addressed “high risk” vulnerabilities in your coding techniques.

PCI Requirement 6.5.6 states that you have to have a process in place to identify all “high risk” vulnerabilities. If you remember back in PCI Requirement 6.1, it asks that you have a program where you’re subscribing to third parties to identify vulnerabilities. If part of your application or something within your application is deemed to be “high risk”, that application needs to be addressed. PCI Requirement 6.5.6 is kind of the catch-all. It basically says all “high risk” vulnerabilities need to be addressed. You need to have a process in place to address any “high risk” vulnerabilities. Understand that what’s vulnerable today may not necessarily be a vulnerability later on, but you need to have a process or program in place to fix that.

What is Improper Error Handling?

Improper error handling is one of the common coding vulnerabilities outlined in PCI Requirement 6.5. PCI Requirement 6.5.5 states that improper error handling must be addressed in your coding techniques.

PCI Requirement 6.5.5 alerts organizations that improper error handling introduces many security issues to your website because it can unintentionally leak information to an end-user or malicious individual. For example, a 500 Internal Sever Error could show database connection strings, configuration information, error codes, stack traces, data dumps, local directories, or information about the back-end application.  These details should never be revealed, but especially not to an attacker. OWASP warns, “Such details can provide hackers important clues on potential flaws in the site and such messages are also disturbing to normal users… Even when error messages don’t provide a lot of detail, inconsistencies in such messages can still reveal important clues on how a site works, and what information is present under the covers.” The last thing you want to do is provide your attacker with clues on how to exploit your system. The PCI DSS explains, “If a malicious individual can create errors that the application does not handle properly, they can gain detailed system information, create denial-of-service interruptions, cause security to fail, or crash the server.”

A common example of improper error handling is user ID and password input. If an attacker receives the message, “incorrect password provided,” that error message is telling them they’ve given a correct user ID. Now, they can focus on hacking the password. The PCI DSS recommends using generic language in your error messages so that no useful information is accidentally given to attackers. Instead of saying “Incorrect password provided,” try giving the error message, “Data could not be verified.”

When in the development phase with an application, you must ensure that your error message does not disclose any unnecessary information. If your application is going to error-out, it needs to do so in a secure way. In order to verify your compliance with PCI Requirement 6.5.5, an assessor will need to review your policies and procedures related to application development and interview the responsible personnel to ensure that your system is properly handling error messages.

How many times have you been surfing the Internet, go to a website, and all of the sudden you see this 500 Error. In this error, it shows all sorts of information – database connection strings, information about the back-end application, the local directories. Once in a while, you’ll see this. it’s not as prevalent as in years past, but it’s still something that we see today. From a development perspective, you need to make sure that if your application should error-out in some way, it errors-out in a secure state so it’s not disclosing any unnecessary information or an insecure information to the end-users. While it’s absolutely acceptable to dump all of that stuff back into an error log and then de-bug and find out what went wrong, the last thing that you want to do is provide more information to the attacker to might allow them to further their attack.

What are Insecure Communications?

PCI Requirement 6.5.4 requires that you protect your applications from insecure communications. To understand PCI Requirement 6.5.4, let’s look back at PCI Requirement 4. PCI Requirement 4 and its sub-requirements outline how to use strong cryptography and security protocols to protect cardholder data, which is what PCI Requirement 6.5.4 calls for. The PCI DSS states, “Applications that fail to adequately encrypt network traffic using strong cryptography are at increased risk of being compromised and exposing cardholder data. If an attacker is able to exploit weak cryptographic processes, they may be able to gain control of an application or even gain clear-text access to encrypted data.” Best practice says that you should not use insecure communications such as insecure protocols, ports, or services. These forms of insecure communication are vulnerable, and your application cannot depend on something that’s vulnerable.

In PCI Requirement 6.3, we learned that the best way to ensure securely developed applications is to incorporate information security into several phases of your development process: requirement gathering, design, development, and testing. PCI Requirement 6.5.4 requires you to examine these phases again and ensure that within these phases, you’re using defined, specific, secure methods of communication and that strong cryptography is incorporated.

During a PCI assessment, an assessor will examine your documented policies and procedures related to application development and, once again, interview the responsible personnel to ensure that insecure communications are addressed by coding techniques that properly authenticate and encrypt sensitive data communications.

6.5.4 requires that when you’re developing an application, that you’re not going to be using an insecure protocol, port, service, or any insecure communications. There’s no point of developing an application that has a dependency on something that’s already vulnerable. Make sure that during the requirements phase of the application and the design phase of your application, that you call out specific protocols, ports, and services that are going to be used to ensure that those are going to be secure.

What is Insecure Cryptographic Storage?

PCI Requirement 6.5 requires that your organization address common coding vulnerabilities in software development processes to ensure that applications are securely developed. One of the common coding vulnerabilities associated with secure application development is insecure cryptographic storage, which is outlined in PCI Requirement 6.5.3.

PCI Requirement 6.5.3 requires that your organization does not have insecure cryptographic storage. Everything that we learned in PCI Requirement 3 is coming back into play with PCI Requirement 6.5.3. We’ve talked about the requirements of a Key Management Program, but how does that fit into developing secure applications? The PCI DSS warns, “Applications that do not utilize strong cryptographic functions properly to store data are at increased risk of being compromised, and exposing authentication credentials and/or cardholder data. If an attacker is able to exploit weak cryptographic processes, they may be able to gain clear-text access to encrypted data.” As we learned in PCI Requirement 3, strong cryptography and a good Key Management Program is vital for the security of your cardholder data environment.

If your organization is storing PCI-related data using encryption, those keys must be stored securely, as PCI Requirement 3.6.3 commands, “Secure cryptographic key storage.” If your Key Management Program keeps your keys securely stored, has the appropriate protections, and access is limited to the fewest number of people and locations as possible, you can help prevent your organization from being susceptible to an attack.

When developing the application, we need to make sure that you have strong cryptography as part of the development lifecycle and management of the application. 6.5.3 talks about insecure cryptographic storage, and this goes into defining how you manage your keys. We talked about, in Requirement 3, all of the needs for developing a Key Management Program. This is one the things we look for as an assessor, your Key Management Program and how that plays out in your SDLC. It’s not really up to us to define your program. What we look for is that you have policies and procedures, your SDLC calls out how you’re managing the cryptography of the application, and making sure that you’re then adhering to those processes.