Determining PCI Scope – A Practical Guide

Having performed numerous Reports on Compliance (ROC) for corporations and assisted a myriad of clients with their Self Assessment Questionnaire (SAQ), one thing is apparent to us: companies large and small are having difficulty determining PCI scope for their environment. This can have a profound impact on your compliance. Having the wrong scope can invalidate your penetration tests, cause you to increase the cost and complexity of meeting requirements, and even cause you to fail your audit. Let’s take a practical look at determining PCI scope and try to resolve any questions you may have about scope in your environment.

Some Useful Definitions

The following are a few definitions we will need in order to properly explain the steps involved in determining PCI scope:

• Cardholder Data Environment (CDE) – The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.
• Network Segmentation – Network segmentation in computer networking is the act or practice of splitting a computer network into sub-networks, each being a network segment. Advantages of such splitting are primarily for boosting performance and improving security. For the purpose of this blog, segmentation refers to network segmentation from a security standpoint, where all connections between the different subnets are explicitly approved and all other connections denied.
• Point of Sale (PoS) – Hardware and/or software used to process payment card transactions at merchant locations.
• Report on Compliance (ROC) – Report documenting detailed results from an entity’s PCI DSS assessment.
• Self Assessment Questionnaire (SAQ) – Reporting tool used to document self-assessment results from an entity’s PCI DSS assessment.
• Virtual Local Area Network (VLAN) – A VLAN is a group of devices on one or more LANs that are configured to communicate as if they were attached to the same wire, when in fact they are located on a number of different LAN segments.

For further clarification or additional definitions, check out the official PCI glossary of terms.

Determining PCI Scope

With definitions out of the way, lets work through a step by step process to determine the scope for your upcoming SAQ or ROC.

Step 1: Identify How and Where the Organization Receives Cardholder Data

The first step to determining PCI scope is to identify how you are accepting cardholder data. The most obvious place for many merchants is your PoS systems at the registers and your e-commerce website. What about calling in with credit card information? Can customers mail in their payment information?

Common Mistake #1 – Forgetting Payment Channels. In this first step, the customers we typically perform audits for forget about customers that call in to provide payment information, and fail to include that VoIP network in their scope.

Common Mistake #2 – Over-scoping. Remember that we are talking about normal business processes. There may have been one time during a power outage where one employee wrote a card number on a sticky note. In that case, make sure you have a policy that prohibits that from happening and you have steps in place to securely destroy that information. But if it is not a normal business process, don’t include it in your PCI scope or it will quickly get out of hand.

Step 1 Example

To make this guide more useful, lets walk through an overly simplified example. In the diagram to the left, I have outlined my sample organization’s network. We have one store that sells widgets in person using a single point of sale terminal. We also have a website that is in a DMZ that customers can use to purchase widgets online. Finally, we have one server that processes all transactions and a database that stores records of all transactions in case customers want a refund. I have been tasked with determining PCI scope for our SAQ.

First, lets discuss segmentation. In the diagram on the left, I am indicating that each of these subnets are segmented appropriately. Each of these subnets are identified by a different color in the diagram. In order to be properly segmented from a PCI perspective, that means that I can place a computer in the blue corporate network a run a port scan across the network and see ZERO ports open on hosts in the other subnets. Here is where it gets confusing, so bear with me. This also means I can place a computer in the green store VLAN and see ZERO hosts in the PCI Server VLAN. Now that does not mean that there are no connections between the green store network and the yellow PCI Server network, but what it does mean is that each and every connection between VLANS must be strictly defined and documented. Therefore, if I set down a laptop that is not part of a defined and managed list of allowed connections, I shouldn’t see anything.

So now that we know about segmentation, lets complete step one. In my store I have the following systems that store, process, and/or transmit cardholder data:

• PoS device in the store
• e-Commerce Web Site
• Processing Server
• PCI Database

Step 2: Create Cardholder Data Flow Diagrams

Once you have identified all the systems that store, process, and/or transmits cardholder data, the next step is to create cardholder data flow diagrams. These can be drawn on top of a network diagram, or built separately. The point of this diagram is to trace cardholder data from its point of origin to its final destination, whether that be storage on the network, transmission to the payment gateway, or destruction. These diagrams are necessary to meet PCI DSS 3.2 requirement 1.1.3.

