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.
PCI Guru 
would in-scope remote admin laptops be subject to the internal scans – PCI DSS Requirement 11.2.1? These remote admin systems while not continuously connected to the CDE, they are in scope. This scoping guidance document clearly calls these remote admin systems out and makes it seem like all applicable PCI DSS requirements would apply, so why wouldn’t PCI DSS Requirement 11.2.1? While it might be inconvenient to obtain four quarterly passing scans for these systems, I do not think that would matter?
I would assume that such laptops would all be built from a common “hardened” image, updated, maintained and managed common as well. If that can be documented and evidenced by the QSA, then you should be able to scan as many as possible each quarter and apply any results (i.e., remediate any vulnerabilities) to all of them for that quarter. However, you need to be able to show that you scan all of those systems at least once a year.
With this scoping document and per input for our QSA, it appears that jumpboxes are no longer adequate for keeping a remote employee’s laptop with admin access to our PCI in scope environment…out of scope for our review. However, my company’s engineers proposed a VDI option as potential viable solution for keeping remote latops out of scope…but our QSA said the PCI Council has already shot this idea down. Is this true? If the VDI environment is PCI compliant, I have a hard time seeing a valid reason that the remote laptop still need to be in scope of PCI.
The notebook or desktop accessing the PCI environment still has some scope albeit reduced PCI requirement scope. I would argue that as long as your basic security configuration for your admin PCs are adequate, then they should be fine.
Thanks… Do you know anything about AWS Workspaces? It appears to be their DDaS solution. Any thoughts on it? Our Engineers our considering it…saying it would be easy to locked out for compliance. However, it does not appear not be have been assessed for PCI compliance by AWS (at least according to their website). Can’t see it being a feasible solution for PCI compliance, if it hasn’t been assessed for PCI compliance by AWS….since we would have no responsibility for the underlining infrastructure.
I have not had a chance to look at Workspaces yet, but I would concur with your analysis given what I have been told about them.
After reading the scoping guidance I went to my client and strongly suggested they outsource payment. If the PCI Council continues this way, everthing in the environment, despite strong network isolation, comes into scope.
Remember though that the scoping document from the Council is only guidance, it does not change anything in the PCI DSS. If someone prefers the guidance from the Open PCI Scoping Toolkit or some other reasonable scoping approach, that is also allowed. But I do agree with your rationale you gave to your client.
Love your blog, I regularly check back here to get your analysis of recent developments in the world of PCI DSS.
Web redirects to payment processing sites would not be considered ‘connected-to’ systems for two reasons:
1. The webserver issuing a redirect never actually makes a connection to the redirect destination (CDE) – it tells the client/browser to make the connection request. Similar for i-frames.
2. For a lot of merchants, the payment pages are part of the payment processor’s CDE and not in scope for the merchant’s assessments. The merchant would not need to play ‘connected-to’ mind games.
Page 11 of the segmentation guidance calls out “web redirection server” and not “web redirects” as possible examples of connect-to systems. To my mind, the only time a web server performing redirects is brought in to scope as a security impacting device or connected system is if:
1. The webserver has additional functionality or connectivity to a CDE above and beyond issuing web redirects.
2. And that the CDE to which it has connectivity belongs to the same merchant.
For anyone else reading this reply I wanted to point out that what I mentioned above is only from the perspective of segmentation. Redirects and i-frames represent several risks (which PCIGuru has already covered in other articles) and there must be appropriate controls in place to mitigate these (even if not mandated by SAQ A).
I would like to say that the Council agrees with you, but they do not. The Council has taken the position that ANY device that has the potential to affect the payment process is in-scope. How much in-scope depends on the risk presented. In the event a server that does a redirect is changed to send payments to “My Bad Payment Page” whose fault will that be? The merchant or the payment processor? It will be the merchant’s fault and they will be the one legally on the hook. That is all the logic you need.
On segmentation and external access. If you have a remote worker , eg laptop user , they multi-factor to a Jump box and then access the CDE , IF the Jump box has disable copy and paste , disable drives , printers and so on, with no permissions to the jump box , would the laptop be in scope ?
The laptop is in scope, but the requirements it must comply with are reduced based on the risk it presents to leaking CHD from the CDE. If the laptop is only looking at CHD and that CHD never exists on the laptop other than the display, then I would think all of the hardened configuration controls and AV would be sufficient. If the laptop is accessing CHD and potentially storing it, then it would be entirely in scope. Also, if the laptop is being used to enter CHD for MOTO, then it is also in-scope but may also have reduced scope if configured to ensure that memory scrapers and keyboard loggers cannot be installed.
General Inquiry – I’ve noted in some of your articles you have referenced that “PCI SSC has stated any requirement can have a CCW.” Is this documented anywhere? Unable to identify in FAQs
This is one of those statements that were made at various Community Meetings over the years as well as by some QSA trainers. However the PCI DSS did not start out that way, so this is a recent change within the last five or so years.
That said, it is only a theory that you can write a compensating control worksheet (CCW) for any PCI DSS requirement. There are some requirements such as 3.2 where there are going to be no controls that will get you around the fact that your organization stores cardholder data unencrypted.
Another CCW that becomes impossible to write is for using Windows 2000 on your network. I have worked with clients that have tried this feat (after I had warned them) and what they find out is that it is a giant rabbit hole of problems. Just when they think they have it done, the QSA comes in and finds all sorts of issues with the controls that can be easily circumvented. After three to four iterations of this, clients typically give up because they are frustrated that they are getting nowhere. As a result, I have yet to see a CCW for Windows 2000 that is effective and could survive the scrutiny of a QSAC QA or Council AQM review.
Lauren Holloway from the PCI Council answered a question asked by a participating acquirer representative on the December 2016 Acquirer Forum webinar for the meaning of “Purpose Built Controls”. Her answer was: Controls which are built & managed by the entity being assessed to manage segmentation. It depends on how those controls implements segmentation and must be evaluated on a case by case basis.
So it seems that the Council is not discrediting previous technical controls that implemented segmentation, such as VLANs, access control lists (ACL) and encrypted tunnels and that they are not limiting such controls to just firewalls.
Why are you calling this a draft publication? The document revision table says initial release 1.0 and the press release makes no indication this is a draft. Not that it won’t be updated at some point, just wondering why you’re stating this is a draft inferring it’s still being worked on.
The copy I got from the Portal has a “draft” watermark.
My interpretation is that web-redirect/iframe servers are in scope, but only for the requirements listed in SAQ A (i.e. parts of Requirement 2 and 8). So nothing new there really.
What’s remarkable though is the bullet point in the rightmost column (page 11), stating that these components “Must be evaluated against *all* PCI DSS requirements”. This (again) contradicts FAQ 1331 and prevents us from using the Not Tested response.
If PCI SSC really wants to prevent anyone from using Not Tested responses, why don’t they simply remove it from the standard?
How about domain controller that serves both PCI and Non-PCI? I guess based on above guideline it will bring everything in scope as any Non-PCI machine has to communicate with DC which is clearly in scope.s
Active Directory (AD) domain controllers (DC) have always been in-scope for compliance if they provided services to the CDE and/or connected systems. That said, systems that get services from the DCs but do not have access to the CDE are not in-scope.