Why Voice Over IP Matters

“Voice over IP are the most insidious set of communication protocols ever invented by man.” – Jeff Hall

I have been having some interesting conversations of late with prospects and clients regarding Voice over IP (VoIP).  These conversations all seem to revolve around whether or not VoIP is in scope for PCI compliance.  Ultimately the conversation turns to a discussion of why I believe VoIP is in scope for PCI and almost every other QSA seems to never bring the subject up.

The primary reason I believe VoIP is in scope is that the PCI SSC says so.  If you read FAQ #1153 titled ‘Is VoIP in scope for PCI DSS?’ the Council makes it painfully clear that VoIP is definitely in scope if VoIP transmits sensitive authentication (SAD) or cardholder data (CHD).  If you doubt it, here is the exact quote from the first paragraph of that FAQ.

“While PCI DSS does not explicitly reference the use of VoIP, VoIP traffic that contains cardholder data is in scope for applicable PCI DSS controls, in the same way that other IP network traffic containing cardholder data would be.”

Yet even when it is stated that clearly, I still run into people that claim I am making a mountain out of a mole hill and their VoIP is not a risk because other QSAs have never inquired about it.  What that merely means is that other QSAs are ignoring it when they should not be ignoring it.

The first problem with VoIP seems to be that very few people understand it which is the biggest reason in my opinion that a lot of QSAs avoid the discussion.  But it is not just QSAs.  I speak with network administrators, information security personnel and other technology people all of the time and if there is one topic that will glaze over all of their eyes, it is VoIP.  When the discussion turns to VoIP, people seem to hark back to that old PBX system tucked away in the basement or closet.  No one seems to remember that the PBX did get updates (usually two or three a year).  All anyone remembers is that it just worked and that it got replaced once, maybe twice, in a generation.  And the biggest risk was toll fraud from the Caribbean.

But scarier yet is that these people do not seem to completely understand how VoIP and its protocols work let alone the risks.  The biggest problem with VoIP are the protocols used and the reason for my quote at the start of this post.  Regardless of whether you are talking SIP, H.323, H.248, whatever, they all operate the same.  Call set up (start of a call) and call tear down (end of a call) are the only points of a VoIP telephone conversation that are stateful, i.e., conducted via TCP.  The actual call itself is all done via streaming UDP just like any other audio/video stream.  Adding insult to injury, VoIP also requires a large number of the ephemeral UDP ports above 32767 to be open.  UDP, being what it is, provides one of the best transport mechanisms for delivering malware.  There are hundreds of exploits for VoIP from the most benign DDoS attack to turning a VoIP telephone into a spying device by surreptitiously enabling its microphone and video camera (if it has a camera).  But my personal favorites are the attacks that use the VoIP network as an entry point into an organization’s data network.  The bottom line is that the only way to firewall any of the VoIP protocols for actual protection is to keep them away from the rest of your network.

But it can and does get worse.  Add in VoIP trunks from your telephone carrier and you really begin to have a recipe for disaster.  When you have VoIP trunks from your carrier, your internal VoIP network is really only protected from every other VoIP network by the carrier and your call managers.  It is that sad fact that keeps a lot of information security professionals up at night.  If security is all about your weakest link, how do you protect yourself and minimize your risk when your weakest link is essentially the entire world’s phone systems?

Let us add insult to injury in this tale of woe and bring in the concept of unified communications and its primary tool, the softphone.  A softphone is software that turns a PC into a telephone using VoIP. All users need is the internet and a VPN connection to the office network and they have their office telephone right there no matter where they are in the world.  However, the softphone opens up that PC to the same risks that exist for every other phone using that call manager.  But if your VoIP system is used to take calls that discuss cardholder data (CHD), you have now turned that PC with a smartphone into a Category 1, in-scope device because it is now connected to a Category 1, in-scope system and network.  Suddenly all of that effort to achieve PCI scope reduction flies right out of the window.

