You would think this question would be an easy question to answer when talking about the PCI standards because anything that processes, stores or transmits cardholder data is in-scope for PCI compliance.
However, the nuances in the implementation of technological solutions do not always allow a black and white answer. Here are some of the most common in-scope issues we seem to come across.
Defining The Cardholder Data Environment
The first step in any PCI assessment is determining the extent of an organization’s cardholder data environment (CDE). However, it should come to no surprise to anyone that defining an organization’s CDE can be difficult even in the smallest of organizations.
The first question is who is responsible for defining the CDE? Until the release of the PCI DSS v2.0, this was not clear, but had always been implicitly defined by the PCI SSC and the card brands as the responsibility of the organization, not the QSA. The QSA’s role is to take the CDE definition provided by the organization and confirm that the CDE definition is accurate based on the QSA’s assessment work.
The next question that inevitably comes up is how does an organization prove that its CDE is its CDE? There are a variety of things an organization can do to define their CDE.
The first thing to do is to document the cardholder data flow. This effort should define all of the applications involved as well as which applications actually store cardholder data. Once the data flow is defined, then an organization should develop a network diagram that documents all of the firewalls, routers, switches, access points, servers and other network devices and how they are architected.
The final step in proving the extent of the CDE is for the organization to scan their entire network to confirm that cardholder data is not stored anywhere outside of the CDE. For organizations that have invested in data loss prevention (DLP) technology, it usually means setting their DLP solution to look at all computers on their network and determine if any unencrypted cardholder data exists anywhere outside of the proposed CDE.
However, some DLP solutions have not capability to look at data stored in databases, so just because you have a DLP solution does not mean you have searched everything.
For those organizations that do not have a DLP solution, the process is the same but possibly a bit more complicated. For organizations that have a budget, they can license GroundLabs’ Enterprise Recon utility to scan their network and databases.
For smaller organizations, GroundLabs also has Card Recon that it licenses on a number of PCs/servers basis. There are also free or open source utilities available such as Spider from Cornell University, SENF from the University of Texas and CCSRCH from Sourceforge.
I personally prefer Spider from Cornell as I think it finds the fewest false positives of the three free utilities. However, none of these utilities can scan a database and find cardholder data stored in a database. And just so we are clear, all of these utilities are no absolute guarantee that an organization has truly found all cardholder data they may have stored on systems. But, it is better than have done nothing.
For organizations that are not using a utility that understands database scanning, there is a manual way to conduct your assessment. Unload any credit card account number (PAN) fields as well as all comment fields into a CSV or similar file format and then use whatever utility you are using to scan those files for cardholder data.
Networks and Managed Service Providers
Networks that are used to transmit cardholder data in the clear are always in scope – no exceptions. Where things seem to get confusing for people is when encryption is brought into the mix. However, going back to the original definition, if cardholder data is in the clear, then that portion of the network is in-scope. But, believe it or not, this just creates more confusion and arguments.
The bottom line is that any network encryption endpoints are also always in-scope. That is a statement that I have almost come to blows over more than once with managed service providers (MSP) that thought their devices and network were totally out of scope because of encryption.
In a lot of these instances, the MSP is the one managing the encryption keys and since they managed those endpoints and the related encryption keys, those endpoints are in-scope for PCI compliance and so are the MSP’s policies, standards and procedures for managing those devices (Requirements 1, 2 and 4) and keys (requirements 3.5 and 3.6).
“But the cardholder data is encrypted,” is the common refrain from the MSP. Agreed. But a QSA still needs to gauge compliance for the endpoints, not the connectivity between the endpoints.
However, MSPs argue that the endpoints are also out of scope because of encryption. That would be right if someone other than the MSP managed the encryption keys. Another battle QSAs run across is about MPLS networks.
At this year’s PCI Community Meeting, the question of MPLS networks being private was brought up and discussed. What the PCI SSC and the card brands told QSAs is that it is up to the QSAs to confirm that the networks are in fact private. That means that QSAs are going to have to examine the configuration of the endpoint routers to ensure that the MPLS network is in fact private.
I can tell you that this will put QSAs in a battle with a number of carriers who treat their MPLS networks and their configuration as intellectual property. I can tell you from personal experience that these battles to get carriers to reveal their configurations can become very contentious and downright ugly.
The bottom line is that a lot of MSPs do not agree with their activities being in-scope and they refuse to allow an assessment of their environment where their activities are in-scope. In those instances, we have no choice but to mark the client as not having those requirements in place.
I have constantly asked MSPs that fight us to explain why the MSP is not responsible when the client cannot respond to the requirement because the MSP performs that function? More often than I would like to admit, we get the “trust us” response. In a few instances, I have been told that, “The PCI SSC and card brands never meant it to be treated that way.”
Really? Because in QSA training the PCI SSC has been very consistent on the explanation of what is in-scope and MSPs are in-scope if they perform functions that are required to comply with the PCI standards. While the majority of MSPs have come to this realization, there are still holdouts out there that still refuse to cooperate.
Applications that process, store or transmit cardholder data are always in-scope – period. I think everyone understands that statement; however, it is the nuances within applications that create the problems.
In today’s integrated application environment, it is no wonder that determining what applications are in-scope is difficult, if not impossible. Most organizations have gotten out of the complete application development game and are now in the application package integration game.
As a result, organizations are relying more and more on the application package vendors to understand data flow, particularly cardholder data flow. While the PA-DSS process has greatly helped in getting data flow diagrams, there are still a lot of credit card processing applications where the data flow diagram is just not supplied.
Then we have “middleware” that further obscures things. Middleware reformats information streams so that one application package can communicate with another application package. The biggest problem with middleware comes from the fact that a lot of application integration teams are not really sure as to whether the cardholder data is in cleartext or encrypted.
The other problem we have encountered with middleware is the lack of security surrounding the administration consoles of the middleware. Most middleware consoles are browser-based and can be accessed by anyone on the network. Worse yet, a lot of these consoles can have serious security issues that make then susceptible to compromise.
Hopefully this explains the most common issues we see with scoping PCI assessments. If you have any situations where you question scoping, please share them with the group and hopefully we can explain what is in-scope and what is not in-scope.
Cross-posted from PCI GuruCopyright 2009-2011 Respective Author at Infosec Island
Sign-up for our free newsletter to kick off your day with the latest technology insights, or share the article with your friends and contacts on Facebook, Twitter or Google+ using the icons below.