VoIP & UC
47
VoIP is an application that can be exploited just like
By Paul German, CEO, VoipSec
www.voip-sec.com
web and email, so we need to use tried and tested
security architectures to ensure security
Voice has now become just another application in our data
centres. From a user perspective, we have moved away from
having dedicated appliances delivering voice services, to
having servers installed in data centres running applications
delivering not only voice, but video and presence services; all
of which enable us to communicate more richly with our coworkers, partners and customers.
In contrast, while voice has become just another
application, the security industry has fallen behind with
ensuring that this new application is secure. There seems to
be confusion over where the responsibility for the security
role should lay; is it with the VoIP and UC vendor, or should
it be left to the security functions who provide policies and
procedures for all other network applications?
In reality, we made this decision a long time ago, when as
an industry we started deploying email and web applications
to again deliver a richer level of communication both
internally and externally. The vendors of these web and email
applications took security into consideration, but their main
focus was always on the primary function of their application
server. The initial lack of focus on the security function
resulted in new attack vectors being exploited in ways that no
one had anticipated.
Applying dedicated solutions
The rise in breaches led to quick recognition that firewalls
providing network access control were not sufficient to protect
these applications. Mainly due to the fact that sources of
communications were not always known, so open rules had
to be used which in basic terms removed the very function
the firewall was trying to provide. So, security vendors – many
of which were start-ups – stepped up and started to deliver
dedicated solutions that would provide targeted security
for each of these applications. The enterprise network
architecture was also updated to include a sanitisation area
for these applications, which we have all come to recognise
as a DMZ.
In parallel, as they were both learning from their
customer breaches and their own research, these security
vendors started to provide regular updates to their security
applications, enabling them to provide their customers with
the latest updates to protect against common threats. This
has now come to form the basis of the ‘defence in depth’
security models we use today. And although we’re seeing
this model adapt to new ways of delivering applications, the
very premise that we build walls with firewalls and inspect our
applications flows with proxies, very much remains.
So why is it that with voice we see many deployments
where security hasn’t been considered? Or on the other hand,
that deployments where security has been a consideration,
they have utilised encryption as a way of securing voice?
Surely any security professional would call this into question
immediately as it’s well known that encryption provides
privacy of data, not security. Why have we not adopted the
same model we use to secure our web and email applications?
The reason is that the convergence of voice onto the data
network has left a security gap. Security teams don’t really
understand the threats associated with VoIP, and take the
lead from the team deploying the VoIP application. In short,
history is repeating itself but we’re failing to learn from what
we already know.
The other aspect is that vendors and service providers are
making statements around the security of an application or
service being deployed, which insinuates that security is taken
care of. Many of the SIP trunk providers today make these
wild claims, when in fact it’s a risk to both them and their
customers. A customer would never trust a service provider
delivering any other application, so why VoIP?
In control of security
VoIP is an application that can be exploited in the very same
way web and email, so we need to use the tried and tested
security architectures to deliver security in the same way.
We also need to look at what these security vendors are
deliverin g. Is it static security or does it work like a web proxy
or email proxy in that the security policy can be defined,
updates are regular and alerting is enabled? Also, are there
additional features that allow specific threat vectors to be
addressed, and is it in the control of the security team, the
network or application team?
We have seen the rise of the Session Border Controller
(SBC) as a VoIP security function, but this is a product that is
fast showing its weaknesses when it comes to security. Having
been originally created to solve interworking issues between
carriers, we have latterly seen bolted on functionality that is
positioned as security.
Those who remember will recall that firewall vendors took
this approach to solving the web and email security issues,
and experienced the same issues we are seeing with SBC’s
and VoIP today. They failed, and it was a new range of startups who addressed the issue differently that won the day.
Changing the approach
With VoIP and UC we need to see the same mindset change
occur. Those responsible for business security need to adopt
voice as just another application, around which they are
building security policy and procedure that delivers a robust
enterprise wide security posture. Breach data is readily
available, and clearly shows how high the overall cost to the
business is. The difference with VoIP is that the typical breach
does not only come with data leakage or downtime; it comes
with a direct cost that has to be paid irrespective of where the
fault lays.
Customers should be looking at ways to secure their voice
application with a dedicated security function providing
all the features we expect from our web and email security
solutions. Anything less is leaving them wide open to costly
and time-consuming breaches. n
www.networkseuropemagazine.com