PCI Data Security Standards

Share:

The Payment Card Industry (PCI) Data Security Standards
have gained significant attention in the call center market. In this section of the whitepaper we will discuss what those standards are, how they affect recording applications, and
what you can do to help ensure your recording system operates in respect of
those standards.

We have researched this topic extensively; however, inContact is not affiliated with the PCI Security Standards Council™. The information presented in this whitepaper
is based on our research using the information provided at www.pcisecuritystandards.org,
interviews with peers in the industry, and feedback from our clients.

What is PCI?

PCI stands for Payment Card Industry. The PCI Security Standards Council was
founded by American Express, Discover Financial Services, JBC, MasterCard
Worldwide, and Visa International. The Council’s stated mission is “To enhance payment account data security by fostering broad adoption of the PCI Security Standards.”

Who Enforces PCI?

While the PCI Security Council established and maintains the Data Security Standards (DSS), each card brand still manages its own compliance programs. If you have
questions or concerns regarding your company’s compliance status or the risks
and penalties for falling out of compliance, we recommend you contact the
payment brands you are contracted with.

Why All the Fuss?

We could fill volumes with the reasons that PCI Security Standards are important, but in this case the above picture is worth 1,000 words. Identity theft is pervasive in today’s economy, and consumers need to be protected. The PCI DSS take great measures to help safeguard consumer account information and minimize or eliminate the potential for identity theft.

What Are the DSS?

What follows is an outline of the PCI DSS, and notes on how a recording system may be impacted by those standards. The full PCI DSS version 1.1 is available at www.pcisecuritystandards.org.

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall
configuration to protect cardholder data

Most recording applications will not have an impact on the existing firewall; they will be on your network behind your firewall. This will be different for hosted applications, however.

Requirement 2: Do not use vendor-supplied defaults
for system passwords and other security parameters

While we cannot speak for all vendors in the industry, part of inContact’s standard installation procedure is to reset/remove all default passwords. Other measures can be taken to ensure employees do not create overly-simple passwords. This includes the ability to
restrict any users from resetting their own passwords, thus providing the
capability to maintain a higher standard for password security (such as a
higher number of characters, requirements for both upper- and lower-case alpha,
numeric, and special characters in the password).

Protect Cardholder Data

Requirement 3: Protect stored cardholder data

Encrypting the stored data, i.e.
your audio and screen recordings, is perhaps the best way to protect the stored
cardholder data. In the unlikely
scenario that a person could access your secured data center, remove the hard
drives from your recording server or storage unit, and connect those drives to
another server, that person could access unencrypted data on those disks. It is an unlikely scenario, but after all it
happened at Los Alamos…

Requirement 4: Encrypt transmission of cardholder
data across open, public networks

Hosted systems aside, a call
recorder will be on your network behind your firewall, and will not be on an
open public network. If you offer remote
access to the system by third parties, such as a client accessing a system at
an outsourcer facility, that access should be through a secured connection such
as VPN, and not over the public Internet.

Other data transmissions that
could be encrypted include screen capture data sent from a PC to your recording
server, audio and screen files that are downloaded or streamed from the server
for playback, or recordings that are exported from the system.

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus
software

Contact your vendor to see if
there is a recommended anti-virus program for the recorder. We strongly advise against installing any
anti-virus software on your existing recorder without first verifying that it
is compatible with the recording software!

Requirement 6: Develop and maintain secure systems
and applications

Most, if not all, recording
applications have sophisticated permissioning systems to ensure that
unauthorized users cannot access recordings. Exceptions may be tape recorders or units that tap a handset and save
the recordings to a local PC. Notwithstanding
those exceptions or hosted recorders, you should have the ability to restrict
user access at the network level by denying access to the server IP address, in
addition to user name and password authentication. The server itself will require authentication
through Windows for an administrator to log on.

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data
by business need-to-know

User permissions should be able to
restrict what records each user can access, or deny any person from having
access to the server. You can also use
IP restrictions in your data network to further ensure the unauthorized
employees cannot reach the server from their workstations.

 

 

Requirement 8: Assign a unique ID to each person
with computer access

Whatever you do, DON’T SHARE YOUR
LOGINS!!!

Requirement 9: Restrict physical access to
cardholder data

