PCI Scoping 101 - Open PCI Scoping Toolkit

The easy question is: Are you required to be PCI compliant?  If you accept credit card payments online then the answer is, “Yes”.   

 https://www.pcisecuritystandards.org/merchants/how_to_be_compliant.php   
“If you are a merchant that accepts payment cards, you are required to be compliant with the PCI Data Security Standard”.   
 

Miss leading information.

Many SI’s, payment gateway solutions or hosting providers claim that they can remove your requirement for PCI compliance.  Not True.  Even if you have outsourced the collection, transmission and storage of credit card data (CCD), you still must be subject to a PCI assessment however, limited.  What these solutions do is reduce the scope of your PCI compliance requirement.  As per requirement 12.8 you must know what your service providers are doing in addition still must assess your environment as a whole.

Another argument is, it is not necessary to meet PCI compliance requirements because the number of transactions annually are too few.  Again Not True.  If your organization accepts any number of payments found in the following table then you must be PCI compliant.

If you have…	then you can…	to achieve
less than 20,000 online transactions per year	self-assess	PCI Level 4 certification
between 20,000 and 1 million online transactions per year	self-assess	PCI Level 3 certification
between 1 million and 6 million online transactions per year	self-assess	PCI Level 2 certification
over 6 million online transactions per year	hire an independent assessor (QSA)	PCI Level 1 certification

Whether you must be compliant is the easy question.  The real question is, which of your systems are in scope for PCI compliance?

When asked what is “in scope” the simple answer is “systems that store, process or transmit card holder data”.  That is partially correct.   The PCI DSS documentation is somewhat more specific.  However, does not provide guidance on how to determine if systems are in scope for PCI-DSS assessment.  The fact is that the interpretation of scope is not that simple.  Quoting the PCI-DSS v3.1 standards documentation below.  

From PCI-DSS 3.1

Scope of PCI DSS Requirements

The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications. Examples of system components include but are not limited to the following:…

(list of technologies follow)…

The first step of a PCI DSS assessment is to accurately determine the scope of the review. At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data and ensuring they are included in the PCI DSS scope. To confirm the accuracy and appropriateness of PCI DSS scope, perform the following:…

From this we can determine there are loosely 3 device types 1 – in the CDE, 2 – connected to the CDE, 3 – not connected to the CDE.  Connected to… what’s that?  Is that in the same building or room, maybe on the same server or network… you can venture a guess otherwise, clear as mud.

The PCI documentation probably raises more questions than it gives answers.   What exactly is a connected system?  How much protection does it require, the same protection or less protection?  If less, how much less?   The answers are… not obvious.   Debates on scope flare between IT and the PCI assessor it is not simply about in or out of scope it comes down to what is connected and what is not a connected system.

Two of the categories are fairly easy to identify that is 1 and 3.  Yes, everyone can agree on those.  Category 2 is where debates arise.  What constitutes a category 2 system?  Followed by, how do you protect it “adequately” to meet the standards.    You have a few options to an answer the questions:

If you happen to have a PCI expert available they can help.  

Option 1 is hire on a PCI consultant (certified) for an answer.   However, don’t ask any two of them or you may end up with different answers.  That’s right it really is interpretive.  

Who knows your network and systems better than you? 

Option 2 create your own criteria.  Not entirely impossible you could come up with your own definition of connected.   Make sure you write down the criteria so you can at least be consistent when defining the scope yourself and your card processor.

Between using a consultant or doing it yourself you will find evaluating scope is not an exact science.  The how or why criteria are evaluated if you are looking for consensus under the current standards will not happen.  Given the number of approaches creates a blurring between the boarder of what is in and out of scope.

There is a third option that will not cost the money of a consultant or the uncertainty of creating your own definitions.  A standard has to be flexible enough to be applied across a wide variety of controls and architectures therefore, if very non-specific.  The PCI Scoping Toolkit allows a do it yourself approach while basing your decisions on predefined criteria. 

Data Discovery and Segmentation

Wait, before deciding what device are in or out of scope or plan how to protect the devices, take inventory, literally count your cards.  Then make an effort to limit the number of devices to protect.

Data Discovery

You could end up starting unnecessary projects and spending unnecessary money.  Before, you put devices into any of the scope buckets.  Make some effort to know where Credit Card Data is stored and clean it up or... reduce scope.  Best practice is to perform a data discovery.   This is done using an iterative approach:

1.       Look in some places you may “expect” to find CCD however, it should probably not be (database directories for table exports, in excel files of staff that may handle cards or call centres)

