When Does A Telephone Company Become A PCI Service Provider?

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

At what point does a voice over Internet Protocol (VoIP) vendor become a PCI service provider? In other words, at what point does VoIP begin to affect your PCI compliance?

More corporations and consumers, and some of my colleagues, are using the Internet for their voice telephone service. Retailers and other payment card merchants use VoIP lines for their POS terminals. If you use VoIP internally, the question of whether it is in or out of your PCI scope is straightforward. If the VoIP system stores, processes or transmits cardholder data, it's in scope.

VoIP works by digitizing your analog voice signal and sending it to a data network (the Internet). The bad guys have a variety of tools to attack VoIP traffic and systems, so you need to make sure these networks are secure, particularly if you use VoIP in your call center and record the conversations. I was once asked, "If a VoIP network is used for cardholder data, what sections of PCI DSS would apply?" It was an easy question to answer: All of them.

Some merchants feel telecommunications companies got a pass on PCI, at least as far as their being considered service providers. The PCI Council's Glossary defines a service provider as a business entity involved in storing, processing and transmitting cardholder data. The definition specifically states, "entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded."

As telecom companies expand their services to offer Internet-based all-in-one communications to merchants, they begin to look an awful lot like service providers for PCI purposes. The more they convert analog voice data to digital data and provide additional services like firewalls, routers and interactive voice response (IVR) systems, the more telecoms cross over into the "application layer of the communications link" and fall into the standard definition of a service provider.

The PCI Council provides no specific guidance on VoIP. If you search its FAQ for the term "VoIP," you won't get a single hit. That actually is appropriate; it is a technology, and the Council doesn't--and shouldn't--endorse or take a position on any technology. The issue of VoIP all comes back to whether you store, process or transmit cardholder data.

What is a retailer, or even a processor, to do? Most merchants think their PCI scope ends at their Internet-facing firewall. This is not completely true. Requirement 12.8 has four sub-sections addressing how you manage service providers. You are not responsible for their compliance, but you are responsible for managing them. Specifically, you need to have your service providers take responsibility for the cardholder data they process, and you have to monitor their PCI compliance.

Merchants also need to look at PCI Requirement 4.1 when they use VoIP and determine how it applies to their implementation. This requirement specifies that you "use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks." The Internet is specifically mentioned as an example of such a network. Some providers may not encrypt your data automatically.

The spread of VoIP goes deep. Merchants of all sizes now use it to connect their POS terminals. VoIP is reliable, and it can be cheaper than plain old telephone service (POTS).

CIOs can do a few things in addition to PCI Requirements 4.1 and 12.8. For example, be sure to assess how any planned VoIP implementation will affect your firewall segmentation. Ask your vendor what services need to be allowed between network segments or to the Internet.

Because it uses protocols that firewalls are not necessarily designed to restrict, VoIP may cause a hole in your security that increases the risk to your internal systems. Encrypting the traffic is a good start.

If you use VoIP in a call center, protect any digital voice recordings per the PCI Council's guidance. If you use VoIP for your POS card transactions, you may want to confirm that your vendor uses strong encryption (e.g., AES 128 bits or higher; Triple DES; RSA) as recommended by the PCI Council.

VoIP may save money, but you still need to be secure.

In all cases where your vendor is providing additional services that would begin to cross the line from telecom provider to PCI service provider, ask about its PCI compliance. If you get an answer like "telecom providers are exempt," make sure you agree with that assessment. That vendor is transmitting cardholder data on your behalf. If it has visibility to the application layer, then it is a service provider.

Don't forget, as part of your PCI compliance you are responsible for monitoring and managing your VoIP provider the same as you would any other service provider.

Do you use VoIP in the cardholder data environment? What steps have you taken to make sure you remain PCI compliant? I'd like to hear your thoughts. Either leave a comment or E-mail me at [email protected].