Scoping and Segmentation; Who is responsible for deciding what is in-scope for PCI DSS assessment?

Dennis Steenbergen

 It all begins with you and your Cardholder Data Environment or "CDE". Drawing a circle around the very thing that counts as auditable is the assessed entity’s responsibility, not your Qualified Security Assessors (QSA) responsibility. Your QSA is only responsible for agreeing that you got the scope correct. If you haven’t read the PCI DSS Guidance document on scoping and segmentation, give it a read.
The PCI Standards Security Council  provides concrete direction:

At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of its PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers) to ensure they are included in PCI DSS scope.”

The associated documentation that will support you in this scoping process should include your internal vulnerability and discovery scans that includes your entire internal IP address range scope. This helps have an updated inventory of devices that are alive on your network. Additionally, the security council's guidance document states that you need to know how the flow of Cardholder Data (CHD) flows through those devices you just discovered. Useful documentation for this requirement is your Data Flow Diagram. We recommend to review your data flow diagram and asset inventory quarterly for changes as well as your scanning documentation to ensure new devices have been validated as known and have a purpose.

Lastly lets have a quick look at “connected to” systems. "Connected to" systems are systems that do not process, transmit or store CHD but are connected to systems that do and if compromised, permit lateral movement through your CDE. The Data Security Standards Council makes this a distinction.

What are "Shared Services"?

Example Segmentation Illustration: “Connected-to” Shared Services from the SSC's "Guidance for PCI DSS Scoping and Network Segmentation"
 This example above published in the scoping and segmentation guidance document shows a shared services enclave located outside the CDE. Remember the CDE is anything that processes, transmits or stores CHD but anything that is “connected-to” or provides services to the CDE is also “in-Scope” and should be added to your asset inventory for assessment.

So how does the corporate enterprise systems that are out-of-scope connect to the “Connected-to” systems so we can administer our CDE AND keep that hole can of worms out-of-scope? Normally we don’t want to have our corporate enterprise in-scope for PCI DSS assessment because that would invite more cost and complexity to assess everything. Additionally, we want to reduce risk by reducing the possible attack surface should our enterprise network is compromised. We like to keep this aspect of our environment in a separate box.

The first rule of thumb is to only allow admin access to the shared services enclave from within the shared services enclave. This follows that access to our CDE also is only permitted from devices within the CDE or from within the shared services enclave. Of course, we have multi-factor authentication from our shared services enclave to the CDE as well. I bet your still thinking about how in the world do we get into the CDE from the corporate enterprise network? Its easy, any account used to access shared services from the corporate enterprise has no access to the CDE. Enterprise accounts are segmented or separate from the CDE. They only get you access to shared services and nothing else. Now your thinking hold-on, didn’t we just state that access to shared services is only granted from within shared services? Admin access is only permitted from shared services to shared services. This means that the account from the corporate enterprise has zero admin access into the shared services environment.

This means we can login but make no changes. That’s where jump workstations come in. Once your jump-station is accessed then you can begin to RDP and SSH into other areas of your shared services and CDE environments with different accounts that DO have privileged role-based access. This is a logical segmentation step that ensures isolation of these two critical aspects of your scoped environment and is keeping with the spirit and intent of segmentation.
Created with