Addressing Common Coding Vulnerabilities
PCI Requirement 6.5 is focused specifically on making sure that code is developed securely. 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 application layer is high-risk and may be targeted by both internal and external threats.
We discuss training over and over again because it’s so crucial to your cardholder data environment’s security. Your development staff needs to be trained at least annually on up-to-date secure coding techniques, which should include how to avoid common coding vulnerabilities and how to solve issues related to common coding vulnerabilities. This could be an in-house or self-guided training, or something more formal. An assessor needs to see evidence of annual training on how to develop secure code. The intent behind this requirement is to build a knowledgeable staff to minimize the possibility of security vulnerabilities from poor coding practices.
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 vulnerabilities associated with PCI DSS v3.2 and you are required to address these common coding vulnerabilities in the software development process:
- 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
- 5.7: Cross-site scripting (XSS)
- 5.8: Improper access control
- 5.9: Cross-site request forgery
In order to verify that your organization is complying with PCI Requirement 6.5, an assessor will examine software development policies and procedures, training records, and processes that protect the vulnerabilities listed above.
PCI Requirement 6.5 is specifically focused on making sure that when code is developed, it’s going to be done securely. There’s a couple of things that we need to look at. One, is that your development staff has been trained at least annually. Now, the secure code development – we’re going to look for some artifact of that. This doesn’t mean that you need to send somebody off to class for a week to go to training. This training can be something that you deliver in-house, which is fine. It can be self-guided, there’s no issue with that. Effectively, what we’re looking for is that your staff has been trained at least annually on how to develop secure code.
One of the other important parts about this particular requirement is: we’ve seen a lot of vulnerabilities, as of late, with malware. This particular malware has been scraping memory for cardholder data. You can Google it, you can look at YouTube videos. Just with a few lines of code, individuals are able to scrape memory and get cardholder data out of the application or out of the memory. As part of this, we have a requirement that you as an organization train your staff so at least they have knowledge of how the application is handling this cardholder data while in memory. The test for this is simple. Your assessor is going to be asking your developers, “Talk to me about how this application interacts with cardholder data while it’s in memory.”