Step 2 Example

For the sake of simplicity, the diagram to the right is only focusing on the PoS systems, not the e-commerce website. Your diagram should cover all of the payment methods. This can be done with different color lines or using multiple diagrams, depending on what makes the most sense for you. So for our diagram:

• Customer comes into the store and pays at the register using the PoS
• The cardholder data gets transmitted to the processing server
• A copy is sent to the database
• Finally, it is sent to the payment gateway over the Internet

Step 3: Define your Cardholder Data Environment

Your CDE is the people, processes, and technology that store, process, and/or transmit cardholder data. So now that we have that all the information above, we can define the CDE. The CDE in this case is comprised of the store subnet, the PCI DMZ, and the PCI Server subnet. All of the systems within these subnets are completely in scope and must meet all PCI DSS requirements. The scope for your organization should also include the people who have access to these systems, including the IT department, database administrators, and cashiers.

Common Mistake #3 – Unnecessary Systems in CDE. A common mistake we see is that systems that are not necessarily required are either within the CDE or have access to the CDE. In our example, there is a store computer that is on the same VLAN as the POS terminal. This computer is likely just used for inventory and allowing the store manager to access email, etc. However, because this system resides within the same subnet as the POS, it is in scope, and must meet PCI requirements. To put this in perspective, that means every connection to and from this computer must be documented and approved with a business justification. When auditing this system, I will typically go to this machine and try to go to CNN.com, Gmail, and other random websites. If any of these are allowed and not documented, you are failing portions of Requirement 1.

Common Mistake #4 – Insufficient Segmentation. Another common mistake is that the boundaries between the different VLANs are not properly enforced. In order to be properly segmented, all connections between the different VLANs must be documented and enforced. All other connections must be explicitly denied. Check out our blog on testing segmentation.

Step 4: Identify All Systems Connected to the CDE

All systems and devices connected to the CDE or who are on the path of cardholder data as shown in our data flow diagram are also considered in scope for PCI. This includes all switches, firewalls, and routers on the path between these VLANs and on the path to the Internet.

Step 5: Identify Any Security-Impacting Systems

A security impacting system is any system that, if compromised, could affect the security of cardholder data. For this exercise, just pretend a system was compromised, and determine what the impact to your cardholder data environment would be. This includes any system that may give them access to the CDE. This also include any systems like NTP servers that support systems in the CDE. If an NTP server is compromised, it is unlikely that an attacker could gain access to the CDE, but they could mess with the timestamps of the systems and compromise forensic data, therefore impacting the security of the CDE. All of these systems that can impact security are in scope. A key distinction is that although these systems are in scope, every system that connects to these systems are NOT in scope. With that in mind common security impacting systems might include:

• IT Admin Workstations
• Jump Boxes
• Domain Controllers
• Vulnerability Scanners
• DNS
• NTP Servers
• AV Servers
• Logging Servers
• WSUS Servers

Step 6: Do Whatever You Can to Reduce this Scope

In terms of time, money, and the headache it is going to cause to reach compliance, the most important thing you can do when you determine your scope is to immediately reduce it as much as possible. Consolidate to as few systems, people, and VLANs as possible. For example, require your IT Admins to use a jump system (protected accordingly) to access the CDE. This will take their workstations out of scope. Create a separate store VLAN to remove the store workstations not involved in payment processing. Do whatever you can to reduce the number of systems that must meet PCI requirements. Of course, best practice says you should probably meet most of the PCI requirements on all of your organization’s systems as part of a robust security program, but if you limit which systems must have these requirements applied to be compliant, you’ll reduce your organization’s cost of compliance and have the ability to roll out a larger implementation over time.

Summary

Hopefully you’ve found this guide helpful in determining PCI scope. Of course if you have any questions, you can reach out to us in the comments below or via the contact us page, and we would love to talk it through. Additionally, here is the PCI Information Supplement on Scoping and Segmentation that further explains how to define scope. Finally, here is the official PCI flow diagram to determine if a system is in scope or not: