Back in May 2017, the Council finally issued their long awaited Information Supplement on Scoping and Network Segmentation. Based on some questions I have received since then, there are apparently a lot of people that still have not read the official information supplement.
So, I am invoking “RTFM” which means the first order of business is to get everyone to read the information supplement before asking questions. The second order of business is to forget everything that was discussed in the Open PCI Scoping Toolkit as the Council will tell you it does not apply and never did apply. Even though they never offered any alternative until the publication of the aforementioned information supplement. So, throw away all your copies of the Open PCI Scoping Toolkit as it is not usable anymore.
With the Council’s information supplement, there was a change in terminology in how we refer to the various network segments and what is in scope. As you will see, the Council’s approach has simplified the scoping classifications. Because of the pervasiveness of the Open PCI Scoping Toolkit, I have included some references to the categories used in the Toolkit to clarify the Council’s terminology.
- Cardholder Data Environment (CDE) Systems – These systems are always in scope for PCI compliance. These are systems that are either: (1) a system that directly processes, stores or transmits cardholder data (CHD) or sensitive authentication data (SAD), OR (2) a system or component that is on the same network segment (i.e., same network subnet or VLAN) as a system component that directly processes, stores or transmits CHD/SAD. With the Open PCI Scoping Toolkit, these were considered ‘Category 1A/1B’ systems.
- “Connected To” or “Security-Impacting Systems” – These systems are also always in scope for PCI compliance. These systems are basically those that directly connect to systems in the CDE or could influence the security of the systems or data in the CDE. In the Open PCI Scoping Toolkit, these were the ‘Category 2A/2B/2C/2D’ systems. Unlike in the Open PCI Scoping Toolkit, the Council chose to simplify things and have only one category versus the “shades of gray” approach. That said, there are more detailed criteria defined on page 10 of the information supplement that define these systems. Examples include, but are not limited to, Active Directory (AD) servers, RADIUS servers, TACACS+ servers, Security Information and Event Management (SIEM) solutions, Network Time Protocol (NTP) servers, Domain Name System (DNS) servers and Domain Host Control Protocol (DHCP) servers. These systems and devices can also be considered as “Shared Services” because they provide service not only to the CDE but also to out of scope systems.
- Out of Scope Systems – There are four criteria for these systems: (1) The system must NOT process, store or transmit CHD/SAD AND (2) the system cannot be on the same network segment or subnet as the CDE. AND (3) the system cannot directly connect to any other system or component in the CDE AND (4) The system does not meet ANY of the criteria described for “Connected To” systems. If all of these criteria are met, then the system is out of scope. In the Open PCI Open Scoping Toolkit these were the ‘Category 3’ systems.
As we have found out at the Community Meetings since the publication of the information supplement, the Council will demand you use their scoping terminology. If you use the Open PCI Scoping Toolkit scoping categories, you will be asked to restate your questions or comments using their terminology. So please from here on out use the Council’s terminology whenever discussing scoping categories.
Why Is Scoping A Problem?
Scoping is a problem because organizations think it is the QSA’s problem. However, the PCI DSS states on page 10:
“At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their 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 the PCI DSS scope.”
Eight times out of ten, it falls into the QSA’s lap to determine and confirm PCI scope even though it is the assessed entity’s responsibility to define scope and the QSA’s role is to confirm that analysis. This is why arguments over scope happen. QSAs get into trouble because they follow the processes defined below and determine that the scope is not correct. Had the assessed entity done their work, the argument likely would not have happened or at least would not have been as big as it became.
The purpose of this post is to explain what your QSA is doing when they asked for all the documentation and what they are doing that your organization should be doing before the QSA even shows up. For QSAs, this is what you should be doing to ensure that the scope of your engagement is correct.
Follow The Data
The first thing that people seem to get wrong about scope is fixating on the storage of CHD and ignoring the processing and transmitting of CHD/SAD. This is a big reason why voice over IP (VoIP) gets missed. VoIP typically never stores CHD/SAD. But when customers are making payments over the telephone, CHD/SAD is being discussed and that is what makes the telephone system a CDE and therefore in scope for the PCI assessment.
The key to resolving this is to follow the CHD/SAD through your networks. When he was a Council trainer, Art (“Coop”) Cooper was famous for constantly telling his classes to, “Follow the data.” Therefore, the data flow diagrams overlaid on your network diagrams are so especially important in determining PCI scope. Done properly, these diagrams allow you to understand where the CHD/SAD flows through your organization (i.e., transmission), where it is processed, as well as where it ends up stored.
From that analysis, you can then document where, if anywhere, the CHD/SAD is encrypted and who manages the encryption keys. If your organization manages the encryption keys, then you will need to prove and document that those intermediate devices between the encryption endpoints cannot decrypt the CHD/SAD in order to keep them out of scope. If an outside third party manages the keys, then scope is reduced to where the encryption endpoint is in your environment. For more about encryption and scope, see my Encryption Series of posts listed on the Post Series References page.
Once you have completed this activity, you have defined your CDE, likely many of them. It is not unusual for organizations to have their VoIP network and solution as one CDE and then another for their eCommerce or brick & mortar retail. But there could be even more CDEs depending on your environment.
One other caveat on scoping CDE. Devices that are in the CDE that do not process, store or transmit CHD/SAD are in scope for PCI compliance. These include devices and systems such as jump servers, switches, routers, Active Directory domain controllers, DHCP servers, DNS servers and firewalls.
And that is the rub in this process. It is not unusual to have a client determine that their CDE is larger than they originally believed. This is particularly true in environments that are rapidly changing. The reason is that changes occur that involve the processing or transmission of CHD/SAD and people forget that those are also in scope because of their fixation on storage of CHD. So do not be surprised to be surprised when this analysis turns up with in scope devices that were not believed to be in scope.
Connected To Systems
With the CDE(s) defined, we now we need to define all the systems that connect to the CDE(s), hence the “Connected To” designation by the Council. The reason Connected To systems are in scope is because they can influence the security of the systems and devices inside the CDE. The term you will hear some people use is that Connect To systems can be ‘infectious” to systems in the CDE.
The first place to start is by reviewing the firewall rules or access control lists (ACL) that segment your CDEs from the rest of your network segments. You will likely find specific IP addresses for devices such as Active Directory domain controllers, security incident and event manager (SIEM), FTP, DNS, DHCP, RADIUS, TACACS+ and similar services. It is not unusual to see application and database servers in a complete network subnet.
The second place to investigate are the organization’s most recent penetration testing results for network segmentation. It still amazes me how even with a detailed examination of the firewall rules and ACLs that there are still devices that end up with connectivity into the CDE because of human error examining the rules and ACLs. So use the network segmentation testing to double check your review of the firewall rules and ACLs.
Once you have identified all these networks you then need to make sure that you have an accurate inventory of all the systems and devices on these networks. I typically ask for Nmap scans of the network subnets to make sure the inventory is complete. I take the Nmap results and compare those to the organization’s configuration management database (CMDB) or whatever they use to track their system/device inventory.
I also make sure that all the devices and systems found in this process are contained in their internal vulnerability scanning. Again, it is not unusual to find out that devices and systems are not being scanned quarterly for PCI which is why this check is important.
Now We Have PCI Scope
With all of this done, we now know the scope of the environment and what must be assessed. But, remember, while you are done for the current assessment, this all needs to be performed again next year.
PCI Guru 