2.       Perform a scan using a sampling method

a.       Backup data sets (when doing restore tests works well)

b.      User data storage

c.       Developer DB’s

3.       If you can do it yourself however, sometimes easier to enlist the services of others.  Check with those doing your data backups if they can offer this service.

If card data is found remediate it, by removing, consolidating or protecting it.   If in the search you found a statistically significant number of rogue data stores or a large number of credit cards, you need to conduct another sampling.   A data discovery should be done least annually. 

The result of a data discovery followed by cleanup is you reduce the scope as well as costs of the PCI project.  A data discovery can be done without much effort and no costs.

Segmentation

Not a requirement of PCI compliance however a good practice.  Network Segmentation is referred to in the glossary of terms https://www.pcisecuritystandards.org/security_standards/glossary.php#N as the isolation of systems that store, process or transmit CCD from those that do not.  Recall above the PCI-DSS documentation defined in scope systems as those that are in the environment or connected to it.

Which raises the question of how exactly do we use segmentation to reduce scope?  The PCI-DSS documentation does not explain this.  In fact it leaves that interpretation up to the QSA in the process of an assessment. 

To get around the ambiguity the OpenPCI Scoping Toolkit was developed to create criteria and a means to evaluate the difference between isolated and connected systems.

The Open PCI Scoping Toolkit

From the website at ISACA Information Systems Audit and Controls Association you can download the PCI Scoping Toolkit.

http://www.isaca.org/Groups/Professional-English/pci-compliance/GroupDocuments/OpenPCIScopingToolkit.pdf

The PCI-DSS documentation provides a definition of what is in scope not however, does not provide testing criteria.   The scoping toolkit provides a more detailed evaluation, testing criteria and process that assists in determining where devices are classified.  Once classified it is easier to decide what controls are required for each device and system.

Better Define Segmentation

First the toolkit removes the difficult term “segmentation” and refers to connectivity as either:

Isolated: network traffic between systems is not permitted.

Controlled Access: traffic is restricted between systems by :

·         identifier (user identity, device address) ,

·         traffic type (port, protocol, service, application) or

·         connection initiation direction (inbound, outbound).

Category Clarification

PCI-DSS documentation eludes to 3 categories you need to define that then provide criteria to test.  Depending upon the results of testing you can basically justify how much security is required within the category.  Which means you will end up with sub-categories.  Let’s refine the category definitions:

Category 1 – devices or software that process, store or transmit credit card holder data; are not isolated or restricted through controlled access from other Category 1 components.

Category 2 – devices or software that have controlled access to a Category 1 components.

Category 3 – devices or software isolated from all Category 1 system components

Sub-Categories and Criteria

In order to go from broadly defined 3 categories and apply this to actual network configurations test criteria are required.  By walking through a decision tree found in the toolkit and answering some questions on each of device and its connectivity, you will find the device in one of 7 sub categories.  These 7 sub-categories are found in the table below.

Category	Description	Method of Segmentation	Vector of Attack	In Scope
1a	Systems  that store, process or transmit card holder data CHD.	N/A	Yes	Yes
1b	Systems with unrestricted network access to a 1a device; a "directly attached" system	Open (none)	Yes	Yes
2a	Systems that, through controlled access, provide security services to any Category 1 device.	Controlled Access	Yes	Yes
2b	Systems that, through controlled access, can initiate an inbound connection to a Category 1 device.	Controlled Access	Yes	Yes
2c	Systems that through controlled access cannot initiate connections to, but receive an initiated connection from a Category 1 device.	Controlled Access	Yes	Yes
2d	Systems that, through indirect access, have the ability to administer a Category 1 device. Note 2x devices have no direct access to/from Category 1 devices.	Controlled Access	Yes	Yes
3	Systems that do not store, process or transmit CHD. All network traffic between Category 3 and Category 1 devices is restricted  isolated .	Isolated	No	No

In Conclusion

The descriptions with a little thought will provide insight into where a device fits.  Do not trust the table above alone this is only a rule of thumb.  If earnest about scoping your network for PCI:

1.       perform a data discovery and inventory, map you data flows, consolidate and remediate

2.       use the decision tree to categorize systems and devices (Appendix A)

3.       implement the required PCI-DSS controls according to the standards and associated risk

Appendix A – Decision Tree from Open PCI Scoping Toolkit

 

Sources:

http://www.isaca.org/Groups/Professional-English/pci-compliance/GroupDocuments/OpenPCIScopingToolkit.pdf

www.pcisecuritystandards.org