The Real Story Behind PCI Scope and Segmentation

The definition and maintenance of a clear scope of applicability for any standard is always a challenge on complex networks. A lot has been written about scoping, but this blog will focus on scope reduction and segmentation.

Just to recap… segmentation is not a PCI requirement. It’s only used to reduce scope and carve out a portion of your network (both wired and wireless) to be assessed. A smaller environment equates to an easier PCI burden. (Be sure to secure those systems not in scope for PCI so they are not used to gain access to additional systems and/or used to gain access to the cardholder data environment (CDE)).

Segmentation can be achieved in many ways. It could be logical controls like access control lists, security groups, hypervisors, etc. It can also be physical controls – completely separate systems. As long as out-of-scope networks cannot talk to the CDE, you have achieved your goal.

What does “not talk to” really mean? Exactly that. No communication is possible on any port in either direction (CDE to out-of-scope assets or vice versa). None. It does not mean limited communications; it does not mean controlled communications. It means no communications. If a system can communicate with the CDE, it’s a “connected to” device and is in scope.

Having separate network segments is not enough to achieve scope reduction. You have to have filtering in place to prevent those segments from talking. Without the controls between each segment, your entire network is in scope because all of your segments are (at a minimum) “connected to” segments.

When your assessment begins, the assessor confirms scope. Part of that confirmation is making sure the segmentation methods are configured and working properly to allow for scope reduction. Part of the confirmation efforts include looking at the penetration test results (both internal and external). Your pen tester needs to confirm segmentation controls as part of their testing (Req. 11.4.5). Many pen tester reports miss this requirement when assessing a PCI environment. The pen test needs to check communications in both directions (into the CDE and out of the CDE). Be sure to verify your pen test includes a segmentation test long before your assessment begins.

The segmentation test may come back with open ports. And that’s OK … only if those networks are considered in-scope, such as a shared services zone. The shared services zone is where you find the systems securing the CDE (DHCP, DNS, NTP, anti-malware, authentication services, etc.) This entire zone is in scope for your assessment. The shared services zone will have open ports into the CDE. The shared services zone can talk to both the CDE and the out-of-scope systems. This zone does not contain any account data. The assessor will review the pen test and the open ports between the shared services zone and the CDE and request business justification for their use (Req. 1.2.5). This should be a very limited number of ports and systems. Allowing all ports from the shared services zone into the CDE will most likely not be compliant because there will be no business justification. Where possible, access should be restricted for each port to only those machines that would use it.

Regardless of how you do it, segmentation is definitely worth exploring to ease your compliance burden. Contact GuidePoint for assistance in minimizing your PCI scope.