I have had some interesting conversations with people lately regarding voice over IP (VoIP). It fascinates me as to how little people really know and understand how this technology works. But what really scares me is how this lack of information is putting organizations at risk.
The most obvious problem with VoIP is segmenting it away from the cardholder data environment (CDE). I am really disturbed by the number of organizations that have no security around their VoIP. Yes a lot of organizations have segmented the VoIP from the rest of their network, but there are no controls that stop anyone from getting into that network segment. As a result, anyone with the right set of tools can gain access to the traffic in the VoIP network segment.
The next thing that scares me is the lack of security surrounding the VoIP servers including any call recording servers. People treat these VoIP servers just like their traditional PBX. Unlike their PBX that likely ran a proprietary version of UNIX, VoIP servers are just Windows or Linux servers running a VoIP application. As a result, they are susceptible to all of the viruses, malware and everything else any other server is susceptible. However, these servers typically do not run anti-virus (performance issues) or are they hardened to any rational security standard. When they get infected or hacked, it seems to be a shock to the system administrator.
And what about the call recording technology? We keep hearing from vendors of call recording solutions that they use proprietary recording methods requiring special CODECs. While in some instances the proprietary claims are true, what we are finding more and more is that vendors are just manipulating file header information such that Windows Media Player, iTunes and the like do not recognize the file as being in a valid format. However, tools such as VLC Media Player are able to see past the header changes and recognize these files for what they are, WAV, MP3 and the like. Thus some proprietary formatting claims are all a bunch of smoke and cannot necessarily be relied upon for security or privacy. Another tell on the proprietary nature of call recordings is that, when you “convert” a recording, if the conversion software seems to be copying the recording more than actually converting it, it is likely that the header is being fixed to WAV, MP3, etc. Real audio conversions typically take more time than just copying because the file has to be fully processed.
But the final insult in this whole scenario is the lack of understanding security personnel have regarding the VoIP protocols. While VoIP call setup and teardown are usually conducted over TCP/IP (a stateful protocol), the actual call itself is conducted via streaming protocols over UDP/IP (a non-stateful protocol). As a result, when you start talking to security people about VoIP security, their knee-jerk response is to tell you that VoIP is secured by the corporate firewall. However, given that the VoIP protocols are stateless, even behind a firewall really does not provide any protection.
So you have a VoIP solution in place. What should you be doing to ensure its security if it is in-scope for PCI compliance? Here are my thoughts.
- Properly segment your VoIP from the rest of your network. This means either physically or logically separating the VoIP from the rest of your network. This also means implementing access control rules so that only those devices and people that need access to the VoIP network have access. If you are also using your VoIP phones as the network jack for a PC, make sure to VLAN that jack to something other than the VoIP VLAN.
- If you can, implement the VoIP segment without DNS and DHCP and use MAC filtering to avoid the accidental or deliberate plugging in of a PC into a network jack that is VoIP only. At a minimum, use MAC filtering to at least control what gets plugged into the LAN jack.
- Closely monitor your VoIP segment and generate alerts on any devices that are unplugged or plugged in. Also monitor for any protocols other than the VoIP protocols that your VoIP system uses.
- Do not use the last octet or any other portion of the phone’s IP address as the extension number. Yes, I know this is an easy way for the help desk to identify and troubleshoot phones, but it is also easy for an attacker to locate targets of interest, so keep that in mind when you are implementing your VoIP solution.
- Never, ever connect your VoIP network to another VoIP network outside of your explicit control. Given that VoIP primarily uses UDP/IP, you cannot expect any firewall to protect your VoIP system from anything outside of your control. Always use plain old telephone system (POTS) circuits to connect to any foreign network. I know that is not as sexy as VoIP, but how else can you protect your VoIP system from outside influences?
- Work with your VoIP vendor to harden all servers that manage the VoIP system. These are just Windows, Linux, etc. systems. Obviously you will need to do some testing of this and you may not be able to use all of the hardening items in your server hardening standard, but you would be surprised at what you can do that the vendor says will not work. Remember, they are just trying to cover their butts should a problem crop up.
- Be careful implementing VoIP on traditional PBXs. A lot of these solutions are just PCs or servers and can be easily hacked once on your network just like their full VoIP brethren.
- Get a hold of VLC Media Player or similar tool and see if you can play a recording off of your call recording system. We are getting about a 25% hit rate using VLC to play recordings. A lot of the success of this approach depends on the age of the call recording system. The newer the systems, the more likely it is that you will find that the recordings are just tweaks of existing standards.
PCI Guru 
Thanks for the article, it’s very hard to find information pertaining to securing VOIP.
I do have a question pertaining to securing VOIP. If the VOIP system was encrypted end to end, using methods such as SIP-TLS & SRTP, would this negate the need for segmentation as long as the end points were adequately secured? Obviously the end points would still be in scope, but I would of thought by virtue of the encryption, that any other devices the traffic touches would be out of scope?
Given all of the other security issues with VoIP, call managers, telephone handsets and softphones, securing the communication stream is the least of the problems. That said, encryption of the communication stream would technically segment VoIP for PCI compliance purposes. However, from a true information security perspective, I would say more would need to be done such as securely VLANing the VoIP away from all other traffic.
Thanks for the reply, I appreciate the advice.
Hello PCIGuru,
I realize that your comment is dated. However, I found “That said, encryption of the communication stream would technically segment VoIP for PCI compliance purposes”. To be surprising. Am I correct that this statement does NOT still apply, ie encryption alone will NOT provide segmentation from any local VoIP infrastructure being used? I base this assumption on the Nov 2018 supplemental document.
Since I was part of the group that wrote the 2018 telephony information supplement, I have to point out that nothing I have written violates that document.
End-to-end encryption (E2EE) is a form of segmentation and takes everything between the two endpoints out of scope as long as they cannot decrypt the connection (see FAQ 1086). This has been approved by the Council for a long time and is the basis of the P2PE standard. However, those endpoints are still in scope for PCI compliance.
I think that the important piece that you are missing is that in a VoIP environment, everything connects to the Call Manager (which is the CDE) so anything that connects to the Call Manager is also in scope regardless of whether or not they are used to take CHD over the telephone or not.
That said, I always recommend that the VoIP network be VLAN’d from the rest of the network even if telephone connections are encrypted.
Also see this dicussion for 12 years ago. https://pciguru.wordpress.com/2009/10/31/pci-ssc-issues-clarification-on-encrypted-data-being-in-scope/
In your Nov 4, 2012 reply, you mentioned that vendors have been working on VoIP firewalls, but that the early versions were not sophisticated enough for the task at hand. It’s a couple of years later, and wondering if the VoIP firewall landscape has changed? My organization takes customer payments on 1st generation VoIP (no call center, so no storage). Could a VoIP firewall be used in lieu of ACLs to attain sufficient security controls for VoIP?
Btw, thank you for your contribution to the PCI Community. It’s great that people have a forum to ask questions!
I would like to tell you that progress has been made, but not really. There are still a lot of vendors peddling FUD and “snake oil” solutions for VoIP. I even had one vendor claim that they could tell a “bad” audio/video packet from a “good” audio/video packet. When I probed with questions to figure out how they had done this, I got the usual “that’s a proprietary technology and solution” answer which is code for “we think it does what we claim it does and we hope you never ask us to prove it”. It has to be magic, because there is no such solution. The protocol is predominately UDP and stateless, so other than call setup and tear down, they have nothing to work with without causing communication issues.
Thanks for finally talking about >VoIP And PCI Compliance | PCI Guru <Liked it!
Actually, there is no regulation for VoIP services concerning PCI compliance since it is strictly a transport and there is no storage of information just like there is no regulation for calls over analog lines. VoIP can do a encrypted VPN which is actually more secure than any analog technology but it still irrelevant. Also, credit card machines can’t work over VoIP lines as of 2012. It currently has to be a analog line do the how the calls are started. Look up the terms “ground start” to a winded version of an explanation.
I cut my professional teeth on analog telecommunications protocols such as X.25, ATM and Frame Relay, so I’m very aware of what you are saying and the point you are arguing.
Yes, the PCI DSS does not explicitly call out voice over IP (VoIP) in the standard. However, there are plenty of parts of the standard that are relevant because of the nature of VoIP.
The same issues occurred with automated teller machines (ATMs) when they moved from Binary Synchronous (bisync) to TCP/IP telecommunications around 6+ years ago. Part of the security of ATM transmissions was the fact that bisync needed a traditional wiretap and specialized equipment to listen in. When ATMs moved to TCP/IP, all that was needed was a hub or promiscuous switch port and Wireshark (then called TCPdump).
For the most part, VoIP is just streamed UDP and as such can be easily intercepted with Wireshark and other packet capture tools if the VoIP traffic is not properly configured and segregated. VoIP is even more insidious because the call itself is done using a stateless protocol (UDP). As a result, it cannot be adequately firewalled as firewalls require stateful protocols to work. Vendors are supposedly working on VoIP firewalls, but early models have not lived up to expectations because of the inability to determine good from bad packets in a stream. Then there is the call manager which is typically just a Linux- or Windows-based server with call management software. Any call recordings or voice messages in VoIP are typically stored as MP3 or WAV files, so they can be readily be listened to by anyone with a computer. None of these technologies one their own are as secure as the traditional analog PBX and proprietary call recording technologies. This is why special measures and considerations need to be taken to protect VoIP and its recordings such as encryption of storage, encrypted VPNs for call connections and the like.
As to analog credit card terminals not working over VoIP, they can. Granted, you do need special converters or switches, but an analog credit card terminal is no different than a facsimile machine or an analog telephone as far as a VoIP system is concerned. We have been reliably implementing analog devices on VoIP networks for more than five years now.
The bottom line on VoIP versus analog is that VoIP opens the door to anyone being able to wiretap the system without too much skill. Analog wiretapping required a lot of knowledge and physical access to the telephone switch or circuits. VoIP wiretapping can be done from the perpetrator’s home if the right conditions exist and, regardless of technique used, the victim never knows.
…Wireshark (then called Ethereal)…
The cardholder data environment is defined as anything that transmits, stores or processes card information. AND anything that can connect to this… If you don’t segment your VOIP traffic at a minimum it is most likely that all devices in your organization are in scope of your PCI Assessment.
The key is HOW you segment your network overall, not just VoIP. By just putting VoIP in a separate VLAN does not segment it from a PCI compliance perspective. In order to meet PCI compliance you need to have ACLs that restrict traffic between the cardholder data environment (CDE) and any other network segment, preferably the VLANs have no access to the CDE. The problem we constantly encounter is that VLANs are in place but there are no ACLs restricting access from one VLAN to another VLAN.
Exactly, and that is what I will be looking for when I audit a company that uses VOIP. Not to mention business justification for all access and related things like logging and monitoring in a SAQ D or service provider environment.
I know this is an old thread but I have a question, what about the actual call itself while it is being made. Is there any way or is there a vendor you know of that secures the call itself? Is this something that i should be worried about when trying to be PCI compliant? We are a call center that takes CC information over the phone.
Thanks for this post. I found it while researching a query on whether the phone system into a call centre is in scope. There is a huge amount on the web about call recording in call centres (including the PCI SSC own guidance) but virtually nothing about the phone system itself – which suggests to me that most QSAs ignore it. I’d see the phone network between the PBX and the handset in the call centre as in scope by virtue of ‘transmitting’ card data. In which case all the requirements that apply to other network components will apply to the phone system. Is this how you’d see it?
Depends on the phone system.
Older PBXs can have integrated call recording technology, but most had that as a “bolt on.” As a result, you need to talk to the person responsible for the PBX to determine if it needs to be examined. Yes, I know that a lot of older PBXs are running variants of UNIX, but very few got attached to networks or if they are network attached, all you get access to is basic PBX management capabilities.
Newer PBXs are typically based on Windows and Linux, and they are definitely integrated, so they need to be treated no different than any other server that is in-scope.
Great post and thanks for sharing the tips about security and PCI compliance…very helpful. VoIP is so important and beneficial to companies and organizations.
I actually have a question for you regarding this post. I have been doing some independent research on my Vonage line in regard to my credit card machine not working. I have a Vonage line because it’s cheaper, with Time Warner cable, and then we have a little credit card machine hooked up to the vonage box by a phone line. The credit card machine is set on “Dial” to transmit, rather than “IP”. Is this seting PCI compliant? Also, the credit card terminal frequently displays error messages when I try to run cards, and it has gotten worse since all the storms recently. I plan on talking to Vonage on Monday. I’ve already talked to the credit card company, and they were not helpful. It seems that I have to talk to 5 different companies to make sure I’m getting the right story.
When VoIP first came out there were issues with dial devices, mostly with facsimile machines, where they intermittently worked or did not work. It took Cisco and other VoIP vendors a while to get them working reliably. Part of that fix required changes in their software and special configuration options. I am guessing that is the problem you are seeing with your Vonage VoIP appliance. I am not sure what to tell you to get your card terminal to work over Vonage’s VoIP appliance.