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
