While businesses have been protecting their IP networks for data communications for many years the idea of using the same networks to transport voice has suddenly presented a whole new set of challenges. VoIP can undoubtedly deliver huge advantages, but doesn’t come without its challenges. In fact, it’s a hugely underestimated issue and it will probably take a few nightmare cases of VoIP security breaches to hit the headlines before it is recognised as major business pain point.
Just like traditional data traffic however, voice too carries sensitive corporate information; arguably the most sensitive kind of all. Moreover, as voice is a real time application, it’s simultaneously more critical and more vulnerable.
As a result, the consequences of a successful attack on a company’s voice network may be more serious and damaging than one on its data. A delayed email or a slow browser is one thing. A dropped, time-sensitive conference call or wholesale voice communications failure is quite another.
Vanilla VoIP uses the public IP network to transmit voice data and that means it’s exposed to the same risks as other kinds of data. SPAM for instance, has a VoIP counterpart – SPIT (Spam over Internet Telephony) and specialist VoIP viruses and worms are already on the way.
No physical access is required in order to tap into and or manipulate VoIP feeds. Nefarious parties can not only listen into and record calls, they can potentially even ‘filter out’ sections of conversations and replace it with content of their own.
But probably the greatest current threat is the Denial of Service (DoS) attack. Using a specially prepared SIP packet, the DoS attack is every administrator’s worst nightmare and, unchecked, can put an entire corporate network out of commission.
In short, VoIP carries no guarantee of privacy or maintenance of service unless appropriate security measures are put in place. So what’s required? What are the key prerequisites for a secure VoIP infrastructure?
First, companies should choose their VoIP suppliers carefully; only a very few can claim to offer the kind of breadth needed to implement truly secure voice and data transmission. Then, an advance analysis of the existing infrastructure will be needed to determine if it is suitable for conversion to VoIP - as not every network is. This is done by evaluating the behaviour of the ‘securest’ and ‘furthest’ terminal device distances on the network. If, for example, the time needed to encode / decode the voice feed (or the generally anticipated packet propagation) is too bandwidth hungry, it might be necessary to consider deploying less-stringent security in less-sensitive network locations and vice-versa.
It’s also prudent to include an evaluation phase in the roll-out – migrate a less business-critical area first, noting and learning from any problems and then applying these lessons in later phases.
The first practical move towards robust voice network security is the logical - as opposed to physical – separation of the voice network from the data network through the creation of two or more virtual LANS (VLANS). This means that voice and data are still running across a single network, but are in effect separated.
This makes it much more difficult for internal attackers to access voice traffic and makes it possible to circumvent or at least reduce some throughput rate problems.
The next step is to establish a ‘virtual’ end-to-end connection within the network so that field and home workers can still gain access, but across a connection that is able to withstand the kind of threats outlined above. This underlying infrastructure must also be capable of handling the demands of the real-time VoIP application.
Existing VPNs (Virtual Private Networks) can be utilised here without imposing further burdens on the existing architecture such as firewalls – creating a secure ‘Voice over VPN’ (VoVPN) connection that ensures the security of IP voice traffic between connected points.
Such VPNs must however be properly optimised for use in a VoIP environment. Where the VPN has been designed exclusively for transporting application data the connection will have only limited tolerance and resilience. Transmitting voice data down this connection will naturally place a much greater, multi-level demand upon it and the VPN’s robustness will have to be beefed up accordingly.
To avoid persistent negative influence on voice quality, voice packets – such as (S)RTP (Secure RTP) and SIP(S) (SIP Secure/SIP over SSL) traffic – must be able to pass through the VPN tunnel with as little hindrance as possible. Disturbances typically include packet loss, latency and jitter.
Parallel to this, the flow of data has to be prioritised. It is likely that data besides the voice packets data such as HTTP and SMTP traffic will also be moving across the connection too. If this traffic isn’t given an appropriate order of priority then voice delays, echo effects, annoying crackle and even total outages may result – completely unacceptable in a real-time application such as voice.
To ensure optimal VoVPN functionality, the use of multi-level QoS mechanisms at tunnel points and within the network is indispensable and VPN gateways, routers and switches must be capable of handling these features.
If there are no plans to provide an option to dial-out to the PSTN for non sensitive calls, carrying all voice traffic across the VPN will have an impact on operational stability and the lay out of the VPN will need careful consideration. Smoother transmission within the public network can be further supported by enhancing the carrier and ISPs with special ATM functions or through the use of MPLS.
Keeping IP voice traffic out of harm’s way extends beyond the network. The access devices such as IP telephones or soft-clients and the connection between them and the network, also need to be secure. This can be accomplished with protocols like SIPS and SRTP, but they’ll need terminal devices and / or VoIP applications that properly support them.
Beyond this, SSL certificates come into play. Here, the terminal device contacts the SIP registrar and the encryption depth is then negotiated on the basis of the server's certificate – most commonly using a 128-bit encryption algorithm. Public encryption codes, or keys, are then exchanged (Public-Key-Procedure) after which the device must then be authorised by its host network before voice data transmission can begin – encrypted with the public keys.
Other elements must also be considered, such as wireless LAN telephony, which will need protecting with additional wireless security protocols such as WPA Enterprise which authenticates the terminal device against a central registry, such as a RADIUS server.
It is clear that many effective techniques already exist for protecting VoIP infrastructures against internal and external attack. But these counteracting measures must be properly implemented and maintained in order to work effectively. This is the responsibility of manufacturers, service providers, integrators and systems dealers – so, it’s important to choose wisely.
Equally obvious, but just as underestimated, is the matter of user awareness. User organisations need to know that there is a potential hazard to their VoIP system before they can do anything about it. If you don’t know there’s a threat, you can’t possibly protect against it.
This perhaps, is the most important underlying point of all where VoIP security is concerned. Security rarely functions properly when treated as a plug & play process. Instead, it deserves comprehensive, competent counselling – and VoIP is far from being an exception.