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.
You’ve answered this questions on scoping on so many ways. Being new in this PCI, I’m faced to answer these PCI questions. I try to do research as much as I can. Anyway, here is a simple situation which you can provide a very shor answer. We have business activities that use the credit card swipe devices like the Verifone VX570 that you see everywhere. Some connect via phone, others via Internet and are segmentd from the rest. The problem is that the VX570 is also connected to the POS workstation via USB for the workstation to receive the credit card transaction confirmation. No CC data is passed, only the transaction approval (one way traffic). Since there is a (USB)connection between the VX570 and the POS, does it make it part of the CDE scope?
Tnx for all the assistance to people who need it.
RBD
This sort of configuration of the card terminal (in this case the Vx570) is fairly common whether the connection is USB or RS232. However, you need to prove that no cardholder data is being transferred through the POS from the terminal. That can be somewhat difficult and where your POS application’s PA-DSS implementation manual can come in handy for explaining this configuration.
That document you sent me is super helpful. I now have a greater understanding. Thank you!!
The PCI “expert” at the company we use has told me different answers then what you have said. They did not know anything about segmentation or why you would use it… (I now understand it is not required, but would be used to limit in scope systems). The below stuff is from a different PCI “expert” there.
Can you please evaluate these statements from the company we use for CC transactions:
1. PCI compliance does not specify that a merchant cannot print a report that has full cardholder information. It is recommended that the report function be password protected and that you not utilize auto settle if individuals would have access to the report when it is printed. In that case manual settle would be the best option to monitor who has access to the report. I will check with our processor to see what report is set up to print for . If the detail report prints on auto settle this would include the full card number if it is the totals report it would not. Please remember either report would not contain expiration, cardholder name, cvv code, etc., only the card number. This information can be stored as long as it is secure and not stored with the additional cardholder information.
2. We can write down all the information, but not to many, store it for a short time to enter it later, then securely destroy it. Based on what you have said, this is not true. I am unable to find where it says this in the PCI standards. Can you please point me to this directive? I see it ask “Protect stored cardholder data” and it is mentioned above that we can store it if is not the full data and is protected.
I hope this my questions and your answers are helping others and not just me.
Thanks again.
Thank you.
1. The SSL site makes the rest of the network not in scope for a risk assessment.
2. Since it would be the only workstation that enters card data, it must be fully segmented from the rest of the “has nothing to do with credit cards” network. Meaning they cant use that credit card entry PC to access normal work content. Got it.
Thank you!
Our processor told us that we had to do an official risk assessment. We use the NIST 800-30 for other requirements, so that is why I was going to use that one.
1. Is there another simpler risk assessment form we can use?
2. What if we want to use the processors HTTPS log-in site to type in cards?
Technical speaking we have access to the encryption keys, as the PC will negotiate the encryption with the processors site. (The site does not use a hardware certificate key, nor a installable certificate). The site just uses a normal SSL connection. Based on what I read at the links below all of our network would be in scope if it is not fully segmented. There is no mention of this not being the case if there is SSL encryption. As a side note I am told by the processor that the site is PCI DSS compliant.
Network segmentation:
We use VLANs which are all routed to talk to each other, and I am told by our networking crew that the only way to truly segment these workstations would be to place them on a completely separate network and use a firewall for isolation. Staff uses these workstations to do their normal job, get email, surf the web, etc.
3. What kind of segmentation meets PCI DSS compliance and will keep me from a risk assessment of my entire network?
4. Would we have to stop all other work related activity/surfing on these PC’s if segmentation is not needed?
Thank you for all of your help!
LINKS:
Workstations not segmented are in scope:
https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-does-PCI-DSS-apply-to-individual-PCs-or-workstations/?l=en_US&fs=Search&pn=1
Encrypted data is still in scope:
https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Is-encrypted-cardholder-data-in-scope-for-PCI-DSS/?l=en_US&fs=Search&pn=1
Look at my last response as I think I’ve hit what the risks are unless there is something about the physical terminals themselves that you think you should consider. All you need to do is list the risks and what you are doing to manage those risks. IMHO, a full NIST 800-30 in this instance is way overkill.
When using HTTPS, you only have access to the site’s SSL public key, not the private key that is on the server to which the PC connects. You network is NOT in scope as the connection is SSL encrypted and none of your intervening devices can decrypt the connection. While your network is out of scope, you need to ensure that the PCs used this way are properly hardened, patched current, firewalled, have current AV, etc.
Firewalls are one way to segment a network, but not the only way. Depending on your switches’ capabilities, you can use access control lists (ACL) to segregate your network. The key is that you can manage, control and monitor network traffic that is allowed to flow between segments. You just need to isolate your PCI cardholder data environment (CDE) from any networks that do not need to access the CDE. Those segments that do need access to the CDE, need to be isolated from other segments that do not need access to the CDE.
Gene Kim and company have produced a great guide for scoping a PCI assessment. You can get a copy here.
I have just confirmed that we do NOT have access to the decryption keys.
Three of the CC machines are behind the scenes, (No outsiders have access to this area.) which are in an alarmed, video taped and locked (building) at night. The building uses a badge to get into as well. Staff access hours are limited and all entry is recorded. The other two CC machines are at the front counter (behind it) where we have staff working, and are in an alarmed, video taped and locked building at night. Keys are required to access this building after hours.
The CC machine is password protected, so you can’t easily coax out any reports.
I take it this means that I only need to do a NIST 800-30 on the credit card machines. Is this correct?
What other risks, other then theft would these machines have?
Is there anything else I should be doing?
Thank you for all your help!
Across the board for all terminals involved, you need to ensure that the terminals are properly configured and are not storing cardholder data (CHD). Believe it or not, I have encountered terminals shipped directly from processors and they are not properly configured and are storing PANs that can be printed out on the register tape via the terminal’s reporting capability. I would also ensure that you are keeping your video online for 3 months and available for review for at least a year so that in the event you do have something odd going on, you can review video to determine what might have occurred.
If I understand you correctly, three terminals are used for card-not-present transactions because they are in a secured back office. The risk here is people writing down primary account numbers (PAN), CVC/CID/CVV and expiration date. As long as you periodically confirm that people are not writing CHD and you training them to not write CHD down, you should be good for that area.
The two terminals out front I would assume are used for card present and, possibly, card-not-present transactions. The risk here is also writing down CHD as in the back office. But another risk is that clerical personnel could be skimming cards. So you should periodically review your video to ensure people are not “accidentally” dropping cards on the floor and skimming them or similar moves.
Doing a NIST 800-30 risk assessment is up to you, but probably overkill given the limited risks presented.
I just spoke to our processor and they said that our credit card machines do use P2PE.
How does that change the game?
Thank you,
Dalobo
What you need to confirm for me is if you have access to the encryption keys for the P2PE solution.
If you do not have access to the P2PE encryption keys, then you cannot decrypt the cardholder data once the information is input into the terminal and sent to the processor. Since it is encrypted and you do not have the keys, then no devices between the terminal and the processor has access to the data, so your network is out of scope.
That said, the terminal is still in-scope as it is the endpoint. So you need to ensure its security.
One thing I neglected to ask. Do you process card present transactions, card not present transactions or both? For card not present environments you need to make sure that you train your personnel that enter the cardholder data that they cannot write it down or make any record of it other than to enter it into the terminals.
I am having a hard time finding out what would be in scope in my situation.
I have three stand alone credit card machines. They hook into our network on a voice VLAN, which hits the voice server and then goes to the router and out one of a couple of T1′s (Phone lines, not data lines). The voice VLAN MAY have routes to the PC VLAN.
1) Do these stand alone machines need to be isolated from the network?
2) If so, is a separate VLAN just for them good enough?
3) If not, how do I go about achieving network segmentation?
4) If they can be on the voice VLAN do I just added the IP phones to the risk assessment?
5) Is there anything else I should be considering with regards to segmentation?
Whether or not these terminals need to be isolated depends on how they communicate with the processor. If they are using point-to-point encryption (P2PE) between the terminal and the processor, then you are fine as is. However, I doubt that is the case, but you need to check.
A separate VLAN is fine as long as they are the only thing in that VLAN and there are ACLs in place that isolate the VLAN from all others.
Segmentation here is going to be difficult as your VoIP call manager is going to be in-scope regardless because it has to process the dial out to the processor. If P2PE is not implemented, then your entire VoIP implementation is in-scope as you are currently configured.
See my series of posts on Network Segmentation on my Post Series References page.
I represent a hospitality company. The core system for hotel functions is the property management system (PMS). The PMS system itself is in scope simple because it holds / transmits CC information. The front desk PCs are in scope because they are the point of entry for CC data (through the swipes). The PMS however also handles functions related to housekeeping/ accounts payable / accounts receivables / reporting — modules of the PMS not having stored CC data. The users each have individual logons and rights to the PMS and based on those rights they may or may not have access to modules w/ CC data (the majority do not). The question is are those PCs that access the PMS for none CC related tasks within scope if they are segmented from the CDE and access only allowed via a few specific controlled ports?
As clarified at the 2012 PCI Community Meetings:
“If a system can impact the security of the CDE (whether it is directly or indirectly connected), it is in-scope. To be considered entirely out of scope, a network or system must be isolated from, with no connectivity into, the CDE (such that even if the system is compromised, it cannot impact the security of the CDE). Restricting access by IP or port may limit the exposure of the CDE but does not automatically remove systems/networks from scope since there is still connectivity. If connections are limited to specific ports or services, those systems are included in the PCI DSS scope to verify applicable controls are in place.”
Under this clarification, your PCs with access to the PMS are in-scope regardless of whether they actually interact with the cards.
I am guessing that, in the future, vendors will start separating application functionality so that you can create such an isolated CDE. Until then, you have what you have.
I am confused about what is considered “In-Scope”. If I have a computer that is on the same network as the Point of sales system but it does not process or store any card holder data but can access the registers that do process cardholder data is it considered “in-Scope”
Thank you
At last Fall’s PCI Community Meeting the PCI SSC clarified their definition of out of scope. That definition states, “To be considered entirely out of scope, a network or system must be isolated from, with no connectivity into, the CDE (such that even if the system is “owned”, it cannot impact the security of the CDE)”
Therefore, any systems that have access to the cardholder data environment (CDE) such as a computer that can access the POS, is in-scope for PCI compliance. Just “how compliant” those systems need to be is determined by how much access into the CDE the system has. In your example, the PC would need to be totally compliant, i.e., built to a standard configuration, security hardening, log monitoring, critical file monitoring, etc. However, a system that can only gain access through a single port might only need to be secure and have AV installed depending on what it did.
Our QSA is telling us because our back office pc is on the same subnet as the pos that it is in scope. Our problem is manager access this pc to view sales data and generate reports, he said it will be hard to make this pc compliant because multiple users access this pc and the all need different windows logins, is there a way around this? We can not put the pc in its own subnet because the registers send sales information to it via windows file sharin( no card holder data)
Your QSA is telling you the right information. Your back office PC is in scope.
I would discuss with your QSA what you have as options to correct the situation. Your QSA knows much more about your network and security measures in place and should be able to provide you with a number of ideas to address this issue. If your QSA has no ideas or will not assist you, then I would find a new QSA.
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.
“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”
Can you point me to the documents from SSC that support your interpretation? We have a set of workstations used to take CC payments over the phone. The operators use a web browser over https/ssl to enter the CHD in to an off-site third-party proccessor. We are currently being told all our networking equipment used in the route between the workstations and the off-site third-party proccessor are in scope. From what I read here you would disagree. Thanks.
This was discussed at the 2012 PCI Community Meetings during the PCI Standards Updates and Future Insights presentation.
That said, this has always been discussed in QSA/ISA training. The rationale is that, as long as the intermediate devices cannot decrypt the data stream, then they are out of scope. However, those devices cannot also be part of the cardholder data environment (CDE).
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
I’m confused about CDE. We have a web server that accepts credit card input, and is in a DMZ, but sends that CHD to the database which is in another, restricted segment. According to the DSS, the web server is part of the CDE because cc’s go through it. 1.3.3 says “Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.” That means the web server may not be contacted from the Internet, which is of course ridiculous. Where am I wrong?
Thanks in advance,
Peter
It’s only confusing because you have not had the advantage of going through QSA/ISA training.
What the PCI DSS is trying to stop is the storage of cardholder data (encrypted or not) on a server in a network segment that is directly accessible from the Internet. Processing and transmission are obviously allowed via the Internet otherwise we would not have eCommerce.