The Payment Card Industry Security Standards Council (PCI SSC) defines compliance standards for all organizations that accept credit card payments. These standards cover a wide range of technologies and situations that impact the security of credit card transactions. The Data Security Standard (DSS) is the overarching standard that outlines the compliance requirements for most merchants. This standard is designed to address all issues that may present risk to the cardholder data network (CHD).
Requirement 6 of the PCI DSS outlines the expectations for developing and maintaining secure software. This includes a variety of items ranging from secure development standards to developer training to configuration and change control management. Any organizations that develop software used in a CHD are required to comply with these mandates. However, even organizations that aren’t required to comply could still benefit from following these guidelines. Improving application security through secure development is one of the most effective and efficient ways to lower risk to an organization.
In version 4.0 of the DSS, the expectations for developer training are outlined in requirement 6.2.2. (A lot of information on the internet references 6.5 which was accurate for past versions of the DSS.) This requirement is listed below.
6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows:
The standard further outlines that training should include at least the following items:
Additionally, the requirement’s Purpose section explains that developers should be familiar with all of the attack techniques that are outlined in Requirement 6.2.4. This section includes a fairly complete list of attack categories but is clearly designed to serve as examples rather than a complete list. The techniques listed include:
When reviewing training options, one consideration is whether to provide the training in-house versus utilizing a 3rd party solution. The DSS states that either option is acceptable, but diligence should be taken to confirm that the training meets all of the guidelines. Other factors to consider are cost, the time required, and the training format. Additionally, organizations are required to keep records of who was trained when so that an assessor can verify this. Assessors are directed to interview personnel to verify that relevant training has been received.
There are several different styles of training available today. The simplest, and usually cheapest, can be static-content materials, often in the form of videos. These are often purchased with an annual license based on the number of developers who will be receiving the training. They may or may not include some kind of test or assessment at the end to verify the learning objectives. Unfortunately these materials can be boring for the recipients and it’s difficult to verify that they didn’t skip through or ignore the materials.
A more effective option for training is live courses with an instructor who is able to tune the delivery for the particular audience and lead conversations into deeper topics that are relevant to the organization. These can be more engaging for the attendees, but at a higher cost. They also usually require more time for the developer to devote to the training. Courses like this can be delivered in person or online depending on the trainer and the organization. And application security courses are often taught at popular information security conferences, which is a great option for organizations who don’t have enough developers to justify a private course.
Secure Ideas has several different offerings for developer training that can be customized for each organization’s needs. This ranges from short 2-hour survey courses of the primary topics to in-depth 3-day courses with hands-on labs and exercises. We have found that approaching developer training from a red-team (attacker) perspective provides attendees with a richer understanding of both coding flaws and the mentality of attackers who seek to exploit them. When developers are given the freedom to be creative and imagine their own attack scenarios, it drives home the significance of the issues and builds longer-lasting awareness. It’s one thing to be taught what a Cross-Site Request Forgery flaw is, but eyes get big when they realize the potential impact and what they could do with it.
Secure code training for developers leads to a more secure software development lifecycle (SDLC) and a stronger security-minded culture within the organization. It is one of the most effective ways to lower the cost of application vulnerabilities. Contact us today to chat about how we can help.