PCI DSS Compliance for Cloud-Based Contact Centers Mitigating Liability through the Standardization of Processes for cloud-based contact centers.

Transcription

1 PCI DSS Compliance for Cloud-Based Contact Centers Mitigating Liability through the Standardization of Processes for cloud-based contact centers. White Paper January

2 INTRODUCTION The PCI SSC (Payment Card Industry Security Standards Council) is the leading industry association promulgating robust and comprehensive standards to enhance payment card data security. The key compilation of their work is embodied within the PCI DSS (PCI Data Security Standard), which provides an actionable framework for prevention, detection and appropriate reaction to breaches in payment card security. This white paper briefly discusses the issues pertaining to PCI DSS compliance for Cloud based Contact Centers. PROBLEM It s a given that there are real civil and criminal liabilities associated with breaches in payment card security. Additionally, the credit card companies may impose fines up to $500K per incident of PCI DSS noncompliance. For those who conduct credit card transactions, the question that should be foremost in their mind, Is my Cloud Contact Center Environment Really PCI Compliant? PCI DSS Discussion There are two aspects of PCI compliance that must be thoroughly understood in order to help protect your Contact Center against liability: Scope and Process. Scope refers to boundaries of liability, and Process refers to security methods implemented within the boundaries in which your Contact Center operates. PCI SSC has developed a standard, PCI DSS that defines requirements for security. Its Scope is the whole environment of the Contact Center. The PCI DSS security requirements apply to all system components. In the context of PCI DSS, system components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. System components also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data. Network components include firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include the following: Web, Application Database Authentication Mail Proxy Network Time Protocol (NTP) Domain Name Server (DNS) Applications include all purchased and custom applications, including internal and external (for example, Internet) applications. 1 1 PCI DSS Requirements and Security Assessment Procedures, Version 2.0 2

3 Overview of PCI DSS Requirements 2 Build and Maintain a Secure Network Requirement 1: Install and maintain a firewall configuration to protect cardholder data Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters. Protect Cardholder Data Requirement 3: Protect stored cardholder data Requirement 4: Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program Requirement 5: Use and regularly update anti-virus software or programs Requirement 6: Develop and maintain secure systems and applications Implement Strong Access Control Measures Requirement 7: Restrict access to cardholder data by business need to know Requirement 8: Assign a unique ID to each person with computer access Requirement 9: Restrict physical access to cardholder data Regularly Monitor and Test Networks Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 11: Regularly test security systems and processes. Maintain an Information Security Policy Requirement 12: Maintain a policy that addresses information security for all personnel. PCI SSC has created an applications standard called PA-DSS (Payment Application-Data Security Standard). Its Scope is the software applications within the Contact Center. The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement, where these payment applications are sold, distributed, or licensed to third parties. 3 Overview of PA DSS Requirements 4 Do not Retain Data 1. Do not retain full magnetic stripe, card verification code or value Provide Protection for Data 2. Protect stored cardholder data 3. Provide secure authentication features Monitor Activity of those with Access to Data 4. Log payment application activity Employ Encryption and Other Methods to Protect Data 5. Develop secure payment applications 6. Protect wireless transmissions Regularly Test Applications and Review Design Security Criterion of Applications 7. Test payment applications to address vulnerabilities 8. Facilitate secure network implementation 2 Ibid Excerpted 3 PCI PA DSS Requirements and Security Assessment Procedures, v2.0 4 Ibid Excerpted 3

