Evan Schuman's StorefrontBacktalk

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

Sometimes, interesting developments in PCI come from places other than the card brands or the PCI Council. That is the case with the recent release of the Open PCI Scoping Toolkit. The Toolkit offers a thoughtful approach to scoping a PCI compliance assessment that every merchant—and every QSA—should read and consider.

The Toolkit reflects the work of the now defunct Scoping Special Interest Group (SIG). The PCI Council formed that SIG in response to a discussion at the 2009 PCI Community Meeting about what was included in an organization’s PCI scope. The SIG included merchants, vendors and QSAs (full disclosure: including this QSA), and the chair reported the preliminary recommendations at the 2010 Community Meeting. Attendees and members of that SIG will note that some of the diagrams shown at the meeting surface again in the Toolkit.

The difficulties are that the Scoping SIG never released its report and that this Open PCI Scoping Toolkit, which is based on that SIG, lacks the approval of the PCI Council. Therefore, whether QSAs and their clients will be able to implement the Toolkit’s recommendations, and whether the Toolkit will have a lasting impact on this critical area of PCI compliance, is yet to be seen.

The Toolkit addresses three fundamental scoping questions: What systems are in scope for PCI compliance; where does a merchant’s or service provider’s scope end; and what does it really mean to have a system or device “in scope?” In answering the first question, the Toolkit agrees with the present position of the PCI Council. In addressing the other two questions, however, the Toolkit breaks new ground and presents a more nuanced, risk-based approach to PCI compliance.

Let’s consider each of the three questions the Scoping Toolkit addresses, beginning with identifying what is in scope.

Properly defining a merchant’s or service provider’s PCI scope is the first, and perhaps most important, step in a PCI compliance assessment. The PCI DSS Requirements and Security Assessment Procedures devotes four pages to defining PCI scope:

“The PCI DSS security requirements apply to all system components. In the context of PCI DSS, ‘system components’ are defined as any network component, server or application that is included in or connected to the cardholder data environment.”

Determining a merchant’s or service provider’s cardholder data environment is straightforward. The QSA or Internal Security Assessor (ISA) probes, questions and makes a general nuisance of her/himself to identify all the people, processes and systems that store, process or transmit cardholder data. That process defines the cardholder data environment (CDE).

The Toolkit agrees with the Council’s definition, adding the colorful description of “infectious” to describe the CDE. The idea of the CDE being infectious is a good one. (I sometimes refer to cardholder data as “toxic waste” to communicate the same idea.) The term conveys the message that any system that connects or can connect to the CDE—even if that access is controlled by a firewall—is infected and in scope for PCI compliance. It is like walking into an isolation ward in a hospital: Once you enter, you become subject to additional monitoring and controls.

In the real world of PCI, the types of systems that can connect to the CDE include those that can receive an outbound connection from the CDE (e.g., a Domain Name Server), initiate an inbound connection to the CDE (e.g., an antivirus or patch update server) or even just administer or print reports from a device in the CDE. All of these systems are in scope.