Quietly on Friday, December 9, 2016, the PCI SSC released the draft Information Supplement titled ‘Guidance for PCI DSS Scoping and Network Segmentation’. As with all Information Supplements, the information documented in these does not replace any of the requirements in the PCI standards. These documents contain only guidance and suggestions as to how organizations can comply with the PCI standards.
Overall this Information Supplement does not break much new ground regarding the clarifications that have been given over the years on these two subjects. The Council has taken a much simpler approach to defining categories of systems than did the Open PCI DSS Scoping Toolkit (OPDST). The Council only has three categories:
- CDE Systems (Category 1A/B in the OPDST)
- Connected-to and/or Security-Impacting Systems (Category 2A/B/C/X in the OPDST)
- Out-of-scope Systems (Category 3 in the OPDST)
One thing the Council has done is provide some good examples for how to prove systems are out of scope. If a system meets ALL of the following criteria, then it is considered out of scope.
- System component does NOT store, process, or transmit CHD/SAD.
- System component is NOT on the same network segment or in the same subnet or VLAN as systems that store, process, or transmit CHD.
- System component cannot connect to or access any system in the CDE.
- System component cannot gain access to the CDE nor impact a security control for CDE via an in-scope system.
- System component does not meet any criteria described for connected-to or security-impacting systems, per above.
The Council goes on further to say that even though these systems are out of scope for PCI compliance, they still need to be secured and patched regularly to ensure the overall security of the organization.
However, there are two points I noted that will likely require some additional clarification from the Council as they are going to potentially cause issues with a lot of organizations.
On page 7, the second paragraph, the document states:
“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 to prevent compromises originating from the out-of-scope network(s) from reaching CHD.”
The paragraph taken as a whole seems to imply that the Council is taking the conservative position that only firewalls can be considered as network segmentation controls. It is the phrase “purpose-built controls” that needs to be further defined by the Council. Earlier in the document there is an example provided using firewalls which the paragraph would definitely lend itself.
In the past, the Council has said that access control lists (ACL) and encrypted tunnels also constituted valid network segmentation. However this paragraph calls into question whether those are now considered “purpose-built controls” or not. One would assume so, but as we have all learned in the past, one should never assume with the Council. As a result, it would be great if the Council could provide clarification on what exactly they mean by “purpose-built controls” in the final release of this document.
The next point of concern is on page 11 in the Connected-to and/or Security-Impacting Systems table. The third bullet down in the list of criteria states:
“System component can impact configuration or security of the CDE, or how CHD/SAD is handled—for example, a web redirection server or name resolution server.”
It would appear from this statement that the Council has brought Web servers that perform a redirect into scope for PCI compliance as they are considered ‘connected to’ systems. That will be a huge blow to merchants using redirects to keep their Web servers from having to be ASV scanned and meeting all of the other PCI requirements contained in SAQ A-EP.
The only remaining question is if those Web sites using iFrames will also now be in-scope for SAQ A-EP compliance as well? Time will tell.
I have no idea when the final version of this document may be released. But if the Non-Listed Encryption Solutions Information Supplement is any indication, it could be released on this coming Monday to the public.