4 Isolate Cardholder Data 9. Cardholder data must never be stored on a server connected to the Internet 10. Facilitate secure remote access to payment application. 11. Encrypt sensitive traffic over public networks 12. Encrypt all non-console administrative access Document Procedures and Educate your Supply Chain 13. Maintain instructional documentation and training programs for customers, resellers, and integrators Both Scope and Process are important in evaluating your Contact Center security compliance. PA-DSS is a subset of PCI DSS. Just because one implements secure applications (PA-DSS compliant) does not mean their Contact Center is PCI DSS compliant; but, when dealing with Contact Center application vendors, PA-DSS compliance is the place to start. Adherence to Standards and 3 rd Party Verification Only Payment Application Qualified Security Assessors (PA-QSAs) employed by Qualified Security Assessor (QSA) companies are allowed to perform PA-DSS assessments. Please see the Qualified Security Assessor list at for a list of companies qualified to perform PA-DSS assessments. The PA- QSA must utilize the testing procedures documented in this Payment Application Data Security Standard document. The PA-QSA must have access to a laboratory where the validation process is to occur. A Contact Center looking to receive PCI DSS compliance must create a Report on Compliance using the template provided by PCI SCC. The compliance designation is a function of the individual payment card brand employed by the Contact Center, so the Report must be submitted to each payment card brand, uniquely following the reporting requirements for each brand. Reductions in Scope: The Best Defense Software as a service (SAAS) is outside the Scope of PA-DSS, so one method to mitigate risk within the Contact Center is to outsource applications to a third party. This may relieve the Contact Center of PA-DSS compliance concerns, but the Contact Center still must adhere to the interchange standards associated with PCI DSS. Further, the third-party vendor must adhere to PA-DSS and PCI DSS. Network segmentation of, or isolating (segmenting), the cardholder data environment from the remainder of an entity s network is a method to reduce the Scope of PCI DSS. The Process by which may perform Network segmentation may be as straight forward as merely consolidating cardholder data into fewer, more controlled locations. The Challenges of Recording and Storing Credit Card Transactions under PCI DSS Anytime a Contact Center is taking credit card orders, the issue of PCI compliance must be an integral part of the transaction. The more complex the process chain, the more difficult the PCI compliance task becomes. Every link in the chain must be PCI compliant. Consider the common practice of recording the customer interaction with a customer service representative (CSR). This call may be recorded for security purposes, is a common recording we are all familiar with. 4

5 To know how to engineer in PCI DSS compliance into the credit card transaction, the questions to ask are: 1. Is it necessary to record the credit card information? 2. Who actually takes the credit card information? 3. If the credit card information is recorded, how is it transferred and where is it stored? As we work our way down the solution chain, the solutions are cumulative, not exclusive, so the PCI DSS implementation complexity increases as the chain of events lengthens. If storing the credit card transaction is not required, then the approach is greatly simplified. Only a stop/mute recording function is required when the customer gives the credit card information. By automatically stopping the recording when the CSR or the automated IVR (interactive voice response) navigates to the transaction screen is straight forward. When the transaction is complete, the recording is restarted. If the call navigates away from the CSR, to say an IVR, this may increase security, though it s not an efficient use of CSR resources. While the credit card transaction takes place, the CSR is twiddling their thumbs waiting for the customer to return. A solution to the thumb twiddling problem is a conference transaction which allows the CSR to handhold the customer during the credit card transaction. Conferencing requires more complex Contact Center software to mute DTMF tones, so the CSR isn t exposed to credit card information during the transaction; but, this will result in fewer abandoned transactions and improves customer support satisfaction. The most complex case is when storage of the credit card information is required. It has all the complexity of the case outlined above, plus storage and networking security issues. The storage situation yields a new question, is the information stored on-site or off-site? The advantage of storing credit card information on-site at the Contact Center simplifies the process by removing the network security link from the chain. Since the Contact Center maintains physical possession of the credit card information at all times, the security process is more manageable. Encrypting the credit card information on locally locked down servers with restricted access is generally sufficient for PCI DSS compliance. There is a whole protocol associated with locked down servers that are beyond the scope of this paper, though lock down servers are a manageable problem, they can be expensive and require special staff and space. A less expensive solution may be an off-site storage that is either owned or managed by the Contact Center vendor directly or by a 3 rd party storage vendor. If the credit card information is stored off-site, this complicates the PCI DSS compliance requirements, since security now goes beyond the walls and control of the Contact Center. Not only does the Contact Center require PCI compliance, but the cloud provider and storage facility also require PCI compliance. Though once set up, this type of arrangement can be the most cost effective, and it creates the biggest headache for PCI compliance and requires the most complex Contact Center software and auditing protocol. CONCLUSION When implementing your Contact Center use only applications from vendors who adhere to PA-DSS standards. Evaluate your third-party vendors, such as cloud providers, and use only those vendors who adhere to PCI DSS standards. Further, regularly promote security within your Contact Center environment by instilling a mindset of security within your employees through training, documentation and visible security queues that remind employees of the importance of security. Finally, conduct regular internal audits to 5

6 assure that security compliance goals are being met. These actions will create a track record of compliance and commitment to security that if an unfortunate event should occur, the issue of due diligence is clearly observable and thoroughly documented. For more information, please contact 3clogic at: or find us at 6