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
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.
Hi,
you said “In those instances, we have no choice but to mark the client as not having those requirements in place. ”
You mean that they’re not going to be certified because of their MSPs? Did the MSPs have the right to do that to their clients ?!
When you say that “If a third party manages the keys and no one in the organization being assessed can decrypt, then the data is not in-scope”. How is it possible? If the organization needs the keys for decrypting the PAN, then the data is in scope right ?
Thanks.
S.
The MSP was either not PCI certified or was only certified in requirements 9 and 12. However, the MSP was providing services covered by other requirements such as firewall management and monitoring or network management and monitoring (all or parts of requirements 1, 2, 4, 6, 7, 8, 10 and 11). Basically, the MSPs would tell us and their customer that their services were not in-scope and that we were not allowed to assess their operations to determine if they were compliant. In one case, we were told that the PCI SSC never meant QSAs to review MSPs’ services which is absolutely false. While most MSPs now understand their obligations to comply with the PCI DSS, there are still a number of MSPs that continue to fight with QSAs over their services as related to PCI compliance.
In today’s card processing environment, there is no business reason a merchant needs to store the PAN. For those instances where a merchant needs the PAN for resolution of disputes and chargebacks, a merchant can get the PAN from their processor.
Tokenization is a prime example of a solution where the merchant has no way of getting back to the PAN.
The PCI SSC states that cardholder data that is encrypted is not cardholder data as long as it remains encrypted and cannot be decrypted by the party looking at the encrypted data. So for a large organization where only select users in the accounting department can decrypt cardholder data, those select users and their computer systems would be in-scope for PCI compliance.
When cardholder data is transmitted encrypted such as with SSL or IPSec, when the cardholder data is between the two encrypting/decrypting endpoints, it is also not in scope. As a result, all of the telecom equipment between the endpoints are also not in scope.
Thanks for the mention of network/systems/database scanning. I’m having a frustrating time being satisfied with scans in the absence of DLP products. Spider and SENF are fine for one system, but become cumbersome if you have more than a handful of systems and servers to scan just to demonstrate that there *isn’t* CD on those targets. At least Spider supports UNC pathing…
There are a number of other excellent data discovery tools that you neglected to mention. These include:
FScout by Foregenix
7Seek by 7Safe
PANScan by Security Metrics
PANFinder by 4Tech Software (limited to HP Non-Stop Tandem)
I think if you mention one, should should really mention them all.
Sorry. Not a deliberate snub, but I have not had a chance to use the utilities you mention, let alone know of a complete list. Besides, the landscape in this area is changing almost weekly, so it is difficult to keep up.
Re. Tokenisation – if you are using format preserving encryption, where-by you keep the first 6 and last 4 digits, isn’t there a concern that the middle 6 digits could easily be re-established given there is only finite number of combinations.
Re. Encrypted Data – I would always view encrypted data within scope, even if a third party is managing the keys. Why? If that third party is breached and the keys stolen then the encrypted data is open to compromise.
The PCI DSS states that truncating the PAN to the first 6/last 4 is not considered cardholder data. Is that smart given your example? Given that the last digit of the card number is the check digit, I suppose you could ultimately figure out the missing five or six digits. However, given the fact that a number of digit combinations could result in the same check digit, you would still have quite a number of potential solutions that you would have to try and see if they worked. During which, you would likely be found out if you tried too many transactions.
If a third party cannot provide a PCI AOC for the key management or any other PCI in-scope services, then it is the responsibility of the organization or its QSA to assess the third party’s key management and other in-scope processes.
In the case of outsourced Tokenization… if an entity transmits cardholder data over SSL to a web service hosted by the Tokenization provider, do all components along the way (aggregation, distribution, and core switches fall into scope)?
As long as none of the entities involved in the middle can not decrypt the SSL data stream, then they are out of scope.
PCI Guru – you are welcome to take a spin of CDD Enterprise – just email contact at controlcase dot com to get a special deal for providing everyone (including us) with such insightful information.
- A regular reader of this blog.
Thanks, your posts are always enlightening.
I follow a couple of simple rules while assessing if data is “in-scope” or not.
- If the data is in a form which can be reversed or circumvented such that the original clear text can be read, then the data in question would constitute as data “in-scope”. That makes data stored in encrypted form (online or offline), data stored behind some strong access controls, data hidden behind a view, etc as data in scope.
- If some process is adopted where data is obfuscated such that the data cannot be reversed to its original form (except only on the machine that is doing the obfuscations itself, which would make that machine in-scope) then that data can be considered out of scope. Forms of data would include tokenization, one way hashing (salted), random substitution, truncation, data masking, etc.
I find some conflicting opinions of other QSA’s considering encrypted data to be out of scope if strong key management processes are in place. What I understood during my QSA training was that encrypted data was “in-scope”. If you say that a MSP who also stores and manages the keys would make the network they manage in scope, the same can be said about any organization that encrypts data and stores the keys themselves.
Regarding scanning, I agree that scanning has to be performed on DB’s and systems alike. I have found systems that claim only to switch CHD to be storing CHD in app log files and other least expected locations. Scanning is a must during scope determination, Gap assessments and during the actual audit itself.
I agree that there is confusion among QSAs regarding how to treat encrypted cardholder data. The PCI SSC has always instructed QSAs to look at encrypted cardholder data, determine who manages the keys, and then make a determination as to whether it is in-scope or not. IF the organization being assessed manages the encryption keys, then encrypted data is in-scope. If a third party manages the keys and no one in the organization being assessed can decrypt, then the data is not in-scope. The latter instance is still fairly rare, but is catching up as more and more organizations turn to tokenization and hashing.
We view encrypted cardholder data as out of scope for all but those who can decrypt it. So for example, if store clerks and store bookkeepers cannot decrypt cardholder data, then we do not worry about their access and confirm that they cannot decrypt. We only delve deeper on those users that can decrypt the data and why.
One of the oldest and well tested solutions in the Card Discovery space is ControlCase Data Discovery. There is a FREE version available for people without a budget and for the rest there are other options and an Enterprise version which also searches through Databases and doesn’t have the limitations of traditional DLP tools.
It is lightweight and agentless – no need to install and maintain agents on every desktop.
Have a look at http://cdd.controlcase.com