2017 BEST PRACTICEs CONFERENCES SERIES - BOOK YOUR PLACE TODAY!
EUROPE, Middle EAST & AFRICASTARTS IN:
NORTH and south americasSTARTS IN:
ORLANDO, FL USA
asia pacificSTARTS IN:
KOTA KINABALU, MALAYSIA
Article : Ten Things You Should Know About Security and PCI Compliance When Using Cloud-Based Contact Centers
When migrating from a premise-based Contact Center to a cloud-based Contact Center, the biggest concern that decision makers have is security. Even if a Contact Center is not migrating from a premise-based solution, unless the system has been designed and architected in a way that addresses security and privacy, chances are there will be major security exposures and non-compliance.
The primary concerns that need to be addressed for cloud-based Contact Centers are:
a. Preventing unauthorized access so that only authorized users, with proper credentials, can access confidential data.
b. Protecting the privacy and integrity of confidential data, including credit card information, personal information (e.g., social security numbers and contact information), representative’s notes, call data records, chat transcripts, and call recordings.
c. Integrating with third-party CRM providers without compromising security and privacy.
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 also includes issues pertaining to PCI DSS compliance for cloud-based Contact Centers.
Availability of Contact Center applications and their accessibility from the cloud is crucial to employees and business. Security threats to these applications can cause downtime and pose challenges to security management, resulting in reduced employee productivity. If a Contact Center is processing credit card transactions as part of its business operations, it is a given that there are real civil and criminal liabilities associated with breaches in payment card security. Credit card companies may impose fines up to $500K per incident of PCI DSS non-compliance. So, how can a cloud-based Contact Center solution provide the same level of security as an on-premise solution? And, 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?"
Cloud Infrastructure Security
Comprehensive security evaluation should start with the cloud infrastructure on which the Contact Center is to be deployed. The cloud infrastructure must manage a comprehensive control environment that includes the necessary policies, processes, and control activities for the delivery of each of the Contact Center service offerings. The collective control environment encompasses the people, processes, and technology necessary to maintain an environment that supports the effectiveness of specific controls and the control frameworks for which the cloud infrastructure is certified and/or compliant.
It is important that the cloud infrastructure on which the Contact Center is deployed is compliant with various certifications and third-party attestations. These include:
• SAS70 Type II: Ensure that the cloud provider maintains reports of detailed controls the cloud provider operates along with an independent auditor opinion about the effective operation of those controls.
• PCI DSS Level 1: Make sure that the cloud infrastructure provider has been independently validated to comply with the PCI Data Security Standard as a shared host service provider.
• ISO 27001: Confirm that the cloud provider has achieved ISO 27001 certification of the Information Security Management System (ISMS) covering infrastructure, data centers, and services.
• HIPAA: Evaluate if healthcare applications compliant with HIPAA’s Security and Privacy Rules have been deployed on cloud infrastructure being evaluated.
Contact Center Application Security
- Role-Based Security
Does the cloud-based Contact Center come with role based security? Role-based security should allow a Contact Center license owner/subscriber to provide each user within their organization with role-based access to features and data. A cloud-based Contact Center application must allow for roles to be assigned to users such that these roles define and constrain users from any unauthorized access.
Roles and authorities should be assigned to each user so that each user can access features and data that are necessary to complete their tasks. The access should be restricted at read, write, update, and delete levels for data. It should also be restricted at skills, teams, projects, and Contact Center levels for features. For example, a sales representative might be able to view customer details, but they may not be able to update or delete them. A team supervisor may be able to view the performance of the team that they are assigned to, but they (supervisor) should not be able to view the performance of other teams within the same Contact Center or project.
It should be possible to customize and modify the roles and authorities based on license owner preferences and needs of the Contact Center. For example, there could be three default roles for any Contact Center. These (roles) are:
a. Contact Center Executive/Manager: The owner or administrator of Contact Center has full access to all the subscribed features. A Contact Center manager should be able to create new roles and add subscribed authorities or features to these roles. The Contact Center Manager functions as an administrator of the licenses.
b. Supervisor: The supervisor, or team lead of the group, should be able to monitor the performance of a group of Customer Service Reps (CSRs) using dashboards and reports. A supervisor should also be able to modify projects and project assignments for the CSRs where they are authorized by the Contact Center manager to do so.
c. Customer Service Representatives: CSRs should be able to receive and make calls, text, and email, or chat when authorized. CSR’s view of the data should be restricted based on roles. CSRs can also be restricted to work on specific projects and under specific skills group.
- Telecom Security
License owners should be able to restrict CSRs from making unauthorized calls or texts to unauthorized calling area. Telecom security should restrict outbound users while allowing them to make user initiated calls or texts, only to intended calling area and avoid any international calling charges for the Contact Center. It can, if required, also restrict inbound license owners to receive calls from specific calling areas.
- Password-Based Authentication
It is important to have password-based authentication to give users authorization to access to subscribed features. The passwords stored in the database should be encrypted and cryptographic algorithms should be used to verify users. There are algorithms that have been substantially proven to secure cloud-based services. In case of repeated access attempts, an alert should be generated and the user should be presented with further authentication to prove that the attacks are not automated.
Security for Servers in the Cloud
Contact Center software should provide the industry standard of 256bit Secure Sockets Layer (SSL) for internet based access to the subscribed services. The data, media, archives, and recordings should all be transferred over HTTPS and/or a Transport Layer Security (TLS) connection for highest possible security. The data itself should be stored on highly secure servers and accessible only by authorized personnel.
Data stored on hosted servers must have built-in multi-location redundancy and reliability to cover any risk of failure because of natural disasters (e.g., fires, floods, and earthquakes). Live backups and redundancy of the servers and data provides for seamless access to application and close to a 99.95% uptime.
To ensure the privacy of information over the public internet, all communication between the servers in the cloud and users' machines should be secured using SSL/TLS connections. The communication between multi- location servers can happen over the same secured connections using SSL/TLS.
Cloud-based Contact Center software must be tested and verified against major online attacks like Cross-site attacks (XSS), Weak passwords, SQL injections and Script Injections. Cloud-based Contact Center providers must be committed to immediately use best industry practices to avoid any future attacks that are uncovered and keep the software secure to prevent any loss of data and privacy for their customers.
Third-Party CRM Access Security
Ideally, a Contact Center application should not store any CRM related data on its cloud infrastructure. When a customer call comes in, a web-service call should be made to the CRM and the associated customer information should be fetched and displayed to the CSR. In the case of outbound calling, tokens such as phone numbers and CRM IDs can be pre-stored in the cloud. When a live connection is made, a web-service call is made to the CRM and the associated customer information is fetched and displayed as the call progresses. This way, none of the sensitive data ever leaves the enterprise network. Even the tokens are encrypted end-to-end, further securing sensitive data.
A cloud-based Contact Center must allow its subscribers to use their existing CRM systems without jeopardizing the security and privacy of their data. It should be possible to integrate Web/HTML based third- party CRM systems with Contact Center software using the inbuilt browser and java script application programming interface (API). The methods exposed to java script can be used to update and populate the third-party CRM system. The access to each attribute of the data is authorized by roles and authorities which are determined by the licensed owner. The API should be accessible only after logging into the system and it should restrict users from unauthorized data access or updating.
PCI DSS CCOMPLIANCE
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:
• Network Time Protocol (NTP)
• Domain Name Server (DNS)
Applications include all purchased and custom applications, including internal and external (for example, Internet) applications." 1.
Overview of PCI DSS Requirements
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
1 PCI DSS Requirements and Security Assessment Procedures, Version 2.0
2 Ibid Excerpted
3 PCI PA DSS Requirements and Security Assessment Procedures, v2.0
4 Ibid Excerpted
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
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 Third-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 www.pcisecuritystandards.org for a list of companies qualified to perform PA-DSS assessments. The PA- QSA must utilize the testing procedures documented in the 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 Security Standards Council (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.
To know how to engineer in PCI DSS compliance into the credit card transaction, ask the following questions:
1. Is it necessary to record the credit card information?
2. Who actually takes the credit card information?
3. If 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. 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 Dual Tone Multiple Frequencies (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 third-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 it (PCI compliance) too. However, once set up, this type of arrangement can create the biggest headache for PCI compliance and requires the most complex Contact Center software and auditing protocol.
A cloud-based Contact Center must provide a secure online platform so that Contact Centers can conduct their business and service their customers. At the same time, a cloud-based Contact Center must provide features that are easy to use and do not risk the privacy and secrecy of the data entrusted with the provider. The transactions conducted over the platform must be secure and adhere to highest standards of cryptography.
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 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
Contact 3CLogic - find out more
Download this paper here
Today's Tip of the Day - Complaints
More Editorial From 3CLogic
3CLogic offers a complete suite of inbound, outbound, and blended cloud-based contact center solutions based on an innovative distributed approach (Virtual Telephony Application Grid or V-TAG) that eliminates the need for legacy server-centric architecture. Providing companies with a 360-degree view of all their customer interactions, regardless of the channel chosen, 3CLogic’s solutions allow for a timely and accurate means by which to offer first call resolutions. As a true cloud software solution, hosted on AWS, it offers seamless integration with other cloud-based solutions, including CRM and WFM, while providing market-leading security, scalability, and reliability. Finally, in addition to traditional contact center features (i.e. multichannel communication, IVR, ACD, predictive dialer, etc.) 3CLogic provides a powerful reporting framework with business analytics and real-time scripting engine.
Published: Thursday, March 14, 2013