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:
-
- On software security relevant to their job function and development languages.
- Including secure software design and secure coding techniques.
- Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.
The standard further outlines that training should include at least the following items:
- Development languages in use
- Secure software design
- Secure coding techniques
- Use of techniques/methods for finding vulnerabilities in code
- Processes to prevent reintroducing previously resolved vulnerabilities
- How to use any automated security testing tools for detecting vulnerabilities in software
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:
- Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.
- Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.
- Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.
- Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, clientside functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).
- Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms.
- Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.
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.
