Evan Schuman's StorefrontBacktalk

This conclusion holds even if the systems in question are segmented by an effective firewall that restricts their ability to interact with systems in the CDE—keep in mind that the PCI DSS Requirements and Security Assessment Procedures define “segmentation” to mean “isolation.” Naturally, the firewall itself is in scope because it connects directly to the CDE and provides critical security services.

So far, so good. The Toolkit supports the PCI Council’s guidance on scoping while adding some additional detail and color. However, the Toolkit begins to break new ground on the second question: Where does scope end?

The Scoping Toolkit makes a critical distinction between the CDE, which is infectious (as noted above), and those systems that can connect to or receive a connection from the CDE. The Toolkit treats these connected systems differently. They are in scope, but according to the Toolkit, the PCI scope ends there. These connected systems are not infectious. For example, based on the Toolkit, an enterprise’s antivirus update server is in scope if it can initiate a connection (through a firewall, remember) to a device in the CDE. But the rest of the enterprise’s systems that connect to that server are not drawn into scope. The merchant’s or service provider’s scope (i.e., “infection”) ends at that first “connected to” device so long as it does not store, process or transmit cardholder data and is isolated from the CDE. PCI scope does not continue to grow, thereby avoiding the formation of a daisy chain that encompasses almost every device in the enterprise.

The Toolkit again diverges from the PCI DSS Requirements and Security Assessment Procedures when it addresses the third question: What does it mean to be in PCI scope? Based on the Council document, if a process, device or system is in scope, then all 280+ requirements and sub-requirements of PCI DSS apply. This position has the appeal of straightforwardness. But the Scoping Toolkit challenges that.

The Toolkit takes a more nuanced approach, one that reflects the hands-on real-world experience of the people who created it. It describes how only a subset of PCI DSS requirements might apply to particular devices. The example given is for a workstation that, say, can pass through a firewall to administer a device in the CDE. That workstation does not store, process or transmit cardholder data. Although noting that each situation may be different, the Toolkit suggests that only PCI Requirements 1.4, 2, 5 and 6.1 might apply.

By identifying specific PCI requirements that apply in a given situation where scope is limited and by recognizing that each situation is different, the Scoping Toolkit adopts an approach similar to that underlying the shortened Self-Assessment Questionnaires (SAQs). That is, if a merchant’s card processing environment meets certain conditions, then it may validate its compliance against a subset of PCI requirements. The Scoping Toolkit extends this approach and applies it to the “connected to” devices and systems.

As I read the Scoping Toolkit, I find myself asking what will be its ultimate impact? As a QSA, I follow what the PCI Council provides in terms of definitions and guidance. Nevertheless, I respect the effort, thinking and expertise that went into both the Scoping SIG and the Scoping Toolkit. Maybe the Toolkit will generate some buzz at the upcoming PCI Community Meeting. I have to believe the timing of its release, just before that meeting, is not an accident.

Meanwhile, I would like to hear what you think. What is your reaction to the Toolkit? Is it a useful contribution? Do merchants and service providers need additional guidance on what systems are in their PCI scope? How will your organization use (or not use) the Scoping Toolkit? Either leave a comment or E-mail me.