SecurityView: Hype over VoIP

COMMENTARY: In the perimeter security world at the moment there’s considerable hype over the impact of Voice-over-IP (VoIP).

A number of security pundits have come out with claims that VoIP is the newest security frontier, the newest challenge for the perimeter security world.

That means that people like us (at Network Box) get calls from prospective customers and channel partners asking if we can address these ‘VoIP security problems’.

It’s also sufficient to provoke certain vendors (who shall remain un-named) to a frenzy of press releases, claiming to solve all sorts of problems.

There are three important issues that customers, vendors and channel partners all need to consider.

Issue number one: many of the problems don’t exist. Issue number two: most of the problems that do exist are design problems. Issue number three: many are caused by the vendors themselves!

First, it is true that there is a real risk that VoIP enabled devices become targets for attack. This is mostly because by default, they have every feature turned on (web servers, tftp, etc.).

In fact, the very suggestion of plugging a VoIP phone into the internet or a LAN suggests it would be a mistake to assume that the vendors of these devices are interested in security at all.

But that’s not a VoIP problem, that’s a configuration and design problem — phones should be on separate VLANs or their own physical segment, and the extra socket in the bottom for the PC should be disabled.

Softphones should be controlled as part of an SOE and pre-configured to only connect to the VoIP server (if they’re on a laptop, only via a VPN).

But the right place to solve design problems is not at the perimeter!

Second, inter-VoIP calls/connections (either through VoIP providers, or direct server to server) should be controlled like any other connection — with strict rules. In order for many vendors to successfully deploy VoIP and reduce the number of issues they might encounter, they take the path of least resistance.

By default, phone handsets and VoIP servers are set to do ‘native bridging’, so when a call is made, the phone talks to the server, which contacts the destination, and then hands off to the phones so they are talking directly to each other — this is basically identical to P2P, hence the problem (and the security risk).

But native bridging is optional. Much of the VoIP risk can be controlled by putting phones on their own segment, and not allowing native bridging. This means that all calls are forced through a (patched and updated) server, and the phones are not at risk.

And when the calls go through the server you can do things like IDP/firewall and content scanning. Again, this issue not a problem with VoIP, it’s an issue of design.

Parenthetically, Network Box’s own international VoIP system only runs via VPNs, and is regulated with firewall and other controls. While it’s true that VoIP has the potential to become a vector for things like viruses and worms, just as P2P systems have done, it just hasn’t happened yet.

Lots of things that could happen are unpleasant, but that doesn’t make them a problem — at least not yet — and there are enough actual problems to solve without working on potential ones!

There was a time we only did virus checking on SMTP (some still do) but nowadays it’s SMTP, POP, IMAP, FTP, HTTP, and so on. Adding VoIP to the list won’t kill us.

If you have good design and configuration of your VoIP system and good perimeter security, then as a general comment you’re in great shape.

Most people don’t and that’s the real problem — not VoIP security. The sky(pe) hasn’t fallen yet.

Andrew Tune is a director at Melbourne-headquartered MSSP Network Box Australia, which has been providing fully managed UTM systems for more than three years in Australia.