But this all gets the more fascinating as people go back to their VoIP vendors and find out even more troubling issues with their VoIP solutions.  I remember numerous conversations where people thought once a call was connected to a phone that a call manager was no longer involved therefore the call managers could be put on a different network segment, only to find out that call managers act as bridges when calls are conferenced, involve telepresence or they are to/from outside lines.  They also find out that with the advent of unified communications, services such as instant messaging and email integration are no longer separate servers/functions from the call manager and cannot be easily segmented from the call managers to take them out of scope.

But then there is the revised draft version of the VoIP information supplement from the PCI SSC.  Great guidance if you have a call center.  Worthless for any other sort of implementation of VoIP.  It treats VoIP as a discrete operation as though only the call center model exists for VoIP implementations.  Granted call centers are the largest risk when they are in scope because their call volume is typically 80%+ of calls involving payments.  But all sorts of organizations take payment information over the phone but are not a call center model.

So, what about the organization that has call centers and also normal business people all on the same system?  Based on the information supplement, every phone is a Category 1 device unless the call center VoIP system is separate from the rest of the organization.

Must the call center be on a separate VoIP system from the other users?  It would appear to be that way to manage scope.  But again, there is no explicit guidance for any other implementation model other than a call center.

And if the other users take overflow calls from the call center or occasional calls dealing with PAN, how would separate systems help with that situation?  Near as I can tell, it does not help.

And what about unified communication solutions?  No idea as the information supplement does not reference a unified communication solutions.  However, given the whole premise of unified communications is that it is tightly integrated in most VoIP solutions, other communication methods such as instant messaging and telepresence would likely be in scope as well for PCI compliance.

The bottom line is that the advice I provided over six years ago in this blog is still accurate today.


