advertisement
advertisement

When Does A Telephone Company Become A PCI Service Provider?

Written by Walter Conway
April 21st, 2010

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 wconway@403labs.com.


advertisement

3 Comments | Read When Does A Telephone Company Become A PCI Service Provider?

  1. Breina Montalvo Says:

    Thank you for touching on this subject. You bring up a good point that I have not heard before: phone services could also be considered “service providers”.

    Because there is so much misinformation when it comes to “VoIP,” merchants as well as merchant service providers,are being told that VoIP is non-compliant but we are learning that not all internet protocols are the same. By mere definition, if we look at the phone service vendors as “service providers,” we can then take the necessary steps to PCI compliancy.

  2. thejazzdiva Says:

    I would like to get a discussion group on this subject, there are many who have “internal” service providers in large enterprises that need to “help” the Network team understand that even if it is in the Corporate WAN, my VOIP to my call centers is in scope, and should be encrypted, because not all the people on the WAN need access to that data…

  3. QSA_JOHN_DOE Says:

    I think PCI DSS is clear on this point:

    “Entities such as telecommunications companies that only
    provide communication links without access to the application layer of thecommunication link are excluded.”

    If you are a VOIP provider and your customer is transmitting cardholder data over your VOIP service, then it is the customer (NOT the VOIP provider) that is responsible for encrypting cardholder data before it transmits it as a VOIP call. Unless the Telecommunications company has been contracturally engaged to be part of the clients PCI DSS compliance, then it is just passing on the call and is not responsible for the contents of the call, no matter WHAT technology is being used to transmit the call.

Newsletters

StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!
advertisement

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

StorefrontBacktalk
Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.