Secure Code Development in AWS
Training Personnel to Avoid Common Coding Vulnerabilities
To comply with PCI Requirement 6.5, you must address common coding vulnerabilities in your software development processes. The PCI DSS places a heavy emphasis on training your development team in secure coding techniques and guidelines in order to avoid the following common coding vulnerabilities:
- Injection flaws
- Buffer overflow
- Insecure cryptographic storage
- Insecure communications
- Improper error handling
- Cross-site scripting
- Improper access control
- Cross-site request forgery
- Broken authentication and session management
- All vulnerabilities ranked as “high risk”
In an AWS environment, the Shared Responsibility Model stipulates that customers are responsible for applications developed in AWS and for training their own personnel. AWS explains, “The AWS Marketplace offers solutions, such as SonarQube or Nucleaus Jenkins COG, to customers to satisfy Requirements 6.5.1 through 6.5.10 for the identification of common coding vulnerabilities. Customers can also leverage automated tools to address common coding vulnerabilities, and incorporate them into their CI/CD pipeline. It is the customer’s responsibility to ensure proper testing and validation occurs, whether manual or automated, at each stage of the software development lifecycle to satisfy the Requirements under 6.5.”
For more information on common coding vulnerabilities, check out the OWASP Top 10 Web Application Security Risks.
A lot of people confuse PCI Requirement 6.5 with 6.6, but they are two distinct requirements. A lot of focus is placed on 6.6, which is dealing with evaluating applications for security flaws and correcting those things using some method for that. We’ll talk about that later. But, in 6.5, I want to focus on what that requirement is, which is very distinct from 6.6.
It focuses on the security in development processes that you have in your organization and the training of your developers so that they will be capable and fluent in security practices as they are developing your applications. PCI Requirement 6.5 requires that you send your developers to training and I’ve found that this is an area that is neglected quite frequently. Most developers that I interview are not being given any formal training in secure development practices. They are having to research that on their own and utilize a lot of free resources and subscriptions in order to get access to that information. Ensuring that there are trainings conducted and training records that are available for an auditor to review is actually one of the testing procedures in the PCI Data Security Standard. You want to demonstrate that you’ve made a commitment to training so that your people will be aware of what these security issues are as they develop software. They need to be familiar with OWASP. We often ask the question, “What security methodology are you using to develop your software?” People will point to their policy and say, “We follow OWASP.” But then, when we talk to the developers, they are not as familiar or aware that those are the methods that are endorsed by the organization. So putting some time, energy, and commitment into this – it doesn’t have to be an expensive proposition. There are lots of free resources available. There are lots of online resources available. But, giving the developers time to be aware of and participate in security training when it comes to development is really what PCI Requirement 6.5 is all about.