Ticking the box annually is not enough. Your reputation is at risk – for PCI DSS, you need more than awareness raising.

PCI DSS is a mandatory security standard for all companies developing or working with systems that handle credit cards. From the development standpoint it recognizes the importance of software security and fosters the application of relevant best practices in code.

The standard does not only require following the secure coding guidelines out there, but also requires developers to train themselves on the latest best practices. Learning software security requires a change in how we approach programming: we need to shift our perspective and write code with an understanding of the hacker mindset.

At the same time, software security is a moving target. The attackers are continuously improving their skills and are coming up with novel attack techniques. This is a cat and mouse game, in which developers have to continuously improve. This is why PCI DSS requires annual training for developers on security techniques.

How not to code

From the point of view of the audits, the goal of a PCI DSS software security training should be to fulfill the formal requirement of annual education. But there is a big difference between just putting a tick in the box, and really improving the secure coding literacy of your developers. The decision is yours!

To keep up the pace with the dark side, a good training should go through four stages for each security issue it covers:

• Feature the weaknesses – so that developers are aware of the issues. But just stopping here – which is typical for awareness raising training – would be a mistake: people will understand the basic concepts, but will keep producing bad code under pressure, once back at their desks.
• Show hacking techniques – not to turn developers to the dark side, but to make them clearly understand the risk of leaving any vulnerabilities in the code. The course should instill a healthy level of paranoia with respect to software security.
• Discuss the best practices – so that developers know what to do to avoid the security incidents that can cost the company a huge amount of money, or even worse, a loss of reputation that can permanently tarnish the image of your company.
• Tell case studies – stories from real life that make it clear that a security incident can happen to anyone. Unfortunately, companies like Equifax or Capital One are providing an endless source of such stories. And it is always better to learn from other people’s mistakes, isn’t it?

The curriculum should go in breadth and in depth. It should be highly hands-on to provide first-hand experience with bugs and fixes. Developers need drills and skills that they can apply directly after the training in their day-to-day work.

The PCI DSS requirements and software security

The discipline of secure coding naturally focuses on code, common software security weaknesses, and how to cope with those mistakes and bugs when coding in Java, C/C++, C#, Python or any other programming language. It is all about classes and objects, parameters and variables, buffers and HTTP headers. So how does PCI DSS connect to this subtle domain?

In all standards dealing with software security, there should be certain coding guidelines that developers should follow when writing code. PCI DSS is no exception. The most important and relevant requirement related to secure coding is Requirement 6. Within it, we can specifically highlight 6.5 as the most relevant; it says:

6.5 Address common coding vulnerabilities in software-development processes as follows:

Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities.

Develop applications based on secure coding guidelines.

Breaking this down, in requirements 6.5.1-6.5.10 the standard enlists some vulnerabilities, such as injection flaws, Cross-site scripting or Cross-site request forgery. One may argue that such details should not be in the scope of the standard – and might be right! A standard like PCI DSS cannot continuously follow the latest developments in secure coding and release newer versions just because of any changes in that domain.

We have to admit, however, that it makes sense to pick and emphasize the riskiest things – just to provide a starting point for developers. But then again, it is still disputable why the requirement enlists some critical problems, while omitting others. Just compare the list with the latest OWASP Top Ten!

On the other hand, PCI DSS – correctly – refers to external sources of information where developers can learn more about specific software security weaknesses and the current trends in the domain. Let us take a look at these sources.

• CWE Top 25 Most Dangerous Software Errors: CWE is a huge and comprehensive database of common security weaknesses in code and hardware. The CWE team has come up with the 25 most dangerous software errors in 2019 (previous version dated back to 2011) by establishing metrics based on all real-world software vulnerabilities reported in the previous two years, and using the Common Vulnerability Scoring System (CVSS) severity score.
• CERT Secure Coding Standards: Requirement 6.5 is not only about avoiding the common coding vulnerabilities by training developers, but also about developing applications based on secure coding guidelines. One of the most commonly applied set of such guidelines are the SEI CERT Coding Standards. Worth noting, (as of May 2020) these secure coding standards are only available for Java, C and C++, Android, and Perl.
• OWASP Top Ten: While OWASP is referenced in the standard multiple times, the Top Ten specifically is not – just the “OWASP Guide”. Most probably the standard refers to the OWASP Testing Guide by this term. Nevertheless, the OWASP Top Ten became a baseline reference point in the Web application security domain over the last years. Thus, unsurprisingly, the vulnerabilities enlisted in requirements 6.5.1-6.5.10 are aligned with this list – however, they are referencing threats from an older version of the Top Ten rather than the latest (2017).

Awareness vs skills and experience

When it comes to educating developers on software security, awareness is definitely not enough. Software engineers can gain secure coding literacy only through bit-level understanding of the weaknesses, detailed discussions about the best practices, and hands-on labs to try out the learnt skills.

But this is just the must-have baseline. Developers working in finance also need to know the specialties of the sector, including specific threats and risks, attacker motivations, regulations, standards, and guidelines – just enough information to understand the environment where they are developing code.

Finally, the case studies that “burn-in” the knowledge should also come from the financial sector, to intensify the “it can happen to you too” effect.

All these elements, together, will let make you the most of a PCI DSS software security training.

Please have a look at our course specifically tailored for PCI DSS requirements. Please note that it can come in several “flavors”, including Java, C, C++, C# and Python. Drop us a mail if you are responsible for the professional aspect of your company’s certification, and we will come up with a long-term education plan tailored that fits the needs of your development groups best.