October 23, 2008, 8:27 AM — Knowledge on security issues is a two-edged sword. Knowing enough of security will empower you to make right choices. But knowing too much can make you paranoid. So what, if all VoIP systems can be broken into? Or can they? Or do you really want to know?
Some people argue that you should not care about VoIP issues unless they impact your own VoIP deployment. With this thinking, why would I care about Microsoft problems as a Mac user? The answer is simple: I am in the security business, so I should know about security issues in any platform. If you are in VoIP security business, your job is much easier as you only need to know about VoIP security issues in any architecture and platform. Knowledge about vulnerabilities in one specific domain will help you analyze similar flaws in another domain. No tool can do that for you. It is not only about knowledge of issues, but how you use that knowledge to find new issues.
Building a VoIP architecture does not start from security mechanisms, but user requirements and budget. Although people keep saying that security is not an add-on, it really often is. But it needs to be added at the right time. Not all VoIP architectures need any security (mechanisms). The right choice of products, protocols and network architectures can take you a long way before any VoIP security solutions need to be added (if ever).
So back to the original question(s): How do I build a cheap (free) but still secure (enough) VoIP deployment?
The most common method of deploying VoIP in an Enterprise environment is using softclients, VoIP terminals running on a PC. The VoIP server can be running any open source VoIP gateway such as Asterisk or SER. The cost? Zero. Sounds attractive?
The security threats in such a simple VoIP deployment are really quite easy to enumerate:
- VoIP client has a vulnerability(Probability 100%)
- VoIP server has a vulnerability(Probability 100%)
- The PC has a vulnerability(Probability 100%)
What? That is not a threat enumeration! You are right... Let's try it the other way around:
- VoIP client has a vulnerability, with an exploit in the wild(Probability 100%)
- VoIP server has a vulnerability, with an exploit in the wild(Probability 100%)
- The PC has a vulnerability, with an exploit in the wild(Probability 100%)
We are not getting anywhere with this, are we... ;) One final time:
- VoIP client has a vulnerability, which will be exploited by someone(Probability ?%)
- VoIP server has a vulnerability, which will be exploited by someone(Probability ??%)
- The PC has a vulnerability, which will be exploited by someone(Probability ???%)
There are quite many influencing aspects in this... How can we block the exploit if we do not know about it yet? We are not going to block access to VoIP, nor to the PC's, so the perimeter defense approach is out of the question. Nobody believes in IDS/IPS anymore, so that does not help. Can we learn something from other Enterprise applications? Let's list some of them and see what is in common with VoIP:
- Email is not really peer-to-peer as the email clients access the Enterprise server and do not have any direct connections between client implementations. Otherwise, we know that all email clients are broken also, and are really careful to enforce which email client can be used in the IT infrastructure.
- Web Browsers are equally broken, but at least there are couple of browsers that most people tend to trust. A Browser is a bit more problematic to secure as it has to be able to connect to anywhere anytime. You can proxy outgoing web traffic, therefore limiting the attack surface.
- Instant Messaging is almost peer-to-peer, and probably why it is also banned in most Enterprise networks. It is possible to implement Enterprise IM using centralized messaging servers, which enforce access control. At least you know who attacked you if that happened.
Can we learn something from these? Yes. Enterprise networks need to enforce authentication (check, done in VoIP). They also need to control the traffic flows from outside into the Enterprise (check, let's use IP-PBX as the only route in), and from the Enterprise to the outside world (check, a proxy is in place). The used software has to be accepted by the IT staff, and security policies need to be enforced (check, softclients are installed and administered by central IT).
That sounds too simple to be true? VoIP is just like any other Enterprise Software. You need a security policy for VoIP, and enforce it. The most challenging task is selecting the right piece of software for the task at hand. Unfortunately that is not the easiest task for VoIP currently. Want some recommendations? Let's see if I have some for the next post, here in ITworld...
