Call centers that handle payment card information have a responsibility to protect their customers from data compromise and fraud. When we visit college campuses, there are two primary types of call centers we will include in our PCI assessments:
- Billing/Acceptance call centers in which the primary role is to collect payments
- Phonathon merchants with student callers reaching out for donations
If your call center staff is accepting payments over the telephone, verify you are taking the necessary steps to determine how the PCI DSS applies within each area. Below are some of the more common areas of non-compliance that our Security Advisors see in these environments:
Voice Over IP (VOIP) Phones – Due to the substantial cost savings and functionality of converting to VoIP from analog lines, or what is often referred to as POTS (plain old telephone service), strictly analog call centers are slowly fading away into the past. Unfortunately, IP-based voice traffic is as vulnerable to attack as any other type of Ethernet traffic, and should be treated in a similar way when it comes to security. If VoIP traffic is unencrypted, anyone with access to the network can easily sniff, or intercept, information and compromise cardholder data. Therefore, any VoIP traffic that contains cardholder data should be in scope for applicable PCI DSS controls. However, the configuration of your VOIP devices and network configuration both play key roles in determining what exactly falls into PCI scope. PCI DSS Requirement 4.1 states that organizations must use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open or public networks. If possible, any VoIP phones that may be used for accepting payment card information (or other sensitive information like PHI) should deploy some form of voice encryption (e.g. Secure Real-time Transport Protocol (SRTP), Transport Layer Security (TLS), etc.).
Are your VoIP phones utilizing software-based phones (e.g. Cisco IP Communicator, Microsoft Skype/Lync Client, etc.) or do you have an actual plastic instrument (i.e. “hard” phone) connected to the network? “Softphones” do create additional complications because even if voice encryption is used, the audio must be decrypted for you to be able to listen to the call. The device (PC) running the softphone client could be compromised, leading to the leakage of data.
Organizations should consider segmentation of the VoIP networks from their data networks. If your call center VOIP phones are setup so that the payment data is flowing over a separated / segmented voice network, then your level of effort to secure this network can be reduced. This subnet can be secured similarly to other segments in the organization’s CDE with all of the applicable controls from the PCI DSS, including restricting physical and logical access to all system components, system hardening, anti-virus protections, regular system patching, vulnerability scans, logging, file integrity monitoring, etc.
Call Recordings – If you are recording customer calls where payment data is being exchanged (and more specifically Secure Authentication Data (SAD) like the three digit CVV2 code), then you are now storing cardholder data electronically and all of the PCI DSS requirements must be accounted for. The DSS clearly states that SAD must be destroyed after authorization; additional guidance from the PCI Security Standards Council explains that this data must not be queriable, so additional controls may need to be put in place. Rather than taking on this expanded PCI scope and the work required to achieve and maintain PCI-compliance, it is best to avoid storing this data in the first place.
There are different technologies that can be implemented to assist with this effort, including automated pause and resume technology that recognizes when the staff member has entered the payment processing screen and pauses the recording. Once the transaction is complete, the recording resumes.
Alternatively, call centers can switch to a keypad payment-by-phone technology (commonly called an interactive voice response or IVR technology) that requires the customer to enter in their card details via the keypad on their phone, so the call center staff does not have access to the payment card details.
Inaccurately / incompletely Secured Workstations – This is clearly a concern across all departments, but call centers are one of the more common areas where staff are able to access the Internet, check e-mail, etc., while at the same time handling customer payments. Do your call center employees have access to your ticketing website, or to the Internet so they can check the weather? As you allow them to access different applications or web browsers, this will make the device more vulnerable to compromise and potentially non-compliant with the PCI DSS.
All workstations involved in handling payments must be locked down to provide access only to applications which are necessary for call center operations. There should never be any direct access between any network component storing, processing, or transmitting cardholder data and the Internet. Required PCI security controls must also be implemented (e.g. anti-virus, logging, firewalls, etc.). Implementing a PCI-listed Point to Point Encryption (P2PE) solution for payment processing can quickly eliminate the need for securing workstations.
Many call centers will also go the route of implementing a virtual desktop infrastructure (VDI) solution to simplify the management and maintenance of these workstations. In these situations, the workstation deployed at the desk is just a “display device” that runs a centrally managed, virtual machine delivered from your server. CampusGuard recommends that you either use a “zero client” for the workstation and deliver both secure and non-secure virtual desktops or deliver a non-secure virtual desktop to the secure host computer. The non-secure virtual desktop is how employees would access the Internet or other more vulnerable applications. Depending on configuration, the server hosting the virtual desktops may need to be segmented and properly secured in order to be considered a compliant solution.
Permissions Errors – Data that can be accessed, can be stolen, so limiting who has access to sensitive data keeps the potential for a breach down. Ensure all staff members only have the access to the information necessary to do their jobs. Implement clearly defined policies and procedures and require all staff members complete annual security and PCI-specific training. If your call center has remote employees, ensure they are using multi-factor authentication when accessing your payment applications and only using company approved (and secured) systems.
Shared Accounts – With high staff turnover and so many users accessing information, many times organizations will have shared accounts that multiple people are using. This is not a compliant security practice and makes it impossible to log and keep track of who has accessed sensitive information. Along those lines, make sure to utilize role-based logins and change passwords frequently (the PCI DSS requires passwords to be changed every 90 days).
Lack of Clearly-Defined Procedures – It is important to have well-documented procedures and ensure all staff have read and acknowledged the call center policies annually. Make sure you clearly outline activities you deem to be forbidden (e.g. taking notes on a scratch pad and writing down personally identifiable information when they are speaking to a customer on the phone). Having a clean desk policy and banning mobile devices is recommended to protect from any sensitive information being taken out of the call center by employees.
Displaying the Account Number – The Primary Account Number (PAN) may be initially displayed on the screen for customer confirmation purposes. However, once the payment is submitted for authorization, the PAN must no longer be visible and should be masked to show no more than the first six digits and the last four digits. This is not a common finding, but still a good idea to verify your call center is not running any outdated or legacy software systems that might not be masking the PAN appropriately.
If you have a call center on campus, you may want your PCI Team to pay them a visit, see how the operation is set up, and review their current procedures, so you can verify if additional controls are needed. As a side note, if you are outsourcing to a third-party call center for payment processing, make sure you are meeting all of the requirements of 12.8 and validating their compliance annually!
The PCI Council is planning to release an update to their supplemental guidance document discussing telephone-based payments as the previous version is a bit outdated (March 2011). We will be sure to keep you updated as that additional guidance becomes available.
Some additional guidance from our Security Advisor team below:
Ko: Remember the good ol’ days when having VOIP was just a change from POTS to VOIP and you maintained two discreet sets of network infrastructure, one for voice and one for data? Those carefree days without softphones, or VOIP mobility, and CDP spoofing are over. *sigh* We know that VOIP is here to stay and with all the nuanced ways that you can deploy VOIP in your environments, it’s now more important than ever to ensure that you’ve deployed your VOIP infrastructure in a manner that supports the PCI DSS requirements.
Using P2PE can greatly reduce the scope of things that need to be PCI compliant, but, if you’re receiving CHD using a VOIP softphone, the very nature of having unencrypted audio of CHD on your computer workstation may bring that workstation back in to PCI DSS scope. Carefully consider any upgrades that you plan on making, as only securing the payment processing side may still leave you with computers, networks, servers, etc., still in PCI DSS scope if IP softphones are still used.
VOIP is one of the dinosaurs designed using the “build-it-first-to-work-then-add-security-later” model, which, we all know, doesn’t make using it securely easy. This new guidance from the PCI Council should help add more clarity on what is expected for protecting CHD when using VOIP and especially for call centers.
However, even without the new guidance, implementing information security best-practices on securing IP traffic should still provide you with adequate controls to secure your VOIP deployment and be PCI compliant.
For additional questions regarding how to secure your call center and ensure PCI compliance, don’t hesitate to reach out to us.
