In an effort to cut costs, my company has decided to migrate from private branch exchanges to IP telephony. By routing calls over our existing IP network and using voice-over-IP links, we can significantly cut our telecommunications costs, especially since we have significant telephone traffic between our U.S. offices and places like Europe and India, as well as other parts of Asia. The bottom line, however, is that we'll have phones on our desks that are connected to the network. And that means securing the telephone network will become my problem.
The thought of IP traffic with voice traversing the network bothers me, since our network isn't as secure as it could be. So I conducted an assessment of the major pieces of the IP telephony infrastructure. Since my exposure to IP telephony has been limited, I started by reading up on the technology. Most of the vulnerabilities discussed focused on the ability to either intercept network traffic or conduct impersonation attacks -- manipulating a phone call so that it appears to come from someone else.
Since I didn't have a lot of time, I didn't focus on denial-of-service attacks, which we can address with our regular network gear. For example, we use Cisco Systems Inc. network equipment, which includes several self-defense features within the operating system to address most DoS attacks. In addition, we will most likely deploy an all-in-one device to mitigate the threat posed by malicious code. Fortinet Inc. in Sunnyvale, Calif., has a very appealing product that we're considering deploying. This device not only addresses malicious code, but also supports firewall, VPN and intrusion detection and prevention functions.
To conduct my tests, I created a scaled-down version of the new IP telephony system. The setup included several IP phone models, a call management server and some networking gear. I started by testing the network over which the voice traffic must flow. I first attached my Linux laptop to an available Ethernet port to see what I could monitor using the free dsniff and ethercap tools.
Once I recorded some network traffic, I downloaded and compiled a tool called Voice Over Misconfigured Internet Telephones, which goes by the horrible acronym VOMIT. This program can take captured IP telephony packets and reassemble them into a form that you can play back over your computer's speakers. The IP phones from which I gathered the voice traffic don't support encryption, so I could easily play the conversations. Using handsets that encrypt traffic will be a requirement. We'll also require that IP telephony traffic be separate from our regular data traffic. We'll do this by creating separate virtual LANs on our network switches. By segregating the traffic in this way, we can thwart users on the data VLAN from sniffing voice traffic.
In addition, we will add firewall rules that limit access to the critical IP telephony devices to only the required IP addresses. For example, if managers are on a separate VLAN, we can craft rules that state that only certain users can obtain management access. We could further lock down the network by restricting the traffic so that only the IP phones can contact a manager.
Another aspect of IP telephony is the PC phone, or "soft phone," which lets any PC with a headset or microphone and speakers work like a regular telephone. Until we address desktop firewall and patch management issues, however, we'll restrict users from using these applications.
Next on my agenda was to assess the integrity of the centralized communications server, or call manager, which sets up and manages phone calls. IP phones initiate a call by contacting this server. While the call manager plays a role in setting up calls, once the connection is established, the phone conversation occurs directly between the two IP phones over the switched IP network.
The communications server software we'll most likely use, Cisco CallManager, runs on Windows 2000 and Internet Information Server. That's not the ideal system for a critical infrastructure, but Cisco claims that the Windows implementation has been hardened, that unneeded services have been disabled and that there is even a host-based intrusion-detection system installed on the server.
If I could hack into CallManager, I figured that I would own the entire phone system. For this test, I ran a combination of Nessus, a freely available port scanner, and WebInspect from SPI Dynamics Inc. in Atlanta to conduct a comprehensive application-layer assessment. To my surprise, both assessments identified no critical vulnerabilities. Then again, my test represented an assessment for only a single point in time. More testing will be needed, and patching will be critical. As soon as Microsoft announces the next Windows vulnerability, if the call management server isn't patched, it may then be possible to gain access to it.
Cisco and the vendors we approached all claim that they keep up with all patches and security issues and provide regular updates to the operating system and their software.
This was just my initial look at some of the main components of the IP telephony infrastructure. I still need to address DoS issues, and we have to take a hard look at the architecture of the entire IP telephony infrastructure. Several other tests we conducted provided a comfortable level of assurance that we can deploy a secure IP telephony system.
For now, it seems possible to deploy IP telephony in a secure manner with the proper architecture and planning -- and by taking advantage of the available security configuration options of the devices.
What do you think?
This journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org, or join the discussion in our forum. QuickLink a1590. To find a complete archive of our Security Manager's Journals, go online to computerworld.com/secjournal. -- Computerworld (US)
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.