The PCI DSS is comprised of over 200 specific requirements, including technical, administrative and policy controls. For this reason, the first consideration when approaching PCI compliance is determining exactly which parts of the environment have to be included within the PCI compliance scope and which do not, based upon the scoping rules provided by the PCI Security Standards Council (see link below for details). Scope reduction is the key to keeping the costs and time required to achieve PCI compliance to a minimum.
In this article, we’ll explore some of the options available for reducing PCi compliance scope. In order to apply this guidance properly, you must first ensure you fully understand the rules for defining PCI compliance scope, so if you haven’t already read my other article on that topic, please do so before proceeding:
Defining the Scope for PCI Compliance
Now, with that guidance in mind, here are some strategies you can explore for reducing the scope for PCI compliance. We’ll briefly discuss each of the following:
- Document network topology and cardholder data flows
- Eliminate cardholder data
- Explore options for Data Tokenization
- Explore options for End-to-End Encryption
- Explore other outsourcing options
- Reduce scope using network segmentation
Step 1: Document network topology and cardholder data flows
Before you start making changes to your network or business processes, it’s critical to ensure you understand all of the existing ways in which credit card data is being transmitted and/or stored within the environment. Using surveys, interviews and other information gathering methods, create documentation that details all of the cardholder data flows, as well as how each flow relates to the network topology (i.e. which segments the traffic traverses).
It may also be necessary to use software to perform cardholder data discovery in order to locate previously unknown instances of stored cardholder data.
Step 2: Eliminate cardholder data
Once you’ve located all of your cardholder data, the next step is to eliminate as much of it as possible. Any data that exceeds business retention requirements can be eliminated, which will immediately reduce the degree of potential liability in the case of a breach, as well as helping to reduce the scope for PCI compliance (or at least for certain PCI requirements).
Step 3: Explore options for Data Tokenization
Data tokenization refers to the process of replacing actual credit card data with token values that can be used to represent that data, without being considered cardholder data (and therefore not in scope for PCI compliance). This technology lends itself especially well to e-commerce environments, but can also be leveraged for internal payment applications and databases. The vault that stores the actual credit card values and token data can be either housed internally or outsourced to a PCI compliant third party. In either cases there can be significant reductions in the scope for PCI compliance.
Step 4: Explore options for End-to-End Encryption
End-to-End Encryption has the potential to become the “holy grail” of PCI compliance scope reduction, at least for those organizations that are able to leverage the technology. Especially for retailers with many store locations that handle card-present transactions, this technology can have immense impacts on PCI scope reduction. End-to-End Encryption means that the cardholder data is encrypted right at the point of swipe. The encryption keys are stored within the hardware device used to swipe the cards, and the merchant does not have any access to the decryption keys. The cardholder data is sent, encrypted, to a third-party processor, who then decrypts the data for processing (and possibly tokenization also).
The key here is that the PCI Council has ruled that if cardholder data is properly encrypted and the merchant has no means of decrypting the data (in other words, the merchant does not have access to the decryption keys), then that data is no longer considered cardholder data and would be out of scope for PCI compliance. This can potentially result in getting almost everything at the store locations out of scope (except for the card swipe devices themselves) and would make most of the individual PCI requirements non-applicable at the store level.
Step 5: Explore other outsourcing options
Aside from data tokenization and end-to-end encryption, there are additional ways in which portions of the PCI compliance responsibilities can be shifted to third party organizations. Examples would include:
- Outsourced call center services if credit card data is handled by telephone
- Outsourced e-commerce shopping cart services
- Outsourced log management
- Outsourced intrusion detection and/or vulnerability management
These are common areas where organizations can look to outsourcing for PCI scope reduction. Each of these (especially the last two items on the list) can be very challenging for organizations for whom information security management is not a core competency and/or with limited internal IT resources available. Just make sure any third party you talk to about such outsourcing is fully aware of their obligations as a PCI Service Provider and is prepared to demonstrate their compliance.
Step 6: Reduce scope using network segmentation
The final step in PCI scope reduction is to adjust the network segmentation to minimize the number of systems that are in scope for PCI compliance. This should only be done after exploring the above options, as the outcome of those scenarios will likely have an impact on which systems and segments need to remain in scope for PCI.
Since the rules for PCI scoping require that all connected systems (system on the same network segment as systems handling cardholder data) are in scope, even if they have nothing to do with cardholder data transmission, storage or processing.
Segmentation should be performed according to security level. For example, typical network segmentation for supporting PCI compliance might look something like this:
Additional segmentation can be achieved in a variety of ways, including deploying additional firewalls, adding network interfaces to the existing firewall, or using other types of network devices capable of enforcing traffic restrictions and performing stateful inspection.
Jeremy Simon, PCI QSA, CISSP, CISA
Practice Lead, PCI Compliance Services