The recording server should be in a
locked computer room / data center at your facility. For a hosted solution, check with your
hosting provider to ensure access to the server is restricted. Having encryption for your stored files is
also helpful in restricting physical access to the data.

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to
network resources and cardholder data

Most PCI compliant companies are
likely to have something in place that is monitoring network activity. In addition to your network management
protocols, your recorder should log user access and user activity within the
system as it pertains to accessing recordings.

Requirement 11: Regularly test security systems and
processes

While we cannot speak for other
vendors, as we add new features to cc: Discover and other CallCopy software,
part of our QA process is to conduct regression testing to ensure new components
to not have unwanted effects on existing modules.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses
information security

If your vendor has direct access
to your recorder through modem, VPN, or other means, you should ensure that
vendor has a policy for information security.

Exceptions to the DSS

“PCI DSS requirements are applicable if a PAN [Primary
Account Number
] is stored, processed, or transmitted. If a PAN is not stored, processed, or
transmitted, PCI DSS requirements do not apply.”

 

 

What Can Be Stored

Information on what can and can’t be stored is reprinted
from the Payment Card Industry (PCI) Data Security Standard Version 1.1, Release:
September 2006. Descriptions for the
CVC2/CVV2/CID are taken from the Glossary available atwww.pcisecuritystandards.org.

Data Element Storage Permitted Protection Required PCI DSS Req. 3.4

What Can’t Be Stored

Data Element Storage Permitted Protection Required PCI DSS Req. 3.4

*The second type of card validation value or code is the
three-digit value printed to the right of the credit card number in the
signature panel area on the back of the card. For American Express cards, the
code is a four-digit unembossed number printed above the card number on the
face of all payment cards. The code is uniquely associated with each individual
piece of plastic and ties the card account number to the plastic. The following
provides an overview:

CID Card Identification Number (American
Express and Discover payment cards)

CAV2 Card Authentication Value 2 (JCB
payment cards)

CVC2 Card Validation Code 2 (MasterCard
payment cards)

CVV2 Card Verification Value 2 (Visa
payment cards)

 

 

Recommendations

After extensive research on the Internet and through
personal interviews, we have not been able to find any conclusive rulings
regarding the PCI DSS and call recording applications. As with the two-party state recording laws,
our recommendation is to err on the side of caution and implement the solution
that best addresses the PCI DSS.

The aspect of the PCI DSS that poses the greatest challenge
to the recording industry is the prohibited storage of the CVC2/CVV2/CID – the
three- or four-digit security code, depending on the card type. This information is stored in your audio and
screen recordings.

So how can you remove or block the security code from your recordings?

Manual Editing

Manual editing is one way to remove that data, but we do
not recommend this method. It seems with
the goal of PCI DSS being to limit access to the cardholder data, manually
editing the recordings is exactly the opposite – it is requiring someone to
access the data, however temporary that access may be. Not to mention the labor requirements…

Automated Editing

There are challenges with automated editing of records as
well. A recording that has been tampered
with or edited may not be usable in court. You also need to ensure the right sections of the call are edited. This can be an automated or manual trigger
sent to the recorder to update the record with start and stop points, between
which is the sensitive data. With
CallCopy’s cc: Discover platform, we offer a bcc: Compliance module that allows
users to send these triggers, and there is a blackout applied to the sensitive
data.

If this is a manual trigger, then you are relying on your
staff to always remember to click a button to initiate and end the
process. This is obviously subject to
human error, and the result will be some recordings where an agent forgot to
start the blackout and some where the agent forgot to end it.

 

Our recommendation is for automated triggers based on
activity in a desktop application or web form. In this scenario, a trigger to start a blackout would be sent when an
agent clicks on the field to enter the security code, and it would end when the
agent submits the account information. This method is still not infallible, as a customer may provide account
information before the agent takes the action that starts the blackout.

Encryption

We recommend a recording system that is able to offer
encryption for your stored data as well as encryption for all client-server
communications. This includes screen
data being sent across your networks and audio/video playback.

Exported Records

Perhaps the most critical time to
encrypt calls is when they are exported from the system. We do not recommend that calls with sensitive
cardholder data be exported unless they are encrypted and password protected.