PCI DSS is probably one of the most misunderstood compliance obligations among IT professionals. It is in fact the Payment Card Industry Data Security Standard (PCI DSS) governed by the PCI Security Standards Council (PCI SSC) founded in 2006 by American Express, Discover Financial Services, JCB International, MasterCard and Visa. These organizations are still on the PCI SSC’s executive committee. However, there is also a board of advisors from organizations such as Amazon, Citigroup, Microsoft, PayPal, Square, Starbucks, Wells Fargo, etc.
Who must be compliant to PCI DSS?
All entities who store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). These entities can be merchants, processors, acquirers, etc. There are in total 12 high-level requirements and each one has many controls:
- Install and maintain a firewall configuration to protect cardholder data
- Do not use vendor-supplied defaults for system passwords and other security parameters
- Protect stored cardholder data
- Encrypt transmission of cardholder data across open, public networks
- Protect all systems against malware and regularly update anti-virus software or programs
- Develop and maintain secure systems and applications
- Restrict access to cardholder data by business need to know
- Identity and authenticate access to system components
- Restrict physical access to cardholder data
- Track and monitor all access to network resources and cardholder data
- Regularly test security systems and processes
- Maintain a policy that addresses information security for all personnel
A PCI DSS requirement is simply a control in audit terminology where there are testing procedures for each one. There are more than 200 requirements/controls within PCI DSS.
If you have an application where users are able to pay with a credit card, this application must be PCI DSS compliant. Even if you don’t have so many transactions. Even if you just transmit credit card information without even processing any transactions. The required requirements would be different depending on what you are doing with the cardholder data. For example, when cardholder data is only processed and transmitted but not stored by an organization, many controls would not necessarily be applicable.
Hosting Provider and You
Many developers and sysadmins think, hope, that since the hosting provider is PCI DSS compliant, they have offloaded the responsibility to the hosting provider. Unfortunately, it is really far from the truth.
Hosting providers are PCI DSS compliant for specific requirements. The responsibility is often shared between the provider and the client for many controls. Other controls, the client is the solely responsible.
For example, a more traditional provider such as a data centre, could be PCI DSS compliant. But it will be mainly for controls within the requirement 9 related to the physical security of the hosting environment. The goal here is to provide compliance on the environment controls where clients can’t perform themselves an audit.
However, with a cloud provider, it could be a little more complicated. A provider such as AWS would often share a responsibility matrix for each requirement. For example, AWS implement security groups on each virtual server which is like a firewall. However, the client has the responsibility to configure the firewall adequately. This is a shared responsibility. The same for penetration tests. AWS will perform penetration tests on their infrastructure. But the client still has to perform penetration tests on their applications and servers.
In any cases, it is important to remember that compliance such as PCI DSS is not always related to technology but also people and processes. You will always have a responsibility of being compliant for your organization.