PCI Scoping Toolkit: Where QSAs Fear To Tread?
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.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.