How to Scope & Segment Your PCI Environment

How should a company think about PCI Scope and Segmentation?

For companies looking to identify and reduce the scope of their PCI environment, through network segmentation, it is necessary to build in security controls to restrict the communication between trusted and untrusted networks and system components and validate which systems can communicate with or impact the security of the cardholder data environment (CDE).

PCI Scoping and Segmentation

Scoping

Scoping is the identification of people, processes, and technologies that interact with or could otherwise impact the security of cardholder data (CHD). When assessing PCI scope, the first principle is to consider everything to be in scope until proven otherwise.

If a company’s network is used for the transmission, processing, and/or storage of CHD, and it is unknown how that CHD traverses and/or resides on the network, it is safe to say that the entire network is in scope.

If a company’s interaction with cardholder data is limited to a specific network or network segment and security controls are also implemented to isolate that part of the network and meet PCI’s definition of segmentation, then just that isolated part of the network may be considered to be the company’s CDE, and the scope of the company’s PCI compliance can be limited to that CDE.

According to the Payment Card Industry Security Standards Council (PCI SSC):

“Segmentation involves the implementation of additional controls to separate systems with different security needs.”

Segmentation can consist of logical, physical, or a combination of both types of security controls, and common segmentation methods used to reduce the scope of the CDE include “firewall and router configurations to prevent traffic passing between out-of-scope networks and the CDE, network configurations that prevent communication between different systems and/or subnets, and physical access controls.”

Scoping Concepts:

• Systems located within the CDE are in scope, irrespective of their functionality or the reason why they are in the CDE
• Systems that connect to a system in the CDE are in scope, irrespective of their functionality or the reason they have connectivity to the CDE
• In a flat network, all systems are in scope if any single system stores, processes, or transmits account data.

Network Segmentation

Segmentation itself is not a PCI DSS requirement. However, to reduce the scope, cost, and effort to maintain PCI DSS compliance, network segmentation controls may be implemented.

We recommend this from both cost, effort, and risk management perspectives.

The intent of segmentation is to prevent out-of-scope systems from being able to communicate with systems in the CDE or impact the security of the CDE.

When implemented correctly, segmentation controls will prevent an out-of-scope system component from being able to impact the security of the CDE, even if an attacker can obtain admin access to the out-of-scope system component.

It is important to note that the existence of separate network segments alone does not automatically create PCI DSS segmentation. Segmentation is achieved via purpose-built controls that specifically create and enforce separation and prevent compromises originating from an out-of-scope network(s) reaching CHD.

Segmentation controls should be implemented with specific configuration settings and documented processes to ensure the ongoing, secure management of the technology.

Testing and Validation Scope and Segmentation Controls

Once a company’s CDE has been scoped and segmented to meet the business’ objectives for PCI compliance, the company must test and validate the segmentation controls on a periodic and ongoing basis.

PCI DSS Requirement 11.3.4 states that segmentation controls must be tested via penetration test on an annual basis or after significant network changes (whether internally via an independent party not responsible for the security of the CDE or an external party, such as risk3sixty).

For companies who are Service Providers, the requirement is to confirm segmentation controls via penetration test every six months, per PCI DSS Requirement 11.3.4.1.

QSA Responsibilities for Confirming Scope

As a PCI Qualified Security Assessor (QSA), that conducts PCI compliance assessments, risk3sixty has some responsibilities for confirming our client’s scope and segmentation controls as part of a PCI assessment.

As mentioned above, the entities that we assess are responsible for defining and confirming the scope of their PCI environment ahead of each annual assessment and conducting annual/bi-annual segmentation tests.

As a QSA, risk3sixty must:

1. confirm that the scope has been defined and documented properly by our client being assessed, and
2. that the client’s controls are operating effectively.

We then make a determination as to whether the segmentation controls implemented are adequate to effectively reduce the scope of the PCI DSS assessment.

Practically, and especially for new PCI clients, this begins with a conversation around the scope and often includes some strategy discussions over the client’s PCI environment and purposes for PCI compliance.

For additional information on PCI Scoping and Segmentation, see Guidance for PCI DSS Scoping and Segmentationfrom PCI SSC’s Document Library.

Important Note: Scope is the most important element to get correct, upfront, before pursuing PCI compliance – let us know where you have questions about this!

Scoping, Segmentation, and Compliance

When thinking through how to scope and segment your PCI environment, as well as how to implement and maintain PCI Compliance, here is a quick list to get you started and inform your approach to thinking about your PCI scope and compliance strategy, as described in PCI SSC’s Guidance for PCI DSS Scoping and Segmentation:

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6