PCI DSS Toolkit

Since 2012, Open Scoping Framework Group is providing a free PCI DSS Scoping toolkit.

Successful PCI DSS compliance depends upon the correct identification of the scope of the assessment. An overly narrow scope can jeopardize cardholder data, while an overly broad scope can add unnecessary cost and effort to the PCI compliance program. Subjective interpretation of the PCI DSS guidance results in a wide variance in practice among both QSAs and Participating Organizations.

When scoping errors occur, organizations will not focus on what matters most – that becomes a flaw - An overly narrow scope of assessment could potentially jeopardize cardholder data, while an overly broad scope potentially adds unnecessary cost and effort to achieving PCI compliance.

If you are a QSA, ISA or someone responsible for PCI compliance somehow you must follow these:

OSFG-Open Scoping Framework Group was originally created by Gene Kim whose name should be familiar to almost everyone - 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.

Here are the activities that occur in CDE:

§ Processing – when cardholder data is actively being used by a system component (e.g., entered, edited, manipulated, printed, viewed) Open PCI DSS Scoping Toolkit (August 2012).

§ Storing – when cardholder data is inactive or at rest (e.g., located on electronic media, system component memory, paper).

§ Transmitting – when cardholder data is being transferred from one location to another (e.g., data in motion).

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.  Although attempt 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 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 have, nothing will.

Although addressing the people and processes around cardholder data is a necessary part of any PCI compliance program, the Toolkit focuses almost entirely on categorizing the system components that comprise an organization’s computing environment. In addition, the Toolkit does not define what PCI DSS controls are required for each Toolkit category. Because every organization is different, it is up to each organization and its assessor to determine the nature, extent and effectiveness of each control to adequately mitigate the risks to cardholder data.

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.

Thiago Leoncio.

IDM & Security SME.

Reference: Open PCI DSS Scoping Toolkit