Secure coding training for PCI DSS compliance

The financial industry, and more particularly the payment industry, handles a large amount of sensitive personal data. As such, it is no surprise that they were among the first to define strict security standards. In payment transactions, security is critical, and any weakness does not only compromise the data, but can result in credit card fraud that causes huge losses for the stakeholders.

PCI DSS compliance in the payment industry

The Payment Card Industry Data Security Standard (PCI DSS) was created to establish the common set of rules and controls for stakeholders in payment transactions. In the last two decades, it has become a household name of security standards. The standard, as its name suggests, is centered around critical cardholder data, and builds network controls, policies, and procedures that protect this information.

The PCI DSS belongs to the set of security standards that explicitly requires the security training of developers responsible for building and operating financial software. Much has been written about the 12 requirements of PCI DSS and the controls to maintain PCI security. Let’s take a look at a few points developers need to focus on in order to build secure-by-design software and the training that supports those requirements.

Lessons in PCI DSS security

Below are a few security topics and controls every developer needs to pay special attention to.

Data, Data, Data

When it comes to PCI security, cardholder data is key. This fundamental fact cannot be emphasized enough for developers, who often think in terms of software systems and delivered features, and as a result sometimes overlook the requirements surrounding data security. They need to realize the dangers lurking in the dark for cardholder data, like the XSS attacks that haunted British Airways and Ticketmaster.

First, developers need to minimize the data collected (PCI DSS Req 3.1-3.4) or render it unreadable when displayed in user interfaces. When collected, critical cardholder data must be properly encrypted (PCI DSS Req 3.4-3.6). To do this, developers must learn about cryptography best practices.

Encryption is also critical for data in transit across open, public networks (PCI DSS Req 4). With the use of third-party cloud environments, configuration and proper encryption are the cornerstones of data security.

Data is not protected by walls (anymore)

In general, traditional controls about networks and systems are getting weaker, and more and more responsibility falls on the shoulders of developers. Firewalls, network segmentation, and traditional perimeter protection methods are less and less effective. With the ubiquitous working-from-home culture and the use of the cloud, data gets more exposed and vulnerable. Developers need to understand this. They need to assume data will pass through and reside in potentially insecure or unknown environments and protect it accordingly. Even if these zones
are established, PCI DSS Req 1.1.5 demands, for example, the proper enforcement of access control to data in the network. A similar principle needs to be applied in software which allows only authorized access to cardholder data.

Do not assume that data is safe in a protected environment

Developers often assume internal systems are trustworthy, and they will compile statistics or documents that contain full cardholder data. They do not necessarily consider an insider threat when an employee of the organization gets access to data that should be hidden. PCI DSS Req 7 and 8 advocate strong access control, authentication, and authorization to critical data that needs to be implemented by developers in all circumstances.

Secure configuration is king

As we have discussed in a previous blog, configuration errors are now the number one root cause of security breaches. Especially with the transition to cloud platforms, developers need to understand the shared responsibility security model; most importantly, that the cloud providers are responsible for the security of the infrastructure, but not for the security of data and software they host. PCI DSS Req 2.2 requires that systems are properly configured, which for developers means a proper configuration of applications and sharing data with other platforms, for example, via APIs.

Expect interrupts to fix security issues

PCI DSS Req 5 demands that companies maintain a vulnerability management program, which puts some pressure on developers. The issues discovered in pentesting and bug bounty programs naturally add to the already significant workload of developers. Even so, the company has to maintain the commitment that these issues will be fixed, otherwise the bug bounty program will be a very expensive and useless endeavour. Developers not only need to be equipped with fundamental security skills to fix the reported bugs, but their managers need to understand that this takes time. The whole engineering organizational culture should support the reporting and fixing of critical issues.

Give a man a bug fix, or teach a man to debug

Vulnerability management gives direct feedback to developer teams on their mistakes, but mature organizations go further and encourage developers to proactively avoid security vulnerabilities. PCI DSS Req 6 states several requirements about developing secure applications. These mandate the prioritization of vulnerabilities, patching of software, and the proper development of secure application by knowing and respecting secure SDLC best practices, such as performing proper code reviews.

PCI DSS Req 6.5 explicitly states that developers should be trained “at least once annually in up-to-date secure coding techniques”. The details in Req 6.5 cover most of the OWASP Top 10 issues like injections, broken authentication, broken access control, cross-site scripting (XSS), or cross-site request forgery (CSRF). Note that web security fundamentals are not easy, and most developers still need to grasp the essence of attacks behind the basic OWASP top 10 vulnerabilities. Sadly, this rabbit hole goes very deep, and even major companies are susceptible to these attacks, as the recent XSS vulnerability in Google search shows. These issues are far from trivial, and developers should build an intuition for noticing when there’s a problem.

A last note on secure coding training in PCI DSS

Above, I selected a few requirements in the PCI DSS standard that advocate strong secure-by-design software development practices. Frameworks are getting better and offering more tools to remedy security issues, but developers still need to learn to understand the security fundamentals to protect critical cardholder data. Fundamental secure coding training, such as a review of OWASP top 10, is a very good starting point for this.