PCI DSS for the Common Developer

If you work in the financial services industry, you may run into a situation where you need to deal with credit card information. In fact, any time you allow customers to purchase items or services from your site, you will need to know how to deal with payment methods, including credit cards.

The PCI DSS (Data Security Standard) is the standard developed by the Payment Card Industry (PCI) that describes how credit and debit card numbers must be protected. It spans what companies must do from a network as well as application security standpoint to protect customers’ data.

Let’s discuss the aspects of the PCI DSS that developers should know so that they are aware of how to create compliant applications.

The Basics

The PCI DSS is set up as a list of requirements. This can serve as a checklist for a company to make sure that they comply with each standard. A company can then choose to be assessed and certified as PCI DSS compliant.

There are 12 requirements in all. Most follow what are considered to be security best practices. Many wouldn’t be a surprise to any security minded developer.

That doesn’t mean that every developer knows all of the PCI DSS requirements for software systems. So let’s get started reviewing the key pieces that every developer should understand.

Network Topology

Network topology is not directly related to writing code, but it will likely have an effect on the architecture and design of your system. PCI DSS Requirement 1 requires that you have a firewall protecting any infrastructure where card data could reside or be used.

Firewalls are normally installed at the edges of the network to create DMZs and protect the internal network of the company, and this is good practice.

Another common use of a firewall is to separate even internal networks from any parts of the network where cardholder data could be held. This segmentation is key to protecting cardholder data from intrusion.

Why should developers care? First, if you are designing a system, you need to know where data will be going. If your application is dealing with cardholder data and that means there is a firewall between where your code executes and the database, it will change what you need to do to get your application to function. It may require opening up ports in that firewall to ensure everything moves smoothly.

Second, your company may put that segmented piece of that network under the control of a centralized team. The choice of that team will effect your technology choices, such as what database to use. Perhaps access to cardholder data is controlled by a service that your application will have to consume.

Proper Storage and Transmission

How cardholder data is stored is a huge piece of the PCI DSS standard. Requirements 3 and 4 state that cardholder data must be protected in transit and at rest.

To begin, let’s take a look a what cardholder data you will need to handle. The PCI has specific terms for various pieces of data represented on a credit or debit card.


The chip and magnetic stripe data are referred to as “Full Track Data”. The PAN is the Primary Account Number.

Companies are forbidden to store in any way certain data from the card. The full track data, CAV2/CID/CVC2/CVV2, as well as any PIN entered must never be stored under any circumstances, even in encrypted form.

When a user enters this data, you use it to verify the card and charge it using a payment gateway, then it is to be destroyed.

The PAN can be stored but must be encrypted. The cardholder name and expiration date can be stored and does not require encryption.

The PCI DSS Glossary defines strong encryption as using industry standard and tested encryption algorithms with at least 112-bit keys. This includes such algorithms as AES-128 (or higher), RSA, and ECC.

Cardholder data must be protected in transit. TLS should be used everywhere cardholder data is transmitted. Cardholder data should never travel in the clear, especially over the internet or over wireless networks.

Make sure you never send cardholder data over unencrypted channels such as email or SMS.

In my post on protecting your passwords, I describe the use of SecureString in the .NET framework. If you are using .NET, SecureString is a class that will protect cardholder data even while it resides in memory.

Using SecureString, you can securely clear out the string when it is no longer needed. The CLR will ensure that only one copy of the string exists in memory. Also, that copy will be encrypted while in memory. Even attacks that could take chunks of memory from your application while running will not reveal sensitive cardholder data.

Vulnerability Management

Vulnerability management is a key piece of any sound application security strategy. Vulnerabilities will appear in software and it is important to manage, not ignore them.

PCI DSS Requirements 5 and 6 require that organizations install antivirus software on all systems as well as have a robust secure development lifecycle for building software.

Any third-party software used as well as server operating systems must be patched regularly to reduce the amount of vulnerabilities that could be used to steal cardholder data. Antivirus software in use must be updated and patched regularly.

A comprehensive vulnerability management program has three pieces:

  1. Regular scans and assessments to discover vulnerabilities in software.
  2. A rating system for vulnerabilities such as “High”, “Medium”, and “Low” to help determine priority of fixes.
  3. Easy to use security controls and developer education so that developers build security into the software from the start.

Software security guidelines such as OWASP Top 10 and the SANS Top 25 come in really handy for vulnerability discovery. Use those lists as part of your secure code reviews to help discover potential problems.

Access Control

Requirements 7, 8, and 9 require strong access controls to protect cardholder data. These access controls should be part of the software as well as the hardware of any systems that hold cardholder data.

Cardholder data should only be stored if it is absolutely necessary for the functioning of the business. So you can imagine that access to that data should be strictly controlled. Only users that have a business need-to-know should have access to cardholder data.

Non-repudiation is very important when it comes to cardholder data. Each user of the system must have a unique username. Any actions taken should be recorded for audit purposes. It is important to know what was done to the data, by whom, and when it was done.

Physical access controls are just as important according to the PCI DSS. Any systems that hold cardholder data must be protected by strong physical security measures, such as id badges and restrictions on allowed media in the area.

Help with PCI DSS

The PCI DSS can certainly seem overwhelming. Many developers may not like the idea of keeping track of all of these requirements and making sure their organizations are compliant.

If this is true in your case, then it may be wise to outsource the intricate details of how to store cardholder data securely. Many payment gateways exist that can help to handle the details of PCI DSS compliance while providing a robust API for developers.

Paypal and Braintree are two examples that come to mind. Braintree has a robust API with pretty advanced features (such as card verification and a secure “vault” to store cardholder information) available in several popular programming languages. Regardless of your choice, it certainly is worth looking into using services such as these to help ease the burden on your development team.

It’s not that Scary

Ultimately, the PCI DSS is not as intimidating as I once thought. It is detailed and strict, but most of its guidelines are based on information security best practices.

If you are a developer of an application that deals with or stores cardholder data, use the PCI DSS to keep your customers safe. Keeping cardholder data secure is not just a business problem, it’s a software problem. Tackle it by becoming familiar with the PCI DSS.

1 thought on “PCI DSS for the Common Developer”

  1. Pingback: Breaking Down the OWASP Top 10 2017 RC Part 2: Numbers 6 Through 10 – Green Machine Security

Leave a Reply

%d bloggers like this: