A big thank you to a reader for suggesting this post with a post to my Miscellaneous Questions page with a number of questions related to call centers.
Based on their questions, the first clarification that needs to be made is in regards to pre-authorization data. In a call center environment where operators are taking orders over the phone and accepting credit/debit cards for payment, until the card transaction is either approved or declined, we are talking pre-authorization data. Only cardholder data after authorization or decline (also known as post-authorization data) is covered by the PCI DSS.
However, as I have noted before, the card brands expect pre-authorization data to be protected with the same voracity as post-authorization data. The PCI DSS can provide organizations with a guideline on how to protect pre-authorization data, but pre-authorization is not in-scope for PCI compliance.
That said, just because it is not in-scope for PCI compliance; do not think a QSA is not going to consider it. Any good QSA should review the pre-authorization process and identify any issues that might be present that could result in the compromise of pre-authorization data.
“Do we need a “clean room?””
From a PCI compliance perspective, the answer is ‘no’, although there are a number of PCI requirements that would lead you to restrict what is in the actual call center. However, best practice is to operate any call center handling potentially sensitive data in a ‘sterile’ environment. That means clean desks, no personal items at the workstation, no paper and pens for writing things down, locked down workstations and other restrictions so that sensitive information is not leaked from the call center.
The idea for creating a sterile environment by banning cell phones and giving personnel lockers to secure their personal items is in line with what we see in call centers. In addition, I think most call center organizations find that their clients require such approaches to ensure that their customers’ privacy and security is maintained.
In addition to all of the physical security, call center personnel need to be trained regarding security and privacy. Call center personnel need to sign an agreement that says they acknowledge that they will be in contact with cardholder data and that the cardholder data is to be protected in compliance with the PCI DSS and other regulatory and legal requirements.
“Is it necessary to segregate our team responsible for taking credit card information?”
The PCI DSS does not require credit card handling call center personnel to be segregated from other call center personnel. But again, best practice would be to put your credit card handling team together for a variety of other reasons. Another best practice is to segregate call center teams that handle sensitive data from personnel that do not handle sensitive data.
“The PCI standard 3.3 is not very clear on the subject in my opinion.”
“ … however, parts of the standard seem to me very unclear.”
The first thing people responsible for call centers should do is read the PCI SSC’s FAQ (#5362) on call center recordings and PCI compliance. The next thing they should do is read my postings on call center recordings.
- Call Center FAQ Significantly Changes
- Call Center FAQ Changes – AGAIN
- The Missing Link In Call Center Recordings
Requirement 3.3 of the PCI DSS is very clear in my opinion.
“Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).”
What I am sure is confusing are the caveats surrounding this requirement. The first caveat states that personnel with a business need to know can have access to the full primary account number (PAN). These personnel are typically accountants that work chargebacks and disputes, not call center personnel. In a call center environment, the system may display the PAN for customer confirmation purposes. However, once the PAN is submitted for authorization, the full PAN must no longer be available and must be masked to the first six digits and/or the last four digits.
The second caveat is that where legal or regulatory conditions apply, requirement 3.3 is superseded by any legal or regulatory conditions. The best example of this is that United States’ federal law mandates the last four digits of the PAN be displayed on a POS receipt. However, this second caveat should not impact any call center as they do not generate any documentation that would be regulated.
“I know that there are system requirements.”
Another area where call centers can be at risk is the call center workstation. The reason is that the workstation comes into contact with the cardholder data. Depending on how the workstation is used and configured, will determine the level of security surrounding the workstation.
The big move in call centers today is to use virtual workstations either through Citrix, VMware or similar solutions. In these situations, the workstation is just a display device. The server creating the virtual desktops needs to be physically and/or logically segregated from other virtual servers.
The threat to a physical workstation in any environment is that a keyboard logger is installed to record everything typed into the physical workstation. As a result, the physical workstation needs to have their system/event logs monitored and have anti-virus, anti-malware and critical file monitoring implemented.
Hopefully this answers a lot of the questions call centers have regarding PCI compliance.
PCI Guru 
Hey PCI Guru,
I have a question for you which is about segregation of CDE. In my call center agents receives clear credit card details(number, expiry cvv) over the encrypted web chat application , web chat application is managed by the client. Once agent receive the details they copy it on client internet website for the transaction and card details vanished on closing the chat box. Card details does not store anywhere on my network and agents do not have pasting rights anywhere on their systems except client website. My question is , do I need to segregate agents systems from rest of the network using firewall as agents handles card data on their systems.
Where segregation of CDE is necessary? As per my understanding if a system either process, store or transmit card details then it would come in the scope and need segregation from rest of the network as per PCI dss3.2
Note: I am going for SAQ-D assessment
What, if anything, have you done to ensure that the sensitive authentication data (SAD) is not residing in memory and that the Web chat application also is securely deleting it? If you have not assessed this, I would guess that you will find that the data is still in memory all over the place including your workstations and your clients’ servers that are involved. All of which will create PCI compliance headaches for all involved.
That said, I am assuming that the applications involved are all using HTTPS/TLS, IPSec or some other secure protocol to communicate which would be considered segregation as well as you have hosted-based firewalls with appropriate rules implemented.
Correct, Application are all TLS based and are hosted on client server resides on client data center that i am not responsible for. Client asked me to go for SAQ-D for my side of environment which comprises of call center agents workstations and network devices/internet firewall/proxy. Agents systems are all hardened with firewall, AV, Patches. Do i still need to segregate my agents workstations with network firewall in order to form CDE as agents workstation?
It is up to you. You know your environment and if more network segmentation would make you sleep better at night, then do it. But you are technically PCI compliant with the host-based firewall, and using HTTPS as well as all of the hardening.
Hello PCI guru,
By reading the last PCI DSS requirements I understand that if I want to outsource a call centre out of a PCI environment the external call centre must be PCI certified as well, is that correct? i.e. I have a call centre in-house that is PCI certified, but for costs considerations or time differences I would like to outsource the service. Agents in the outsource call center would connect to my company’s databases via a Citrix portal through a VPN, and they would be in a segregated physical area. Are these measures enough or must the call centre be also PCI certified? Thanks in advance.
When you outsource, the organization you outsource to must also be PCI assessed and validated using the service provider version of the PCI DSS. You must then obtain a copy of their service provider Attestation of Compliance (AOC) for the services they provide to your organization.
Thank you very much for your quick reply! It’s tricky to outsource PCI call centres as there are not much PCI certified ones. And it’s trickier to make understand this to the business as they usually call me “business stopper”. But the risks are high, that’s why PCI is intended to. And when I mention risks there are not many risks owners in the business…
Thanks again for your reply.
Guillermo.
Hi,
I have a question about call center agents that wish to work from home. I understand that the agent’s laptop would fall under scope for PCI. If the application that the agents use to enter in customer’s card holder data is hosted on on a HTTPS site, does the agent’s home router and/or switch that they plug their laptop into also fall under PCI scope? It would seem that employee’s home networking equipment would be impossible to maintain under PCI scope (and wouldn’t allow for segmentation of non-PCI scope equipment) so it would require costly, managed equipment provided by the employer that could enable segmentation. Thank you!
It all comes down to your organization’s acceptance of risk. I have some clients that require all home agents to be on equipment supplied by the organization so that they know it is secured and kept current. I have other clients that accept the risk and only provide a hardened notebook and assume that using HTTPS provides enough security. But add in VoIP and softphone technology and I tend to fall into the ‘you need to manage everything’ bucket to be truly secure.
But my understanding is that “acceptance of risk” is not a viable method to not apply controls in a home users case.
Example:
“PCI DSS requirements apply to all system components, unless it is has been verified that a particular requirement is not applicable for a particular system. Decisions about the applicability of PCI DSS requirements are not to be based on an entity’s perception of the risk of not implementing the requirement. Organizations may not choose which PCI DSS requirements they want to implement, and risk assessments cannot be used as a means of avoiding or bypassing applicable PCI DSS requirements.”
– Snipped from Article Number 1252 on the council FAQ website.
The concept of “acceptance of risk” is not a unilateral one. You have to get the agreement of your acquiring bank or even the card brands if you’re big enough. If you get that concurrence in writing from the bank/brands, then you can use that. This was how Linux without AV was dealt with before the Council modified requirement 5.1.
Hi pciguru,
Regarding call centers, if operators receive inbound calls and introduce cardholder data in a payment gateway (using a secure protocol) they use their workstations to transmit card data (pre-authorization data). I assume that these workstations must be properly configured and hardened (updates, anti-virus, FIM, …) but do you think that in this situation internal scans on these machines are required? And using the same thread, do you think that workstations used by administrators of security servers must be scanned (I mean in internal quarterly scans)?
Sounds like the workstations and administrative stations are in-scope, so yes, they need to be scanned quarterly under the standard. They also need to be annually penetration tested as well.
Regarding this, why SAQ C-VT, which describes the situation exposed before, doesn´t require anything about the requirement 11? I think that this is a big problem of the standard. There is a lack of baselines in relation to certain aspects like these. The assessors need a more accurated criteria of the council for these questions to maintain consistency between assessments. Usually, this affects the customers due to the changing criteria followed by every assessor (according to his own view and experience)
C-VT makes a huge assumption that the PCs accessing the virtual environment are patched current and are properly protected from getting a keyboard logger or memory scraper. That is not always the case, but that is what it assumes.
Hi PCIGuru,
We have a Tech Support team in a dedicated Call Center facility which now has the need to process credit card payments for an RMA service using a third-party, internet based payment gateway (accessed via a web browser using an individual user login and password). We do not store any credit card info in our environment – once the payment is processed, we only see a token on the payment gateway website for each transaction. Each Tech Support team member has their own, company issued PC that is connected to our internal company network to access email, SAP and other systems to do their job (log cases, process RMA’s and assist customers with technical issues) – all of which requires a Windows login to get into the computer itself as well as a separate login/pw to our internal network.
What controls do we need to have in place to be PCI compliant and still allow Tech Support to take a credit card over the phone and manually enter it into the third-party’s payment gateway on our company-issued PC’s?
Thanks!
I’m assuming that the third party’s payment page is secured through TLS (aka HTTPS). If that is the case, the PCs used need to be appropriately hardened, regularly patched, have anti-virus/anti-malware and are periodically monitored to ensure they remain secure (aka Security 101).
To follow on the above example we have the same situation, but we are using a in-house developed payment terminal (in the CDE). Using the Open PCI DSS Scoping ToolkitFor scoping purposes, we consider the workstations (not in the CDE) that the reps use level 1a because they enter/process the credit card information. Once processed, we do not store credit card data, only the token. What we are currently struggling with is because the reps can use their workstations to connect to other network resources (examples similar to above – email, Salesforce, other non-PCI (level 3) applications, etc) how do we prevent those currently out of scope devices from becoming in-scope (2c – systems that through controlled access receive an initiated connection from a Category 1 device). It seems like this brings most of our environment in-scope and defeats the attempt to limit scope by creating the CDE in the first place.
Thanks for your help!
It depends on whether or not your organization is will to accept that risk. Most organizations do not so they segment their call center systems from the rest of the network.
Ok. I get call recordings and the storage. But the transmission is still unclear. More and more call centers have remote agents working from home. A call comes into them via a typical analog landline or perhaps the agent is using VOIP from a service provider like Comcast or Vonage. A customer speaks their PAN and CVV. We have had our security team state these agents must use analog landlines as VOIP is generally not encrypted over the public telephone network. What you say?
VoIP is a pain, but can be encrypted and that is what the call centers I work with are doing to secure it for remote operators. The remote operators are required to use a soft phone on a computer/terminal supplied by the call center, no personal gear allowed. They connect over an SSL or IPSec VPN to the call center’s network and then can send and receive calls. They are monitored like any other operator but are not allowed to operate as a remote operator until they have been “certified” by the call center to work remotely. That certification process can include working for a year or more as well as specialized training.
How do you deal with Requirement 9 for those remote workers that are involved in taking payments over that soft phone?
You accept the risks that they present by minimizing the risks that they present. Sometimes that means create one or more compensating controls to make that work.
hi PCIGuru..
I just want to know since i am new to this PCI, what about the layout of office needed when complying with PCI. For example, do we need a isolated room or separated room to place the card swiper so there will be no leakage? another thing, when the organization changing their building or migrated to new places, what need to be complied by the organization?
thank you for your time..
You need to ensure the physical security of the point of interaction (POI) or card terminal
Properly configured, a POI should never “leak” card information because it does not store it. But that is the operative phrase, “properly configured”. I have encountered units from very reputable firms that need to be configured by the merchant so that the POI does not store cardholder data.
There are people that swap out POI for a tampered with POI, so you should make sure that it cannot be changed out without someone’s approval and knowledge. This is why some merchants lock their POI down in a cradle. That may or may not always be possible. I have some clients that keep their POI in a locked drawer and only bring it out when needed.
The bottom line is to use your best judgement and protect your POI as best you can based on your situation.
Thanks PCIGuru for answering my question.
Another thing, sorry for asking more questions. It just that I dont really get understand, if we change our building, the rules is still the same right? We just need to ensure the safety of our POI, right? There is no such rules applied right?
Thank you again.
You need to protect the point of interface (POI) regardless of how you configure your facility. If the POI is public facing as with a grocery, pharmacy or gas station, then you will likely have much more security than if you are using the POI in a mail order/telephone order (MOTO) situation where the public is not involved.
Regardless, there will be some amount of security in any location to minimize the potential of POI tampering.
Ok, thank you PCIGuru for assisting me.
PCIGURU, thanks. One other question…you mentioned the risk of malware, but what about the concern of Data Leakage with a more lenient Internet outbound policy? An example would be cardholder data potentially could be posted to a blog
No doubt about it. If an organization has outbound network traffic policies that allows access to just about anything on the Internet, it will not stop much of anything.
Good info. Got a question as it pertains to Call Center staff members outbound access to the Internet and 1.2.1 – Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment. What is best practice? Should they be completely restricted to job function web sites and services only, or can they at least browse news, research, educational sites?
Most call centers restrict operator access to only those sites that are necessary for their job function. If you wish to provide access to news, research and education sites, that is up to your organization to establish that as your policy. However, you then increase the risk that your operator workstations could be infected by malware, so you might then want to consider using a file monitoring program to enhance your anti-virus solution to mitigate the risk.
You are mentioning that the threat to a physical workstation is a key logger, but is it not also a threat to a ‘virtual’ workstation??
Yes, a keyboard logger is a threat to the virtual workstation as well. The FIM and other controls on the virtual workstation can flag that issue and take the virtual workstation image out of service until the problem is addressed. That way the physical workstation can meet a reduced set of controls such as anti-virus, basic security hardening and current patching.
It is imperative that the vendor has to properly inform and educate the call center agents about the importance of how to properly handle cardholder data. It is sensitive information and they wouldn’t want other people to handle their data in a haphazard way. This is another thing that vendors have to do to make sure that such information is kept as secure as possible.
Training of call center employees is a given and is covered in the requirements under 12.6. However that is the responsibility of the call center employer, not a vendor.
Vendor security of call center equipment such as the call manager and call center applications is another story. With the advent of voice over IP (VoIP), call managers are just another server with the PABX applications running. Unfortunately, like cell phones and other embedded devices, once a vendor moves on to the next generation, the older PABX solutions are left by the wayside never to be upgraded. Given that most organizations desire 10+ years out of a PABX like they used to get, this means that there are a lot of organizations running older VoIP call managers that are very vulnerable to attack.