The Council just published new Guidance for PCI DSS Scoping and Network Segmentation to help clarify basic scoping and segmentation principles provided in the PCI Data Security Standard (PCI DSS). We sit down with CTO Troy Leach to discuss the guidance.
Why is the Council issuing this guidance?
Troy Leach: The Council is issuing this guidance to provide further clarification on scoping and segmentation practices and because this topic is one we have been asked to address frequently during my entire tenure with the Council. The guidance is aimed to help both large and small entities evaluate which system components should be covered by PCI DSS requirements. Data breach investigation reports continue to find that companies suffering compromises were unaware that cardholder data was present on the compromised systems. If you can limit exposure of payment data in your systems, you simplify compliance and reduce the chance of being a target for criminals.
Is network segmentation a PCI DSS requirement?
Troy Leach: Network segmentation is not a PCI DSS requirement but we’ve always encouraged a strategy that minimizes systems that have access to cardholder data. This not only helps reduce cost and effort associated with a PCI DSS assessment but also provides greater focus to evaluate and monitor those critical systems that remain relevant to protect payment data. That’s why, while not a requirement, we do include guidance directly in the standard because it is a valuable concept to consider.
Why is it important for organizations to consider network segmentation when segmenting their CDE from other systems/networks?
Troy Leach: If you can limit exposure of payment data in your systems, you simplify compliance and reduce the chance of being a target for criminals. That is why you hear so much from us on “devaluing data” by reducing access to account numbers that can be stolen and exploited for future fraud. Similarly for segmentation, by limiting the assets and locations of cardholder data in your network, you can drastically reduce the number of systems to protect, which means your security efforts become more focused and more manageable. And better security should translate to simpler compliance efforts.
What differentiates this guidance from previous scoping and segmentation guidance?
Troy Leach: This guidance is more detailed than scoping guidance that we have provided before in any Frequently Asked Question (FAQ) or whitepapers. Segmentation is a very complex topic because each network is very unique. We understand that many want explicit guidance that explains clearly how to implement segmentation; however, controls that work effectively in one environment, many not be adequate for another. Because of this, this guidance paper aims to provide guiding principles that each entity could use in their own network in a way that works best for them. In this guidance, we provide two detailed examples that we hope will provide not only clarity but also ideas for how to design infrastructure to be more effective going forward.
What is the potential harm in not properly segmenting a network?
Troy Leach: Many account data compromises are a result of organizations trying to do the right thing but unaware that secondary or tertiary connections had access that could be compromised but was overlooked. We cannot emphasize enough the importance of the exercise to thoroughly review the potential access and flow of payment card throughout an organization. Because of this, out of scope systems are often targeted by attackers since they have less oversight and fewer security controls, and are then used to attempt to gain access to in-scope systems to get the cardholder data. Penetration testing is a critical tool for verifying that segmentation is appropriately in place to isolate the cardholder data environment from other networks. A network that is not properly segmented can put cardholder data at risk.
Does this guidance offer recommendations on how to determine what third party entities are in scope?
Troy Leach: This document describes a method to help organizations identify the systems that, at a minimum, need to be included in scope for PCI DSS. It is intended to cover segmentation principles, and potential impact on PCI DSS scope, but is not intended to cover every method that may impact PCI DSS scope (such as tokenization, encryption, use of third parties, etc.). Additionally, the document provides guidance on how segmentation can be used to help reduce the number of systems that require PCI DSS controls. Many of our information supplements such as the Third Party Security Assurance and Cloud Security Guidance documents created by our Special Interest Groups contain additional information on navigating third-party relationships.
Who is responsible for determining an entity’s scope?
Troy Leach: The assessed entity is responsible for annually determining PCI DSS scope and confirming its accuracy, and for ensuring that scope is kept accurate on an ongoing basis. The assessor performing the PCI DSS assessment is responsible for confirming that the scope has been defined and documented properly. Assessors should discuss scoping decisions if any are not clear in the assessed entity’s documentation. In such cases, the assessor should work collaboratively with the entity to understand the scoping decisions made.
How will this guidance impact merchants and service providers?
Troy Leach: Merchants and service providers will be able to use this guidance to further understand scoping and segmentation principles, and it will help them understand which system components should be covered by PCI DSS requirements. As we talked about earlier, this may also help in future design of networks as well.
How can assessors use this guidance?
Troy Leach: Assessors will be able to use this guidance to gain clarification on scoping and segmentation principles, as it applies to PCI DSS. It will also help them directly with performing PCI DSS assessments and facilitating conversations with the entities they are assessing for controls that could be considered for good segmentation.
Could this be in a future version of the PCI DSS?
Troy Leach: Unlikely, although we do already have guidance on segmentation within the PCI DSS and we may evaluate if there is value to include any clarity or additional material. Segmentation is a discretionary decision and this paper is intended to clarify principles that may improve effectiveness of PCI DSS requirements and approach to the overall assessment.