22 Responses to “Why Voice Over IP Matters”

  1. 1 Deep Haria
    April 18, 2021 at 7:25 PM

    If a merchant is using legacy Non-VoIP based PRI technology to transmit CHD, would that bring the SBC and PBX in scope for PCI?

  2. August 21, 2018 at 3:35 AM

    Hi PCI Guru,

    I have been reading through your blogs about PCI and cloud based VOIP telephony providers. I’m currently managing a PCI project and after sourcing a DTMF solution our QSA flagged that the telephony service provider will still be in scope. I understand why this is the case, however our telephony provider has offered us a solution that prevents DTMF tones being created on the incoming line before it passes to our DTMF payment solution. If we were to proceed with this product would this then take the telephony platform out of scope?



    • August 23, 2018 at 6:28 AM

      The vendor can tell you whatever they want. But in my very humble experience, the tones will still traverse your network until they are masked by the third party. Just because an operator does not or cannot hear them does not mean they were not there.

  3. August 20, 2018 at 5:12 AM

    Take care that Fake-tcp/icmp headers help you bypass UDP blocking, UDP QOS or improper UDP NAT behavior on some ISPs. Raw packets with UDP headers are also supported.In UDP header mode, it behaves just like a normal UDP tunnel, and you can just make use of the other features.

  4. 7 Frank Santosa
    March 25, 2018 at 2:40 AM

    Re VOIP and Physical Security Controls.
    Thanks for your article. I concur with you and your position re VOIP and continue to have similar discussions with our clients.

    Just wanted to get your opinion on this and similar in relation to physical security for offices.
    Many offices are now introducing hot-desking allowing their employees to work at any available desk in an office.
    This may have implication on PCI DSS Controls for Physical Security.
    The current PCI DSS Scoping Document lists the controls required for personnel supporting the CDE (e.g. working on the office LAN, but connecting into a system supporting the CDE, e.g.a Log Mgt Server, or Firewall Management Server) and doesnt require physical security controls for the LAN environment, but they are required for the CDE and Systems Supporting the CDE. This seems reasonable because these people arent handling the card data, they are providing admin services.
    However, the scoping document doesnt provide a case study of an environment where people handle cardholder data from LAN environment (e.g. call center agents).
    In your opinion are these call center agents required to be physical segmented (e.g. in a dedicated room with access controls to the room) if they handle cardholder data by phone; or as part of their work (.e.g a data analytics staff member who works for the issuer so will always have access to the original PAN).
    If physical access is required to be restricted, then hotdesking is not possible for such an organisation.

    • March 25, 2018 at 4:57 AM

      Separate and secured areas are not required by the PCI DSS but are usually put in place to reduce workplace noise as well as keep people that have no business out of the call center. The PCI DSS really only requires that the facility has physical security controls such as card key access and video monitoring.

      As far as I am aware, “Hot Desking” or “Hoteling” (as it’s called in the US) is not restricted by the PCI DSS nor has there been an FAQ issued regarding it. But it does bring up some interesting potential issues if PCI DSS requirements are not considered. That said, a lot of that can be mitigated by the use of virtual desktop (VDI) technology.

  5. 9 Mike
    February 21, 2018 at 10:33 PM

    Hi all. very nice blog, I have been a reader for some time. However this is time to ask my first question.

    Regarding VoIP system and call centers.. is it a requirement to have the voice encrypted at the local network?… I read that somewhere the other day, however what I find on the PCI 3.2 is REQ 3 to protect CHD data at REST and REQ4 to encrypt transmission over OPEN PUBLIC Network.. can’t find anything about encryption during transition at the local LAN. voice traffic from the call manager to the phones is segmented from the other LANs/VLANS.. but my concern is, is this a recommendation or is mandatory and is so, under which requirement?

    • February 22, 2018 at 9:03 AM

      If the VoIP traffic is on an internal network controlled by your organization, then it does not need to be encrypted. What encrypting the traffic on your internal network does though is segment it from the rest of your network which may slightly reduce scope.

      • 11 Mike
        February 22, 2018 at 8:03 PM

        Thanks for your prompt answer. That is what I was thinking.
        We already have segmentation for the VoIP traffic, there is one designated isolated VLAN from the other network.
        Thanks again.

  6. 12 Simon Ober
    August 22, 2017 at 5:21 PM

    Dear PCI Guru,

    From your experience, have you found that merchants that outsource their VOIP solutions to the cloud and guard against the transmission of cardholder data through the use of mid-call DTMF solutions (clamping down on the DTMF and having the customer enter cardholder data via their telephone’s keypad) remove the hosted VOIP solution from their PCI scope?

    • August 25, 2017 at 4:57 AM

      Not always. Depends on how the call transfer works with your VoIP system. Some are still sending the call through the call manager. It’s why people need to ask lots of questions to figure out how the solution works. Trouble is, a lot of vendors have no idea how their solutions work. You will likely have to dig out the answers through a lot of diligence.

  7. 14 Wayne Murphy
    August 19, 2017 at 2:23 AM

    I’m finding this is constantly overlooked by QSAs and merchants/service providers and find it a very challenging conversation when discussing this with clients. Often I’m presented with the argument that they have now encrypted the VoIP traffic therefore it’s no longer in scope.

    Something I increasingly coming across is clients who have started to use a DTMF solution to de-scope everything to them find that they are transferring the call to the DTMF service which means their phone system still in scope as it still routes the traffic.

    • August 19, 2017 at 5:24 AM

      And those third party IVR solutions may or may not leave the client’s VoIP system in scope. There are some that cause the transfer to be complete, but it is difficult at times to make that determination.

      Encrypting VoIP traffic protects the data stream, but still leaves the telephones and call managers in scope because they are endpoints in that encryption solution.

  8. 16 PCIGURU Fan
    August 18, 2017 at 11:31 PM

    How many post breach forensic investigations have identified voip as the entry, exit, or data transfer point? In other words is voip a possible or a probable breach source?

    • August 19, 2017 at 5:28 AM

      I am not aware of any breaches that have been traced back to a VoIP security issue. But that does not mean there have not been any or that it is not a valid vector for future attacks.

      Given the plethora of VoIP exploits, it is likely only a matter of time before VoIP is publicly used as an attack vector.

      I did get to see a hospital breached via VoIP years ago in an information security exercise as a “proof of concept” test.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

August 2017

%d bloggers like this: