18
Aug
17

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.

Advertisements

11 Responses to “Why Voice Over IP Matters”


  1. 1 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.

  2. 3 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.

  3. 5 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.

      • 7 PCIGURU Fan
        August 19, 2017 at 7:12 AM

        So, at this point, it’s either a “flat earth” threat or a “tipping point” threat like anti-virus was prior to the Melissa/love virus in 2002. If you truly believe the latter maybe put a business plan together and line up investors for a product solution so you can become the billion dollar McAfee of voip when that fateful day arrives. 🙂

      • August 19, 2017 at 7:23 AM

        Problem is, how do identify a “good” VoIP packet from a “bad” VoIP packet? 😉

      • 9 PCIGURU Fan
        August 19, 2017 at 8:19 AM

        By creating the bad voip packets so you can control creation of the good voip packets just like the anti-virus products. 😜😜

      • August 20, 2017 at 7:59 AM

        Saw this in my Twitter feed this AM.

        http://www.kitploit.com/2017/08/udp2raw-tunnel-udp-tunnel-which-tunnels_19.html


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 )

Google+ photo

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

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

August 2017
M T W T F S S
« Jul   Sep »
 123456
78910111213
14151617181920
21222324252627
28293031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,898 other followers


%d bloggers like this: