Glossary: PCI DSS Compliance

Payment Card Industry Data Security Standards (PCI DSS) compliance can be a little daunting for development teams at first glance. These standards were last updated in May 2016, and they’re currently running on version 3.2. PCI DSS standards were developed to deliver stronger controls for credit card data to reduce fraud and increase customer protection.

PCI DSS Compliance Objectives

There are 6 main objectives for developers to consider when examining how they will approach PCI DSS compliance:

1. To build and maintain a secure data network - this is a fairly simple requirement that mandates that an up-to-date firewall is in place to reduce the risks of data intrusion or loss. There is also an expectation that default passwords (or any other security setting) provided by suppliers will be changed throughout the network.
2. To ensure that cardholder data is protected. This means ensuring that data stored within your network is as secure as possible against attack and that data during transmission is encrypted particularly when moving through public networks.
3. To ensure that there is a program in place to manage vulnerabilities. In essence that means that anti-virus measures should be in place and regularly updated. Applications must also be developed with security in mind. There’s a requirement to ensure that security is at the heart of your development strategy to ensure PCI DSS compliance. The PCI DSS standard requires a code analysis to take place at least once a year, or every time there are changes made to the application's code. (see screen show below)
4. Access controls need to be implemented and be as strong as possible. Card holder data should only be shared within the business when there’s a clear business need for that data. Anyone with access to cardholder data systems should have an individual access code assigned to them so that breaches may be tracked. The physical access to such systems should also be as restricted as possible without impacting on functionality.
5. Testing and monitoring need to take place on a regular basis. The software development team should have a test strategy that delivers scheduled unit-tests, integration tests and system tests to adhere to the terms of PCI DSS compliance.
6. Information Security policies should be well-documented and regularly updated. This is good practice for all policy documentation within a development environment as it focuses your team on best practice application of new theory.

PCI DSS compliance is necessary for every entity that will store, transmit or process data relating to cardholders. However, it’s worth noting that there isn’t always a requirement for a formal validation process for PCI DSS compliance for the entire range of system entities. In particular small scale businesses don’t have to go through a formal validation process, though it is mandatory for them to take all the measures listed above so that they can demonstrate their intentions to maintain a safe cardholder data environment, and prevent liability in the event of loss or theft of that data.

Validation of PCI DSS compliance does not mean that the work is complete. Instead it determines that adequate controls are in place at a specific instance in time. It is essential that regular examination of practice and policy takes place, and systems are updated as necessary.

Checkmarx’s source code analysis makes PCI DSS compliance simpler. You can satisfy the requirement to regularly inspect your code using this tool to automate code inspection. There is a pre-defined routing for PCI DSS compliance so there’s no need to spend hours developing your own solution. Then all you need is for developers to make PCI DSS compliance testing a standard part of their test routine, and you can be demonstrating compliance that much more easily.