White paper How to take your contact centre out of scope for PCI DSS
Executive summary With 77 per cent of UK companies admitting to a security breach (Source: The Ponemon Institute, 2009), and up to 97 per cent of companies falling short of PCI compliance, call centre security looms large on the boardroom agenda. 77% of companies admit to a security breach and up to 97% fall short of PCI compliance. Increasingly however, merchants are finding that eliminating customer card data from their infrastructure means they can reduce the scope of PCI DSS. By doing so, they can reduce the risk of a breach of card data and cut the cost of PCI DSS compliance. The two principal approaches to reduce cost, complexity and the PCI DSS audit scope for cardholder data are: 1. Tokenization 2. Point-to-point encryption These emerging technologies are established for both high street and online retail channels but the contact centre and voice transactions still present additional challenges. Semafone has incorporated these technologies into a unique solution to tackle both fraud risk and PCI compliance by ensuring that no payment information is heard by the agent, or stored by the company. June 2011 2
Reducing the scope of the PCI audit can drive down costs by more than 75%. Contents Executive summary 2 Contents 3 PCI DSS background and audit scope 4 Two ways to eliminate the need for customer card data 5 The challenge for the contact centre 6 How Semafone removes card data from the contact centre 7 Reducing the scope of PCI DSS audits for the contact centre 8 Cutting the cost of PCI audits 10 Conclusion and glossary 11 June 2011 3
Introduction: PCI DSS background The Payment Card Industry Data Security Standard (PCI DSS) is the card schemes compliance programme to combat fraud and protect consumer card data. It applies to all organisations that store, process or transmit cardholder information, from any of its members cards (Visa, MasterCard, American Express, Discover and JCB). Level 1 retailers spend an average of 1.8m to become PCI compliant. Source: Gartner Larger organizations must have their annual compliance assessment carried out by an independent Qualified Security Assessor (QSA), while smaller companies can use a Self- Assessment Questionnaire (SAQ). The current version of the standard (v2.0 since March 2011*) specifies 12 requirements organized into six control objectives. From July 2012 MasterCard says that Level 2 merchants either have to have their SAQ completed by an external QSA or they need an Internal Security Assessor (ISA) with PCI DSS training to sign off their SAQ. Control objectives Build and maintain Protect cardholder data Maintain a vulnerability management program Use strong access controls Regularly monitor and test networks Maintain an information security policy PCI DSS requirements 1. Install and maintain a firewall to protect cardholder data 2. Do not use vendor-supplied defaults for passwords and other security parameters 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks 5. Use up-to-date anti-virus software on all systems commonly affected by malware 6. Develop and maintain secure systems and applications 7. Need-to-know access to cardholder data 8. Give a unique ID to each person with computer access 9. Restrict physical access to cardholder data 10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes 12. Maintain a business-wide policy that addresses information security * https://www.pcisecuritystandards.org/documents/protecting_telephone-based_payment_card_data.pdf June 2011 4
PCI DSS audit scope PCI DSS has five types of SAQ to be completed. The table shows how different types of SAQ require less controls and can therefore cut the cost of PCI DSS compliance. Each type of SAQ offers a different number of required PCI controls and the costs that go with them. SAQ A Description Card-not-present (e-commerce or mail/telephone order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants. No. of controls 4 B Imprint-only merchants with no electronic cardholder data storage, or standalone, dial-out terminal merchants with no electronic cardholder data storage. 29 C-VT Merchants using only web-based virtual terminals, no electronic cardholder data storage. 60 C Merchants with payment application systems connected to the internet, no electronic cardholder data storage. 80 D All other merchants not included in descriptions for SAQ types A- C above and all service providers defined by a payment brand as eligible to complete an SAQ. 286 June 2011 5
Eliminating customer card data from their infrastructure lets merchants cut the cost of PCI DSS compliance. Two ways to eliminate the need for customer card data PCI DSS requires that merchants must eliminate, render useless, substitute or secure (encrypted to the standards of PCI DSS) all cardholder data. It is rare that cardholder data can be totally eliminated as it is required for refunds, future purchases, loyalty programmes, reconciliation, etc. Therefore, merchants focus on substituting their stored card data or rendering it useless. This is already happening on the high street and online through point-to-point encryption and/or tokenization. Account Data Storage Render Stored Account Data Element permitted Data Unreadale per Req. 3.4 Cardholder Primary Account Yes Yes Data Number (PAN) Cardholder name Yes No x Service Code Yes No x Expiration Date Yes No x Sensitive Full Magnetic Stripe Data No x Cannot store per Req. 3.2 Authentication CAV2/CVC2/ No x Cannot store per Req. 3.2 Data CVV2/CID PIN/PIN block No x Cannot store per Req. 3.2 Figure 1 PCI DSS Applicability Information v2.0 1. Point-to-point encryption Point-to-point encryption can be used to protect and secure cardholder data between two end points. Visa Europe in March 2010 issued a Best Practices for Data Field Encryption with these goals*: 1. Limit cleartext availability of cardholder data and sensitive authentication data to the point of encryption and the point of decryption 2. Use robust key management solutions consistent with international and/or regional standards 3. Use key-lengths and cryptographic algorithms consistent with international and/or regional standards 4. Protect devices used to perform cryptographic operations against physical/logical compromises 5 Use an alternate account or transaction identifier for business processes that require the primary account number to be utilised after authorisation, such as processing of recurring payments, customer loyalty programmes or fraud management 2. Tokenization Tokenization can replace cardholder data, ie the credit or debit card number, with nonsensitive data that can be used as a reference or a token. The card data is then vaulted, usually by a third party, where again it is protected through encryption. Format-preserving encryption and tokenization Encryption and tokenization can both be used, so that the encrypted value or the token retains the format of the original card number. It is also possible to retain the first six digits (the Banking Identification Number BIN which identifies the issuing bank) and the last four digits which do not need to be masked for PCI DSS, so they can be used by production applications and viewed by users. * Visa Europe s Best Practices for Data Field Encryption, Version 1.0 June 2011 6
http://www.visaeurope.com/en/businesses retailers/payment_security/downloads resources.aspx The challenge for the contact centre Technology and services for the de-scoping of high street and online retailers are already well established, with chip and PIN machines where the customer is present, and payment pages hosted by the merchant s Payment Service Provider (PSP) for online transactions. The contact centre has its own specific challenges for PCI DSS compliance. However, the contact centre has its own distinctive issues, with three specific challenges to address for PCI DSS compliance: The physical contact centre environment Call recordings Agents and network Securing the physical contact centre environment PCI DSS requires that employees are screened for security purposes. But if paper and pens are available then other controls come into play. So any writing paper needs to be secured and later destroyed so cardholder data can not be reconstructed. Many contact centres have adopted paperless environments with only white boards and markers available. Agents access to cardholder data also means that PCI DSS requires a policy covering access to mobile phones, the web and email, as staff could theoretically use these tools to transmit cardholder data out of the merchant s environment. Draconian measures such as banning pens, paper, mobile phones, personal effects, email access and web access can have very negative impacts on the contact centre. It can make it harder to retain staff and those who do stay resent being treated as potential thieves, making it very difficult to create a positive work environment. No email and web access within a contact centre is also impractical as these are required to fulfil day to day activities. Call recordings Customers share both cardholder data and Sensitive Authentication Data (SAD) ie the PAN (Permanent Account Number), expiry date, issue number and their security code (CVC, CVC2, etc). If merchants don t take the security code then the call recordings can be protected through encryption. PCI DSS does not permit capturing the security code on call recordings even if the recordings are encrypted. Barclaycard s white paper, Safe and Sound Processing Telephone Payment Securely, details the challenges of the contact centre*. Agents and network The fact that contact centre agents generally input customers cardholder data on their behalf brings the contact centre agent desktop into scope for PCI DSS, as the machine is being used to enter this cardholder data. Also, as the contact centre desktop is connected to the merchant s network, this immediately brings the merchant s network into scope. * Barclaycard Safe and Sound white paper http://www.barclaycard.co.uk/business/documents/pdfs/processing_telephone_payments.pdf June 2011 7
Removing cardholder data from the contact centre Semafone is a contact centre solution that shields all PAN and CVC data from agents, call recordings and screen recordings. Agents do not hear or see cardholder data, call recordings do not capture either the PAN or CVC, and screen recordings only capture asterisks and the last four digits of the PAN. The agent will only see asterisks on the Semafone hosted web page as the cardholder enters their card data. Agents do not ask cardholders to speak their card details, they ask them to use their telephone keypad to enter their PAN and CVC. Semafone masks the DTMF (Dual Tone Multi-Frequency) tones from the cardholder s telephone and replaces them with a flat tone. This is achieved while voice communications remain intact between the agent and the cardholder. The agent can then call up Semafone s enable payment page for the merchant s preferred Payment Service Provider (PSP), passing across the cardholder name, transaction reference, amount and any other payment details required for authorization (such as cardholder address). The agent will only see asterisks on the Semafone hosted web page as the cardholder enters their card data but other than the last four digits, no other digits of the PAN and CVC are transmitted to the page. The agent then verbally collects further payment details such as valid from, valid to and issue number and enters these details into Semafone s payment page. If the cardholder makes a mistake, they can tell the agent who will then reset the PAN or CVC field from a button on the hosted web page, or simply press the star button on their phone. From the first six digits of the PAN (the BIN) Semafone can determine the length of the PAN. Once the last digit of PAN has been entered by the cardholder the agent receives an audio prompt and a visual cue in terms of the last four digits of the PAN being displayed on the Semafone hosted web page. Semafone performs a Luhn digit check (an algorithm that validates the card number) and if this fails Semafone shows the agent a message indicating an invalid card number has been entered. The agent is then able to ask the cardholder to re-enter their card details. Once the transaction details have been collected, the agent can request the transaction authorization. Semafone combines the details from its hosted payment page with the PAN and CVC it has collected from the cardholder s DTMF tones. Semafone then securely transmits these transaction details to the merchant s PSP through the PSP s Application Programming Interface (API) service. The PSP returns to Semafone the results of the authorization including the authorization code and the transaction token. These can be displayed by the Semafone hosted page or can be posted back to the agent application. June 2011 8
Removing card data from call recordings Call recordings are an essential part of the modern contact centre, and mandated by the FSA for mortgage companies when handling collections over the phone. They re also required for dealing with complaints and managers may use them for training and instruction purposes. It is impossible to reverse engineer any card data from the call recording, putting it safely outside PCI DSS scope. However, it is important that customers credit card data is not retained in the recordings. Semafone copes with this requirement by automatically removing the card data from the recordings as they happen. The call recording will capture all voice communications but DTMF tones are masked and only a flat tone is recorded. It is therefore impossible to reverse engineer any card data from the call recording and Semafone has put the call safely outside PCI DSS scope. The Semafone approach has several advantages over the alternative approach of pausing recordings: 1. Pausing call recordings is often in conflict with regulatory bodies that mandate complete recordings 2. Triggering pause and resume by hand is not a robust system, with human error resulting in either the capture of card details on the call recording (and thus the loss of PCI DSS compliance) or the missing of important sections of the call, which is causing major issues for quality monitoring and business improvement June 2011 9
Reducing the scope of PCI DSS audits for the contact centre Semafone in the cloud By capturing card data (PAN and CVC), Semafone is technically in scope for PCI DSS. However, Semafone can be deployed within the telephony cloud of the merchant s network provider rather than the enterprise itself. The merchant will be deemed to have outsourced their payment process for PCI DSS purposes, as it will not have handled any cardholder data. While the telephone network provider will have to be PCI DSS certified, the merchant will be deemed to have outsourced its payment process for PCI DSS purposes, as it will not have handled any cardholder data. In this case, if they have no customer facing card transactions they can complete an SAQ A form and attest to two statements ( Restrict physical access to cardholder data and Maintain a policy that addresses information security ), leaving just four controls to implement for PCI DSS. If the merchant has no customer-facing transactions, they can complete an SAQ C attesting to 80 controls, automatically cutting out 206 controls from SAQ D. Voice DTMF PVG PSTN C82 WWW Provider Edge Network DMZ LAN Firewall SIP or TDM connection DPM Server SBC/CCM Telco Data Centre DMZ Payment Gateway Firewall PBX/ACD Customer Site Out of Scope Voice LAN Agents CRM June 2011 10
Figure 2 Semafone deployed within a telephony cloud Level 1 merchants gain Level 1 merchants need to have a QSA complete their Report on Compliance (ROC) with the full 286 controls within SAQ D. But if the merchant qualifies for SAQ C with the permission of their acquirer the amount of controls is reduced to just 80. Semafone in the enterprise Where a merchant does not deploy Semafone within their telephony network provider, but within their enterprise itself, it is still possible to limit the scope of PCI DSS. The Semafone telephony cards and servers can be segregated by firewalls, so the network outside the firewall will be de-scoped. Importantly, this will include the contact centre environment, including the agents desktops. The merchant will still need to complete an SAQ C for the Semafone environment but will not need these controls outside of the segregated area. As agents do not hear or see card data there is no requirement to secure the physical contact centre environment. So agents can have web access, email access, mobile phones and the use of paper and pens at their desks. This helps to create a more productive environment and ensure higher The story can be even better for Level 1 merchants that qualify for SAQ A (a growing list, including utilities such as gas, electric, water, phone, cable, satellite TV, and ecommerce businesses such as Amazon, ebay, LastMinute.com and Expedia). Qualifying for SAQ A means that with their acquirer s consent they can report Not Applicable to 282 of the 286 controls, leaving just 4 within scope. Voice DTMF PSTN Payment Gateway Firewall WWW As agents do not hear or see card data there is no requirement under PCI DSS to secure the physical contact centre environment. PBX/ACD PCI Chassis On-Site DMZ Voice TPM/DPM Server Firewall Agents LAN CRM Customer Site Out of Scope rates of staff retention. June 2011 11
Figure 3 Semafone deployed within the merchant s enterprise By removing the need to handle customer card data, merchants can significantly reduce the costs of implementing and maintaining PCI DSS compliance. Cutting the cost of PCI audits IT research firm Gartner reported in 2008 that merchant spending to protect cardholder data and become PCI compliant increased by almost five times during the previous 18 months. Among the Level 1 retailers (more than 6 million transactions per year) Gartner surveyed, an average of 1.8 million was spent to become PCI compliant, excluding the costs of PCI assessment services. Level 2 merchants (1-6 million transactions per year) spent 730,000 on PCI compliance and Level 3 merchants (20,000-1 million transactions per year) spent an average of 103,000, excluding security assessment. Gartner did not discuss Level 4 merchants in the report. The Ponemon Institute reported in March 2010 that Tier 1 merchants are spending 150,000 for their annual PCI DSS audits. Ten per cent of these merchants were spending more than 330,000. The rising cost of compliance Auditing costs for Level 2 merchants are set to rise significantly from this year with the announcement that from June 2011 MasterCard will require that all Level 2 merchants must either have an external audit through a qualified QSA or that their internal auditors have attended and passed the PCI Internal Security Assessor (ISA) training. By removing the need to handle customer card data, merchants can significantly reduce the costs of implementing and maintaining PCI DSS compliance. Large enterprises can pay over 150,000 for logging tools, for example, a sum that can be cut if the need for such tools is outsourced. Maintaining all of the latest security patches can also be a significant drain on compliance budgets, especially if they need to be applied to each agent s desktop, with the individual testing that requires. Reducing PCI audit scope cuts costs Reducing PCI scope from SAQ D to SAQ C can drive down PCI compliance and audit costs by more than 75 per cent. For merchants with no customer-facing transactions that can de-scope to SAQ A, the reduction is closer to 90 per cent. Reducing the size of a merchant s card data environment also significantly reduces the cost of achieving and maintaining PCI DSS compliance. In a recent series of estimates carried out by Semafone, the annual cost per agent seat can range from 11,324 for a small ten-agent contact centre with only anti-virus tools in place, dropping to a Semafone-enabled SAQ A rating at a cost of 2,282, saving more than 75 per cent per year. In larger contact centres with greater economies of scale, costs can drop from 1,213 to just 140, a saving of almost 90 per cent. June 2011 12
Conclusion PCI DSS compliance is continual and not just an annual audit. Merchants need to set longterm objectives to reduce their risks from cardholder data and to measure the ongoing cost of doing so. Glossary API Application Programming Interface CVC Card Verification Code DTMF Dual Tone Multi-Frequency PAN Permanent Account Number PCI DSS Payment Card Industry Data Security Standard PIN Personal Identification Number PSP Payment Service Provider For most organisations this will be to avoid managing cardholder data. The ability to achieve this on the high street and online has been well understood for some time but this has left the Achilles heel within the contact centre. Semafone is the only company that allows merchants to close the gap in their de-scoping strategy by allowing them to remove their contact centres from PCI DSS compliance. Semafone can reduce costs, ease the admin burden and contribute to a more productive working environment for staff, helping merchants to finally realise the cost savings that they want to achieve. Advantages of Semafone for contact centres Significantly reduced costs for PCI DSS compliance Zero negative impact on staff working conditions Enhanced security for customers ROC Report on Compliance SAD Sensitive Authentication Data SAQ Self-Assessment Questionnaire QSA Qualified Security Assessor June 2011 13