VoIP Security Concerns

Voice over IP is an alluring goal for I.T. departments. They promise the ability to rid the department of expensive duplicate networks for data, ease the administrative burden for when users change, and lets not forget provide flashy new features like a color touch lcd display.
In that eagerness to grab the promised cost savings of VoIP it is important not to run past security considerations. NIST recently released a recommendations guide for VOIP.
Their starting guidelines are:
1. Separate voice and data on logically different networks. Different subnets with separate RFC 1918 address blocks should be used for voice and data traffic, with separate DHCP servers for each.
2. At the voice gateway, which interfaces with the PSTN, disallow H.323, SIP, or MGCP or Megaco/H.248 connections from the data network. Use strong authentication and access control on the voice gateway system, as with any other critical network management component. Strong authentication of clients towards a gateway is often very difficult. Here, access control mechanisms and policy enforcement may help.
3. Use firewalls designed for VOIP traffic, through either ALGs or Firewall Control Proxies. Stateful packet filters can track the state of connections, denying packets that not part of a properly originated call. (This may not be possible/feasible, when multimedia protocol inherent security or lower layer security is applied, e.g., H.235 Annex D for integrity provision or TLS to protect SIP signaling.)
4. Use IPsec or Secure Shell (SSH) for all remote management and auditing access. If practical, avoid using remote management at all and do IP PBX access from a physically secure system.
5. If performance is a problem, use encryption at the router or other gateway, not the individual endpoints, to provide for IPsec tunneling.
The full article is definitely worth a read. Those are general recommendations having to do with VoIP. There are also problems with SIP the communications protocol used by VOIP phones as well as problems with specific implementations.
After reading that article, I did some googling and found some interesting articles.
The first link is from Sys-Security. They are a cool group that I respect.
http://www.sys-security.com/archive/papers/The_Trivial_Cisco_IP_Phones_Compromise.pdf
They talk about configuration vulnerabilities due to the use of TFTP amongst other things.
Cisco’s rebuttal is at http://www.cisco.com/en/US/products/hw/phones/ps379/products_tech_note09186a00800e251b.shtml
The second link is from British tech website, the register.
http://www.theregister.co.uk/2004/02/20/cisco_voip_kit_open/
Cisco hadn’t responded in time for the register article above. They respond in http://www.theregister.co.uk/2004/03/05/cisco_dismisses_voip_snooping_concerns/ where some security steps are detailed.
http://www.cisco.com/en/US/products/products_security_advisory09186a0080094ac6.shtml
http://www.securiteam.com/exploits/5HP0O0U75Q.html
I think that it is possible to deploy VoIP on an internal network in a secure fashion. However, security concerns must be addressed. Vendors should assist companies in implementing a secure solution. After all we are all plenty busy trying to keep our computers secure. We dont need to add phone patch management to the problem list.