How to Secure Contact Center Phone Payments

Transcription

1 How to Secure Contact Center Phone Payments Strategies being used to reduce fraud risk and the scope of PCI DSS compliance within Contact Centers But which ones work? Click: Call: Visit:

2 FACT: CNP Fraud is Rising - Fast! Payment fraud is a like a giant balloon - you squeeze one end and the other end gets bigger. This is the same way criminals work - the law clamps down on one method of fraud (e.g. the introduction of EMV/chip and pin) and the criminals just move on to less secure environments. Card Not Present (CNP) transactions (ecommerce, mail order and phone payments) are more vulnerable to fraud than face-to-face transactions. The speed of mass fraud through computers, phone and mobile phones occurs on a global scale at a frightening rate. The question that's difficult to answer for CNP fraud is 'who' is in possession of the card details at the point of transaction? As criminals focus more on CNP transactions, contact centers can no longer keep their heads in the sand. 66% of card fraud in the Single Euro Payments Area is now associated with CNP transactions. Card Fraud Report European Central Bank, 2015 Page 01

3 What's The Risk? As the person in charge of customer experience, compliance or data protection, your day-to-day remit may include meeting Payment Card Industry Data Security Standards (PCI DSS), or preventing data breaches, since your organization takes card-notpresent payments. This is a BIG responsibility! The average organizational cost of a card data breach has increased globally by 23% since 2013 now standing at $6.53 million in the US, and 3.72 million in the UK*. The most damage done to the bottom line in the event of a data breach, is through loss of reputation and customer loyalty. In the aftermath of a breach, companies find that they have to spend heavily to regain brand image and new customers. So, where exactly does the contact center come into all this? *IBM and Ponemon 2015 Cost of Data Breach Study: Global Analysis Page 02

4 Protecting Cardholder Data - Why does it Matter to Your Contact Center? The telephone is a notoriously difficult payment channel to secure! If the caller has to read their card data out loud to a call center agent who manually inputs that data to their systems, companies have to take expensive and complex measures to prevent card details being recorded. But there s still the risk that a rogue agent could simply copy the numbers down. In addition, card details are entered into the agent desktop and flow through the company systems. This puts this data at risk and within PCI DSS scope. So it's little wonder that Customer Service, IT and Compliance managers are left scratching their heads deciding how to best tackle these risks. Saks & Company - Sept 2014 Small scale high consequence breach 1 employee Stole 22 card numbers $400,000 fraudulent purchases Security breach hit the headlines Huge reputational damage to Saks Page 03

5 How Are Organizations Tackling It? Many contact center organizations are changing their approach to how they deal with customer information coming in through their agents. 93% of contact centers announced that they either had a PCI DSS Compliance programme underway or are planning one. The remaining 7% admitted they were not compliant but had methods in place to increase the level of security around customer data. Some contact centers are using robust technological methods, while others are trying to sort it out themselves by making adjustments to their internal processes. A small majority are still under the illusion that they will never be breached. Let's look at some of these approaches in more detail... Page 04

6 #1 Segmenting: Payment Zones & Clean Rooms 42% of contact centers separate their payment processes. This includes creating clean room environments or segregating credit card handlers from other agents. These processes are generally good practice but are still problematic. Call recordings (if no pause and resume is in place, see P.6) and data collected on PCs and networks are still exposed, so segmenting in isolation doesn't adequately address the full PCI DSS requirement scale. Some contact centers transfer calls from one agent to an automated secure IVR, or an unrecorded extension where a second agent takes the customer s payment card details. These methods are used extensively but are still open to human error. Passing the customer onto another stage in the process can be frustrating for the customer, and both Average Handling Time and customer experience are impacted. The IVR is particularly bad for customer experience, because if the customer makes a mistake with their payment, they need to call back through the contact center to repeat the process. In addition, from an agent perspective, applying such restrictive working practices can be counterproductive and demotivating - which only increases costs through high staff turnover. Page 05

7 #2 Pause & Resume: Manual and Automated Pause and Resume methods only address call recording security. The rest of the contact center is still in scope of PCI DSS compliance. Manual pause and resume methods, which put all the security responsibility into the hands of the agents, have been deemed inadequate by the PCI SSC which advises companies to implement methods that require no manual intervention by staff. Automated Pause and Resume techniques automatically 'stop and start' a recording based on the screen the agent is using. However, even the most complex system is not completely seamless. For instance: it could impede fraud or quality monitoring investigations as the recordings miss valuable content the agents desktops and network are still in scope for PCI compliance it's extremely difficult to achieve 100% automation of pause and resume once the Pause and Resume system is in place, upgrades to telephony or IT systems pose a large challenge Page 06

