UPDATE: In May 2017 the Council issued an Information Supplement on Scoping and Network Segmentation that supersedes the Open Scoping Toolkit and introduces a Council approved set of terms. That is the official document to be used when discussing scoping and network segmentation issues.
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.
PCI Guru 
I have a fintech company that wants to do PCIDSS for the first time. They don’t have any PCI processes on the ground for now, they don’t transmit, process or store card data, but because they have future plans on PCiDSS processes, they want to get certified now. How possible is that?
Magic!
I am having some trouble deciding what category systems fit in due to VLAN segmentation. I have posted a diagram below. Take for instance the Fuel Controller device – this device cannot “see” any of the encrypted CHD that passes through SWITCH G due to VLAN segmentation. Why then does this device need to be classified as a 2B device? Based on the decision tree and the definitions for a device that directly attaches to a category 1 device – there is no getting around the category 2 classification. Guru, can you elaborate on the diagram below – do the classifications look correct?
[img]http://oi60.tinypic.com/2mx4x28.jpg[/img]
In a fuel implementation, it is going to depend on the type of controller and how your card readers work at the pump.
If we are talking ANDI-type controllers (i.e., analog), then there is no encryption at the card swipe so the controller has access to clear text track data.
If we’re talking a NexGen controller (i.e., digital), then we would need to know if you are doing DUKPT at the pumps’ readers or if you stayed with the DUKPT terminating at the controller.
BTW NexGen controllers are very scary because they are essentially a notebook PC in a locked metal box. They connect to the pumps and POS using Ethernet and you essentially have a network from your pumps back to the controller and off to the POS. All of which creates a tremendous attack surface that a lot of fuel operators do not realize is as big a threat as it is because of their experience with analog controllers.
Thanks for the information. Your comments do help. I was hoping for some clarification on VLAN segmentation issues, etc.. You are right – we are going down rabbit holes with scoping.
As an example: The switch that provides network services (directly connected) for 1A devices is definitely in-scope as you mentioned (1b switch) – but utilizing the toolkit decision tree – devices that touch category 1b devices would be in scope as well. That would include every VLAN on the switch and thus all devices regardless of access to CDE/CHD.
This is where we run into a lot of scoping/leverage issues. I would rather isolate those 1A (POS Lanes) to a switch designated for POS only, but it isn’t cost effective and it’s difficult to justify. I was hoping the toolkit would help me do that…
Not unusual particularly with core routers/switches where all sorts of network traffic can be processed.
It all comes down to whether or not your organization is willing to accept the risk? Since it sounds like you’re willing, you now have to convince your acquiring bank to agree with that decision. To do that you will have to assure the bank that you have appropriate controls on the network devices that would make it difficult to subvert your network. If your acquiring bank has formally agreed (i.e., you have a letter or email that proves their agreement), then your QSA should go along with that decision. If not, then you need a new QSA.
In regard to the NeXGen / single DES DUKPT – I think you are referencing the GSM or Gilbarco Security Module in which encryption is done centrally vs at the dispenser keypad. That type of encryption / implementation has not been acceptable for new deployments since 2009 (neither has single DES DUKPT at the keypad, but obviously much more secure than bringing the PIN block inside the store for encryption); but I just wanted to ask – none of that really matters in the first place, right? – the encryption – whether it’s single DES or triple DES, done at the pump or in the store – is only for the PIN block. The track data is not encrypted in any scenario and passes through the ANDI or NeXGen in the clear until it reaches the POS (and the POS takes it from there). Also wanted to point out that most NeXGen implementations are done like the ANDI – where it’s serial from the card reader to the NXG, as well serial from the NXG to the POS. The NXG can talk ethernet to the POS but not many take advantage of it – and I have never seen anybody do ethernet from the card reader to the NXG – in fact I am not sure anybody is. We consider the NXG in the CDE as a result of all the above – it processes and transmits CHD.
You are correct about single DES not being acceptable any more.
ANDI devices are serial to the fuel pump’s keypad and to the server. This is why there are limitations on the distance between the ANDI controllers and the server although most merchants use fiber optic connections and repeaters to get around the distance issue. The PIN block has always been encrypted at the time of the swipe.
According to Allied Electronics, the NexGen controller can encrypt from the controller with serial back to the keypad. The NexGen controller is essentially a notebook PC motherboard slightly modified to support the serial connectivity to the keypads as well as Ethernet back to the server. So the encryption gets closer to the keypad but it’s still serial and not encrypted. Unlike the ANDI where you would physically have to tamper with it, the NexGen allows someone to place malware on the NexGen and gain access to the cardholder data there.
Thanks for the information – we are talking about ANDI type of implementation.
One more question/comment.
There seems to be a lot of confusion about VLAN segmentation and scoping. For instance, if a system/lane with CHD is directly attached to a switch in a segmented VLAN – is that entire switch considered a 1B device or just the connected VLAN? If the entire switch is considered a 1B device than every other VLAN on that switch has a 2* classification. This definitely promotes physical segmentation of the CDE which can be difficult.
This is where things can get dicey and comes down to your risk tolerance. VLANs with ACLS are considered the way to segment a network.
Given we’re talking an ANDI controller environment, until the traffic gets from the pump to the server, it’s clear text but transmitted over a serial connection. Not that serial is more secure, but it takes significant effort to get at it. There would be no switch involved unless you’re converting serial to Ethernet.
The key question about your switch – is the CHD that traverses the VLAN encrypted (i.e., DUKPT) or is it in clear text? If it is encrypted AND as long as the switch cannot decrypt, then the switch is out of scope because encrypted CHD is not in scope as long as the device cannot decrypt. Yes, your organization may have keys somewhere, but at the device level, any intermediate device is out of scope as long as it does not have access to the encryption keys to decrypt the encrypted CHD.
Now if the switch is in scope because it does encounter clear text CHD, then is is a Category 1 device and you are relying on the VLAN and ACLs to provide segmentation alone. If an attacker owns the switch, they would have access to the clear text transmissions. That said, if an attacker owned a switch, they would probably own everything in your network. So grabbing data from a switch would be a last resort measure because they would just grab databases and files first. That said, if the switch is in scope, then you are correct, anything else attached to it become Category 2 devices.
…all of which makes it very difficult to actually utilize this toolkit. Based on your response (and guidelines I’ve always used) – even if a switch is directly connected to a system that interacts with CHD (cleartext) in some fashion – the switch is not in scope (otherwise a 1B device) if the CHD is encrypted as it transverses with switch. See the dilemma? You can take this even a step further – devices connected to a category 1 device are considered a category 2 device. The toolkit doesn’t fully take into account encrypted vs unencrypted CHD. Furthermore, Ive been through 5 PCI assessments and every QSA had a different idea about what is in/out of scope.
We need to think about scoping in the context of security and not compliance. However, it would be great to have clearly defined information to help with keeping the I’s dotted the T’s crossed from a compliance perspective which would free up more time to look at gaps and improve security controls.
If the switch is part of the cardholder data environment (CDE) then it is in-scope regardless.
The toolkit deals with security from a concept of the risk to exposing cardholder data (CHD) not compliance. That is the point of the categories.
But your frustration shows the dilemma of going down the “rabbit holes” of your environment. You need to take a HUGE step back, a BIG deep breath and look at the big picture and see the forest from the trees. Look for where you have risk? Can you remove that risk? Can you mitigate any residual risk? What to do you need to do to manage and monitor the residual risk? Focus on that instead of one switch or server and you’ll have a much better game plan and what you need to do will be a whole lot clearer.
I’m confused by the rationale for Category 2x even existing. I don’t see anything in the PCI-DSS Scoping that would include these devices that are 2-degrees of separation away from the CDE. The PCI DSS v3 is pretty clear about the distinction between the CDE and the connected systems that are in-scope. Taking this another step out to the machines that connect to the machines that connect to the CDE is problematic and, imo, unnecessary.
In fact, I believe scenario 9.3, the “Jump Box”, is exactly the kind of segmentation that PCI envisioned to keep the admin workstation out of scope.
I’m new to this PCI business, but what does this category derive from?
The risk with the administrator workstation is that someone installs a keyboard logger and then steals the credentials to the cardholder data environment (CDE).
The same holds true for call center operators that are entering significant amounts of cardholder data (CHD) through virtual desktop solutions. If their workstations are compromised, then the data entered through the compromised workstations is at risk.
That is what drives the category 2x definition is that there are systems one step removed that are still at risk. However, that does not necessarily mean that they need all of the “bells and wistles” of PCI, just that they are at risk and need to be monitored or hardened more than your normal workstation.
The open scoping toolkit has a couple of significant flaws. i.e. devices that can connect to CDE devices can sit on compromised network segments . this is bad. this is why the original document that we put together on the segmentation sig wasn’t ratified by the PCI TWG.
@Andrew, per my argument on the SIG, if an Internet facing DMZ is considered a CDE(which it is due to transmission of data) and we can open that CDE to the untrusted Internet, then suggesting that all other access must be somehow “Air-gapped” or that you can’t allow any access into a CDE seems somewhat difficult to justify. In my opinion the reason the sig failed is because the council did not want to get pinned down to a definition of scope which may not stand the test of time or was already flawed because the standard itself has inherent flaws. For example, usernames and passwords as a form of authentication and access, are analogous to the magstripe of a credit card; outdated and easily obtained.
All the more “troubling” was the PCI SSC’s comment at the 2014 Orlando Community Meeting that if a device is “three hops” away from the CDE that it is somehow out of scope.
At the end of the day, it all comes down to an organization’s willingness to accept risk. Organizations that are risk adverse are going to potentially go to significant lengths or take other extreme measures all in the name of security. Organization not as risk adverse may only secure and monitor devices rather than go to an extreme. Neither approach is wrong. It just matters on how much risk an organization is willing to swallow. That said, I have a tendency to believe that those that go to extremes will get tripped up by the complexity of their Rube Goldberg approaches to security.