Site icon IT World Canada

The VoIP tradeoff

IP telephony, better known as Voice over IP, or VoIP, is one of the most important emerging trends in telecom – for government IT executives as much as anyone. The promise of lower cost and greater flexibility is seductive. As usual with new opportunities, however, there is new risk, and the tradeoff between benefits and risk must be analyzed. For a typical government department that generally has its house in order for basic computer security, the benefits win out and you can deploy the technology today. If, however, you are still struggling to establish an IT security baseline, you should hold off on IP telephony.

Security experts who are fond of doom and gloom scenarios point to the myriad possible attacks that can exploit IP telephony and even coin new terms such as SPIT (spam over IP Telephony), but in the end IP telephony is essentially just another application on your network. If your network and data are secure, you are OK.

But is VoIP really just another application? There are some differences to this application certainly, notably its real time nature and new protocols. In this case the new protocol is the session initiation protocol (SIP) that is responsible for the call processing work. Not surprisingly, the real-time and new protocol characteristics are the items that attract the bulk of the new risk. These are also the areas of major differences to regular telephony, which employs a separate network for call processing signaling and a circuit switched network to carry the voice payload. Along with the higher network performance characteristics demanded by VoIP, there are also issues with ensuring the availability of emergency 911 services (issues beyond the scope of this article).

While you can always find many aspects of IT to worry about in security terms, the biggest threat to VoIP applications is malware such as worms and denial of service attacks. A lesser threat is eavesdropping, in the same way it is a lesser threat for other IT applications. Attacks in regular IT networks are launched against servers, end point PCs and the network itself, and this does not change for VoIP applications. In this case the components are the IP-PBX servers and the end points are either softphones on PCs, or hardware based VoIP handsets. As VoIP deployment increases, attacks on these elements will only become much more common.

As SIP is relatively new, we can expect protocol design and implementation vulnerabilities for many years. Attackers craft and launch exploit code against newly discovered vulnerabilities in extremely short order, so protecting against these known and unknown attacks is paramount for all VoIP components. Fortunately, the protection mechanisms are the same as required for other TCP/IP applications, namely firewalls and deep packet inspection intrusion prevention. These technologies can be deployed at the network boundary, and preferably on the host servers themselves, as network-style implementations of Host-based Intrusion Prevention Systems (HIPS) become available. These implementations in particular have no trouble in meeting the latency requirements for VoIP. Some new compact HIPS agents are also becoming available that can be deployed on the VoIP handsets and softphone PCs themselves to provide maximum levels of protection.

Network-style HIP solutions work extremely well against protocol vulnerabilities because they do something simple but effective – data input validation. Just looking at typical vulnerabilities and exploits for HTTP traffic shows the way ahead, as for example more than 50 per cent of the thousands of known exploits attack data input validation problems. These attack boundary conditions and lead to buffer overflows. This allows the hacker to execute his own code on the server, leading to a total compromise of the host. If that happens, you are in big trouble.

A simple data input validation rule on the HIP agent can address potentially thousands of exploits by normalizing the data so it does not cross a vulnerable boundary condition. While the ultimate fix is to patch software, this can be difficult, especially when you consider, for example, protocol stacks embedded in VoIP phones. If you have HIP deployed with the appropriate rule set however, you are not vulnerable and may continue with normal operations.

The hacker community got a kick-start in targeting SIP vulnerabilities in 2004 with the publication of the Protos test suite from the University of Oulu in Finland. This was the result of a research project in automated testing of SIP implementations. The tool works quickly to identify buffer overflow and other protocol problems.

One response from government to assess and address the potential vulnerabilities in Canada’s telecommunications networks and protocols is the establishment of the Protocol Analysis Lab in Michael Binder’s organization at Industry Canada. The lab is headed up by Bill McCrum, and among its responsibilities is to analyze newly discovered vulnerabilities in SIP and related mitigation techniques, in collaboration with industry and government partners. The lab is currently investigating HIP technology as a potential compensating control to mitigate new threats. It is also interesting to note that the SIP protocol is now extending into some Instant Messaging applications, so this protocol and its applications will have far reaching impact.

The real time nature of VoIP introduces another set of concerns, primarily around the quality of service (QoS) issue. QoS is very important for voice communication; latency and delay variation have a devastating impact. For latency, anything over 150 msec delay produces objectionable echo, and delay variation creates jitter. The QoS problem is really affected by these issues in a lower bandwidth setting. Because of the real time requirement, VoIP does not use the reliable TCP protocol for payload delivery, as it does not support the latency requirement. Instead, VoIP uses the unreliable UDP for transport, but this protocol does not guarantee packet delivery. Because of the susceptibility to latency, a denial of service attack has an easier job in disrupting traffic to the point of voice being unusable.

Network audits and engineering can address QoS issues and ensure that your network can handle VoIP service. Particular attention must be paid to firewall and deep packet inspection configurations to make sure they don’t introduce too much latency, and issues such as NAT and IPSec implementations may be problematic here.

The test case for security of VoIP is the softphone. Given the requirement to leave UDP ports open, the PC must have a strong firewall; it should really be a strong HIPS implementation. Another softphone security issue that can’t be totally controlled is user behaviour. While servers and IP phones don’t double click on attachments, users will still find a way to override policies and run something dangerous. This risk is no worse for VoIP over a standard data environment, but it is something else to be aware of.

Encryption sounds like a very sensible approach to VoIP, but it must be implemented carefully if at all. While the encryption algorithms can be configured to operate with only a 1 bit delay, they introduce error propagation so that a single bit error wipes the entire packet. The companion message authentication piece that is often implemented with data encryption causes the major delay impact, however, as it needs to buffer a large block size before the message authentication check can occur. While nice to have, encryption makes VoIP even more intolerant of packet loss as it affects QoS.

In conclusion, if you have achieved an acceptable level of IT security, and have deployed modern technology for firewalls and IPS, you already have the protection you need for VoIP. While new, the SIP protocol is very similar to HTTP, so the tried and true techniques for web security work equally well for VoIP. 054969

Brian O’Higgins (brian.ohiggins @thirdbrigade.com) is CTO of Third Brigade, an Ottawa-based security company that provides host-based intrusion prevention solutions.

Exit mobile version