8 #3 DTMF Blocking/Masking With Dual Tone Manual Frequency (DTMF) blocking/masking methods, the customer uses their telephone keypad to enter their card details when prompted by an agent. The card details never enter the contact center environment and the agent cannot see or hear the card numbers. This method is most commonly used to take the entire contact center (networks, systems, telephony, etc.) out of scope, including home-based and remote agents. From a customer experience perspective, these systems meet the challenge of maintaining 100% agent/customer interaction. To meet the complex PCI DSS requirements, more contact centers are turning to DTMF tone blocking/masking technology to remove all or parts of the contact center entirely from audit scope and reduce both the effort and cost of compliance. And if there is a breach, either no data is present or the card data will have major portions missing. The data will be useless to hackers, and the actual card data will remain uncompromised. Page 07

9 #4 Audio Tokenization: De-Valuing Card Data Audio Tokenization is not to be confused with the tokenization systems commonly used by Payment Service Providers (PSP). PSPs send a 'token' (a substitute for the real card numbers) to the merchant after the initial payment which is then used for future purchases. Before this happens, the card number has to first go through the merchant environment before the PSP processes it. Audio Tokenization secures this first part of the payment, and keeps the real card data out of the organization. The customer enters their card details using their handset. The DTMF tones are then tokenized before entering the contact center environment and restored prior to the PSP receiving the data to authorize payment. For merchants that do not use PSP tokenization, audio tokenization also works for every card payment taken. Many organisations are choosing tokenization over encryption because no card data is present. With encryption, the card data is present (and therefore at risk), but is more difficult to access than actual card data. Encryption places a significant level of PCI audit requirements on the merchant that aren t needed with tokenization. There is also one distinct advantage of Audio Tokenization compared to other methods - it doesn't need any integration or changes to existing systems or processes. Page 08

10 #5 Denial: "Fraud Won't Happen to Us!" Unbelievably, some contact centers only use basic security as their main fraud deterrent, using manual processes and training to ensure correct handling of payment information. These contact centers also rely heavily on firewalls and other security related equipment to prevent breaches to systems and use encryption software for areas that store customers information. Although these are good practice measures and form part of basic systems security, they are certainly not fail-safe and often span generic systems without any specific focus on one department s activity or processes. When breached, it often spells financial and reputational disaster for the organization involved. In their 2014 report, Verizon found that over the last ten years of investigations, 100% of companies were not compliant at the time of the breach. This emphasizes the importance removing the payment channels and processes from PCI scope, so even if you are breached, there is nothing to lose. Page 09

11 What Strategy Should We Take? Whatever direction you choose, bear in mind that the PCI Security Standards Council's main objective is to see card data secured. Going it alone can often mean costly infrastructure rebuilds, and any segmentation method is prone to human error or data leaks. DTMF blocking/masking and Audio Tokenization methods are the most effective ways to secure your contact center for PCI DSS compliance and reduce fraud risk. These are managed services offered by PCI DSS level one service providers and have significant cost, resource, operational and security benefits. Five reasons these methods are popular are: 1. They require minimal or no integration with existing system or processes 2. At a minimum, they de-scope agents, screens and call recordings from PCI DSS 3. When fully deployed, they can take the entire contact center out of scope, keeping card data out 4. They reduce the risk and impact of a breach 5. Reduces the immediate cost and effort for compliance Page 10

12 Still Undecided? As a PCI DSS Level One accredited Service Provider since 2010, Eckoh has gone through the pain of achieving the Standard every year. We'd be happy to share our experience and how we have helped almost 50 contact centers achieve their PCI DSS and data security goals. Our clients would most likely agree that our CallGuard solution is the most flexible on the market. No matter how complex their infrastructure is, or how little or how much they want to descope their contact center for PCI DSS, we have provided a version of CallGuard that fits their needs perfectly. And the best part is, it has lifted a huge fraud risk and tricky compliance area off their shoulders. Page 11

13 About Eckoh If you would like some impartial advice or no-obligation information, just drop us a line or give us a call. Our PCI DSS compliant secure payment suite, Haloh protects payments made over the phone or web: CallGuard - Secures payments made over the phone using DTMF masking or Audio Tokenization, on a premised or hosted basis EckohPAY - automated IVR, web or mobile card payments DataGuard - Secure your web or mobile app transactions Secure Payment Suite, by Contact us today to see how Eckoh could help your contact center move towards PCI DSS compliance. Click: tellmemoreus@eckoh.com Call: Visit: Eckoh plc. All rights reserved. You may not alter or remove any copyright, trademark or other notice from this document. This document and any data, materials, information and analysis contained herein may not be disclosed to or used by any other person or entity without the express prior written consent of Eckoh plc. Substantial effort went into verifying and validating the accuracy of the information contained within this document however, Eckoh plc disclaims all warranties as to the accuracy or completeness of this information. Eckoh plc shall not be liable for any errors or omissions in the information contained herein or for any losses or damages arising from use hereof. Page 12