Since September 2012, the Open Scoping Framework Group has been providing free of charge the Open PCI DSS Scoping Toolkit. If you are a QSA, ISA or someone responsible for PCI compliance and you have not gotten a copy of this fantastic document, you need to get a copy. A copy is easy to get, just go to the IT Revolution Web site, register and you will be allowed to get your copy.
Never heard of the Open Scoping Framework Group (OSFG)? Neither had I until late last fall when a friend told me to go check out their PCI scoping methodology. The OSFG was started by Gene Kim whose name should be familiar to almost everyone as the founder of Tripwire. He got together his DevOps group to tackle the issues faced by all of us trying to scope the cardholder data environment (CDE) and the result was the toolkit.
The toolkit defines three categories of systems.
- Category 1 – System components that process, store or transmit cardholder data or are not isolated or restricted through controlled access from other Category 1 system components.
- Category 2 – System components that have controlled access to a Category 1 system component.
- Category 3 – System components that are isolated from all Category 1 system components.
People always get the reason why Category 1 devices are in scope because they are contained in the CDE. While one would think that Category 3 components would be also just as easy to categorize as Category 1, but that is not necessarily the case. The key is that Category 3 systems cannot have any access to Category 1 components. While attempting to ping Category 1 components from the Category 3 component could be used, a better test is to use Nmap or similar port scanner from a sample of Category 3 components to scan the CDE IP address range to determine if any ports are open.
While Category 3 components can be troublesome, it is the Category 2 devices that usually give everyone a problem including, at times, yours truly. The reason is the connectivity issue as it can be very unclear at times whether or not a device actually has connectivity to the CDE.
To assist in identifying connected systems, the toolkit breaks Category 2 systems into four sub-categories.
- Category 2a – System components which, through controlled access, provide security services (e.g., authentication) to a Category 1 device.
- Category 2b – System components which, through controlled access, can initiate an inbound connection to a Category 1 device.
- Category 2c – System components which, through controlled access, can only receive a connection from a Category 1 device (i.e., cannot initiate a connection).
- Category 2x – System components which, through indirect and controlled access, have the ability to administer Category 1 devices. Note: Category 2x devices have no direct access to/from Category 1 devices.
The first thing we need to clarify is what is meant by “controlled access.” Controlled access means that the system components have: (1) limited network traffic to only that which is required for business operations; and (2) are business justified and documented.
It is the first point of controlled access that typically give people the most trouble. The concept of “limited” network traffic just does not come across the same for everyone. I have seen people try to justify limited traffic when just about every port north of 31000 is open for dynamic use. Do not get me wrong, there are instances where a significant number of ports need to be open (look at Windows 2003 Active Directory as a prime example), but when the answer used to justify the large number of ports is, “We did it to be safe and avoid any problems” says to an assessor you did not want to research the exact ports you needed open or, worse yet, you have no idea what ports are needed to be open.
The sub-category most people will struggle with is 2x. 2x components are those that do not have direct access to the CDE but have access to 2a, 2b and/or 2c components that do have direct access to the CDE. The best example of this sort of situation would be a system management console for a log management server. The console has access to the log management server which does have access to the CDE, but the console should not have access to the CDE. Since the console could be compromised and it has access to a component that has direct access to the CDE, it needs to be included in the scope of the PCI assessment.
The final pieces of the Open PCI DSS Scoping Toolkit I really like are the decision tree and the scenarios provided. If these do not help explain how to scope your PCI assessment, nothing will.
Again, if you do not yet have a copy of the Open PCI DSS Scoping Toolkit, hopefully this post will entice you to get a copy.