As most people familiar with the PCI Data Security Standard would agree, properly defining scope for PCI compliance is a key success factor in achieving compliance with this challenging set of requirements. Network segmentation, if properly implemented, can limit the scope of applicability for the PCI DSS to a subset of the network and systems in an organization. Unfortunately, many companies inadvertantly define the scope for PCI improperly due to some common misunderstandings related to the rules for PCI compliance scope definition.
The PCI DSS, a set of over 200 technical and administrative security requirements, applies to all organizations that handle credit card data. The rules for what needs to be in scope for PCI compliance are as follows:
- The cardholder data environment is comprised of people, processes and technology that handle cardholder data or sensitive authentication data
- The PCI DSS applies to all system components included in or connected to the cardholder data environment
- The PCI DSS also applies to all systems involved in managing the security of other in-scope systems (i.e. authentication servers, log management servers, IDS management consoles, etc.)
A proper understanding of the above three points holds the key to properly defining the scope for PCI compliance. Starting with the first point, we see that any system or person that handles cardholder data is in scope. Consider the following scenario… A customer service representative takes orders by phone, including credit card data, and enters the info into a payment application. This payment application runs on a server at the corporate data center and stores cardholder data to a back-end database. In this example, the customer service rep’s PC would be in-scope, as would the payment application server, the database server, and every network device the traffic passes through. A common mistake is to use network segmentation to isolate the payment application server and database server, but then to leave the customer service PC’s out of scope. If those users are accessing or entering cardholder data, then those systems are in scope!
Moving to the second point, we see that all “connected” systems are also in scope. This relates to network segmentation, and means that any systems connected to the same network segment are automatically in-scope for PCI compliance. This is because of the fact that if one of these systems was compromised, it would be in a better position to target systems handling cardholder data, as there is no firewall to get through at that point. Companies often apply segmentation correctly when it comes to servers handling cardholder data, but many forget to address end-user systems that are accessing cardholder data (CHD), or systems involved in managing the security of other in-scope systems.
The third point is also often overlooked. Any systems involved in managing the security of in-scope systems are also considered in-scope and need to be secured according to the same requirements as other in-scope systems. Example of such systems include, but are not limited to:
- Authentication servers
- Key management servers
- Firewall/IDS management consoles
- Log management servers
- Anti-Virus management servers
- Domain controllers used to enforce Group Policies
End-user systems are a common area where companies make mistakes when it comes to defining the scope for PCI compliance. If an end user accesses or works with electronic cardholder data in any way, that end user’s system is in-scope. Even if a user just views a credit card number on screen, with no local storage of cardholder data – that credit card number that was displayed was just transmitted to that end-user system, and that system is therefore in scope.
For companies with employees that need to access cardholder data within a centralized system, but don’t need to enter new cardholder data, a thin client approach may be considered to remove end-user systems from scope. By deploying a thin-client server within the cardholder data environment, in a separate segment from the end-users, those users can then connect by VPN with multi-factor authentication to the thin-client server and do their work from their. In this scenario, the cardholder data is being transmitted to the thin-client server, but not to the end-user system. In this case, the user would still be in scope, but the end-user’s system would not be. This can be an effective way to eliminate large numbers of end-user systems from the scope of PCI compliance.
Keep in mind, however, that the above approach does not work as well for employees that are taking orders or otherwise entering cardholder data into a system. Even with the thin-client approach, a keylogger installed on the end-user’s PC could still capture the cardholder data as it is entered. For this reason, the end-user systems would still be in-scope.
Spending some time and effort making sure to properly define the scope for PCI compliance should be the first step in every organization’s PCI compliance process, as these efforts can save large amounts of time and money in subsequent PCI-related efforts. While most companies are not required to work with a QSA, it is highly recommended that companies verify their scoping approach with a QSA before proceeding with remediation.