Unified communications: Securing a converged infrastructure

With so many different systems combined, it can be tough to know where to start when it comes to unified communications security. In this video, John Burke explains the basics of securing this new type of infrastructure.

About the speaker:
John Burke is a principal research analyst with Nemertes Research.

Go back to the Unified Communications Security School lesson.

Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact editor@searchsecurity.com.   

Unified communications: Securing a converged infrastructure

Billy Hurley: Hello and welcome to Unified Communications and Messaging,
Securing the Converged Infrastructure. With guest speaker John Burke.

If your company is like most enterprises, you have a number of disparate
communication systems that don't always work well together. But many
organizations are now working to integrate email, instant messaging,
desktop and mobile telephony and video conferencing in order to build a
singled unified communications environment. Though they can increase
productivity and cut costs, unified communications environments present
a new set of information security challenges.

Today's webcast will cover the basics of how to securely design and
deploy the new age communications infrastructure. We'll address the
technologies and protocols that you'll be working with. The threats
that are both here today and looming on the horizon. The challenges of
securing unified communications on different levels of the network. And
finally, the guidelines you need to outline the best communications
security strategy for your organization.

Our speaker today, John Burke, is Principal Research Analyst with
Nemertes Research, an independent technology research firm based in the
Chicago area. John has experience working in nearly all levels of IT,
from end-user support to network architecture. Since beginning his
career at the Johns Hopkins University, he has become an expert in voice
and data networking, administration applications support and central
systems management. At Nemertes, he specializes in technology
management and information stewardship.

Thank you for joining us today, John.

John Burke: Thanks very much, William. We will be talking today about
unified communications and messaging, securing the converged
infrastructure. On our agenda today we'll first be throwing a net
around what we mean by unified communications. After we've covered
that, we'll discuss what unified communications implies for the security
of your enterprise. What are the risks? What are the threats? And
then we'll move on and talk about how to address and where to address
security for unified communications.

So, what do we mean by unified communications? In decades past, the
enterprise has had to embrace and learn to deal with different
collaborative technologies. Starting with voicemail and audio
conferencing in the '80's, and moving into email in the '90's and
more recently, encompassing also things like instant messaging and web
conferencing and the evolution of voicemail and email unified messaging.
So, taking voicemails and potentially faxes and piping them into the
same system that handles email.

So, taking all of these applications, unified messaging, instant
messaging, web conferencing, audio conferencing, throwing in
desktop-to-desktop video and video conferencing and building that all on
a base of present. Present being the ability of applications to know
where the user is and how the user prefers to be communicated with. Tie
all those things together; you have what we call unified communications.

And these are best instantiated or best embodied in a kind of products
called a real-time communications dashboard, one that serves as a
single interface to all these different kinds of conferencing and
messaging and that serves as the control center for present. That
allows the user to say where they are, where they will be and how they
prefer to be contacted by others. Whether they want to have instant
messages. Whether they want to have voice messages. How they're likely
to reply when they receive them.

All of these technologies can be implemented in vendor specific ways and
the protocols vary from vendor to vendor for all of them. However,
there are good established standards out there. For instance, for email
and now for real-time communications like telephony and video
conferencing as well, the standard that's out there that's most widely
implemented, and its implementation is rising and spreading most
quickly, is SIP. The session initiation protocol. Clients are widely
available from a variety of vendors.

Even vendors who have their own proprietary standards for such an
initiation and control of voice or video conversations now typically
also implement SIP. And in some cases, have already defined the
timeline by which they will replace their proprietary strategies with
the standard spaced approach.

When you take SIP and you extend it to handle instant messaging and to
handle present and to use the information that presents provide, you
have the SIMPLE protocol. Which competes to some extent with a protocol
called XMPT, an XML-based present leveraging switchboard kind of an
interface. But, these provide the method to integrate instant messaging
into the same session hierarchy as SIP provides for voice and for video
communication. And to some extent, SIMPLE and SIP provide the glue that
allows all these disparate communication channels to be pulled together
and brought into a single interface and a single planning paradigm for
unified communications.

And they also provide the method by which these unified communications
mechanisms can then be integrated with other parts of the enterprise
infrastructure. In some cases, that will be by equipping applications
with the ability to speak SIP, in essence. To start a phone call or an
instant messaging conversation based on activities inside, for instance,
your enterprise resource planning package, your ERP system. Or you
customer relations management package, your CRM system. You add a new
customer to the database and the back-end application can then initiate
an instant messaging session. Either with the application talking to
the customer service representative or the agent who's going to be
responsible for that client, or directly between the client and the

These uses allow applications to communicate with people and people to
communicate with applications. They also enable
application-to-application communication directly. And so, for
instance, instant messaging becomes another potential communications
avenue between applications on different systems.

Looking at the same issue from the flip side, makers of call servers and
IP PBXs now also are putting web services interfaces onto their
equipment and onto the software stacks on those pieces of equipment.
[Via] is a good example here. So that they're exposing all of their
voice and conferencing applications as services within a
services-oriented architecture. And so, they provide a means by which
applications can reach out and take advantage of those services.

And the goal here is to break down the barriers between the applications
that people use to manage all of the information of the institution and
all of the applications that they use to communicate with and
collaborate with each other and with the clients and customers of the

So, with this in mind, we need to talk about how to secure unified
communications. What are the threats and what are the measures to take
in securing against those threats.

And in case we passed over it a little lightly as we discussed the fact
that we're integrating all means of communication with all other kinds
of software in the enterprise, the stakes in the game are your desktop,
your laptop, your enterprise applications platform and your data
network, both LAN and WAN. When you move communications onto the data
network, you integrate those applications with each other on the
desktop, the laptop and through standard interaction with your
enterprise systems on the back-end. Then, essentially, you're saying
that the security profile of the unified communications is the security
profile of your entire institution, your entire enterprise.

What are we looking at? We're looking at the low-level network. We're
looking at security on your higher-level communication systems, like
email and instant messaging and the security things you're already doing
there. And we're looking at addressing the new security issues raised
by voice or raised by SIP and SIMPLE. And the fact that they're being
used to tie things together. There is no magic box that you'll drop
onto your network and secure unified communications. There are things
you will have to do specifically to address communication, but you can't
secure that without securing the environment generally.

So what are we securing ourselves against? What are the threats that
we're fearing? Well, the first thing we need to talk about is the fact
that all of these threats are things that we face both from the inside
and from the outside.

In the past, if people wanted to tap your communications, it almost
always meant sending somebody into a building and putting a physical tap
or a physical microphone on a piece of equipment in the place where they
wanted to tap things. Now that's no longer the case. And we are
talking about the ability to compromise communications security anywhere
inside the corporate network and from outside the corporate network
without ever having physically to be present inside the enterprise in
any way. And we'll touch upon that point again and again through the
rest of the presentation.

With that in mind, the things that represent security threats
specifically for communication are denial of service. And here, you're
up against the kind of denial of service that you haven't been
previously when your communications network was entirely separate from
your data network. And when the protocols were specific to telephony or
specific to video conferencing, there was little chance that anyone
could or would be able to mount an attack specifically to deny you the
ability to use your telephone. Or your ability to use your video
conferencing equipment.

Now that it's all running across the data network and there are standard
protocols available by which to establish communication, the possibility
exists to mount denial of service attacks against the call servers that
actually manage the phone calls inside the enterprise. The PBXs. To
mount attacks against voice gateways that service the interface between
enterprise IP networks and carrier voice networks. And even to attack
phones. To mount the denial of service attack against all the phones or
specific phones within an enterprise.

There's also the threat of eavesdropping. Again, no longer requiring
physical access to a phone or even to a phone line. But only access to
a compromised laptop or desktop somewhere on the same enterprise LAN.
And here, people are worried about unauthorized call capture. So,
somebody sitting themselves in the middle of an IP phone conversation
and just listening in. That can happen from inside or outside. They're
also interested in and worried about a new level of eavesdropping threat
that comes only with IP telephony. And that is remote activation of IP

When you look at a telephone on your desk, an old-style telephone,
you're looking at a dedicated piece of equipment that has, basically,
its instructions hard-wired into it. Has firmware or is hardware. And
that has an on/off switch in the form of the hook. When you put the
phone down on the hook, it's cutting the current to the handset. It's
cutting the current to the microphone in the handset. And so, you can't
use the phone.

However, if the phone on your desk is an IP hard phone, it's not a
phone. It's a computer. It's running an operating system. And that
on/off switch that you think the hook represents when you put the phone
down, isn't an on/off switch. It's just indicating to the telephone
that you're hanging up the phone. It doesn't actually cut the current
to the handset.

So, that possibility now exists of remotely activating the handset and
listening in to what's going on in an office. Even when the phone is
hung up and appears to be offline. Again, the indicator lights that say
line active, line not active, controlled by software. Compromise the
software, gain the ability to turn that light off. Even when the phone
is active. Or activate a speakerphone the same way.

So, eavesdropping. All the old dimensions plus the new one in the
unified communications enterprise.

Toll fraud. Always a problem and now a renewed problem. Because,
again, you run the possibility of compromise from inside or from
outside. And you also have a new level of threat, which is the
placement of rogue telephones. In a TDM environment, that's pretty much
not possible. The phone jacks have to be turned on. The PBX has to be
told the phone is there. And nothing will really happen if both ends
don't agree on things. But in the IP telephony environment, if you can
plug a device into a jack that has the voice VLAN on it, you can start
to use that VLAN. And if you can worm your way in, using the entire
telecommunications infrastructure of the company from an unauthorized

Vishing is another concern. That's the voice over IP supplemented
phishing attack where, specifically, the bad guys will fake, for
instance, caller ID information. So that they'll call the phone. The
phone will say, "This call is coming from Tech Support," and then
they'll try and get you to answer questions you shouldn't answer about
usernames or passwords or other kinds of security information. Or go
straight to trying to get identity information from you. Social
Security numbers or other things.

And this is an actual concern that some of the people we have
interviewed in our research have run into. They have run into vishing
attacks more than once in the past year. And, of course, you run the
risk overall of platform compromise with unified communications.
Something you did not run into when everything was separate. And this
is platform compromise both at the systems level, somebody gaining
control of the call server. Somebody gaining control of the gateway and
then using that control. Either to steal services or to steal
information, or both.

But it extends all the way down to the endpoint. If you're running a
softphone, compromise of the platform for the softphone, whether that's
a laptop or a desktop. If you're running hard phones, compromise of the
hard phone. In essence, another computer on the network.

When Nemertes went out in the past year and asked voice over IP and
unified communications professionals, people who are running these kinds
of systems for their companies, which ones of these threats were of most
concern to them, although about a third were interested in and worried
about vishing and toll fraud and eavesdropping, specifically, by far
their greater fears centered on the problems that arise from platform
compromise. Things like identity theft and data theft. And to a lesser
extent, they were worried about denial of service. Because of the
novelty of it as much as anything else. The fact that it was now
possible for them to suffer from a denial of service attack on their
voice communications. Not a possibility in the past.

Happily, though, when we asked them whether they had actually had
compromises on their unified communications platforms, only about two
percent had experienced real compromises. And that's a good thing
because they haven't done a lot to secure their systems yet. So, we're
looking at that number rising rapidly for a while.

That's an important thing to remember. That although there are new
levels of threat here and old threats raised to new levels of prominence
and new levels of danger, the old system wasn't 100 percent secure.
Phones and trunks could be tapped and were tapped. And toll fraud was
always a problem, both from inside and from outside. People making
unauthorized calls or being tricked into making unauthorized calls on
behalf of outsiders.

And that, overall, and more importantly in some ways than all the
technical aspects of voice security, there is the fact that voice
security is a social issue as much as a technical one. When you're
worried about the interception of confidential information by outsiders,
it's one thing to worry about them breaking into your network and
stealing it. But you also need to be concerned about the fact that, as
often as not, somebody who's not in their office is having a
conversation in a place that's not particularly secure. In an airport.
In a coffee shop.

And so, they're not paying attention in a lot of cases, to who's around
them or who can hear what they're saying. Or who can see what's on
their screen if they're using a communications dashboard and they've got
an instant messaging session up or web conference up. And they're
looking at a schematic for a product. Or survey information from their
clients and customers. Are they really paying attention to who's
looking over their shoulder? Are they paying attention to who's leaning
over and listening to what they're saying?

Social problem. And part of enterprise security generally. Part of
communications security. And unified communications security has to be
end-user training and raising the awareness of security use of
technology as well as trying to secure the technologies themselves.

At the moment, most VoIP deployments are still relatively small. The
big ones are in process but they're not complete yet. And, moreover,
they're mostly still islands on the net. They're still talking to the
voice infrastructure via gateways that translate for the regular switch
telephone network and not talking IP directly to their carrier. That's
changing rapidly, though. The number of projects is increasing. The
stages those projects are in are moving from tests and pilots to full
deployments. And it's just a matter of time before they become
complete. And the number of carriers that are offering IP trunking is
increasing rapidly as well.

And so, all these things that have served as unintentional defenses in
the past are fading rapidly. And as that happens and as the things like
AOL and Google instant messaging and voice communications, usually
things like Skype and Vonage, increase as well, the level of threat is
going to increase and increase rapidly on the enterprise.

The other reality that we need to face up to when looking ahead at
unified communications security is looking at a security landscape
dominated not by loners waging attacks for their own reasons. Whether
profit or fun or malice. But instead, people who work together. Both
in real-time collaboration and in a market that exists for security
compromises. People who work together and whose dedicated purpose is
making money out of security compromises. Whether through identity
theft or theft of intellectual property or through extortion. And there
are many well documented cases of enterprises being threatened with
blanket denial of service unless they pay up a certain amount of money.

And there is collaboration amongst the bad guys on building tools. On
discovering and sharing methods of compromise. And on waging actual
attacks. There are people who specialize in developing attack methods.
There are people who specialize in developing attack vectors. Those
armies of the zombie PCs out there. There are people who specialize in
developing the payload to be inserted on systems that get compromised
and on siphoning off data. And there are people who will take that data
and use that to further steal information through phishing, spear
phishing and vishing. And who will turn around and sell identity
information to people who are going to perpetrate identity theft.

There's a whole market for this. There are going price rates for X
number of PCs for use in a zombie attack. For X number of identities
with Social Security numbers attached and so on. A thriving black
market economy. And hundreds of millions or even billions of dollars
annually now going into this economy. So, professional, collaborative
and dedicated to the proposition of profit in one way or another. So,
this is not the security environment in which security defenses
initially evolved. And we need to keep this in mind as we move forward.

So, where do we begin? Well, we begin at the lowest level and the
furthest endpoints. And we begin with the phone. Secure the phone
because it's not a phone. It is a computer. A general purpose
computer running specialized software. And it has a specialized
interface so that it looks like a telephone. But it's a computer. Many
of them run web servers by default, for example, and that runs its own
list of security risks. They have administrative passwords in case you
want to get in and change settings. And that presents a level of
security threat that did not exist with old phones.

If you're running a soft phone, it's even more complicated or less
secure. Because, essentially, you're giving up whatever small measure
of security you might have had from the specializations of the hard
phone and taking on the well-known security profile of the corporate PC.
Which is to say a constantly fought battle to control and close
security problems on that platform.

So, it's essential that you know the platform That you know its
security profile. And that you do what you can at the lowest level to
secure it. And on a PC that means everything you normally do to secure
a PC or a laptop. Firewall and anti-spyware and anti-malware and all
the other security tools you use on your PCs. Keeping your operating
systems patched and all your subsidiary tools patched. Like your web
browsers and your MPEG decoders.

It's just as important if you're running a hard phone to pay attention
to the security profile there. As I say, many of them run web servers
by default. But if you're not in an enterprise that's using those, you
need to turn that off. Most of them have an administrative password so
you can get in and change setting in the software. And that has a
default value as they always do. And a large number of enterprises
never change that default value. As is often the case with default
passwords. And so, that's one that you need to get in there and fix as
quickly as you can as you start to deploy phones in real practice.

Once you've moved off of the platform, you'll need to approach the base
of the network and securing that. And there you have the full panoply
of low-level, layer 2 or layer 3 security that's currently available.
Layer 4 as well. And that will involve VLAN segmentation, for example.

And in our research we found something north of 70 percent of the
enterprises had their voice traffic and their conferencing traffic
segregated onto a separate VLAN. Which is great. It's good for
performance control. And it's good for privacy to some extent.

But VLANs are not in and of themselves a security technology. And there
exist many ways of compromising VLAN separation. Most of them or all of
them require having another node on a switch with the same VLAN. But in
the days of utility compromised desktops, or at least frequently
compromised desktops, securing that kind of a platform with which to
launch attacks against the voice infrastructure is not as unlikely as
you want it to be.

And so, you need to reach beyond VLAN segmentation and enable port
security. And most vendors have some level of port security available.
Most frequently you can, for example, lock a port to a MAC address. Say
that only the node with this MAC address can talk on this port on our
network. It's simple. It's direct. And it's effective. It's not,
again, 100 percent foolproof. But it raises another hurdle.

You can also enable deeper levels of endpoint security. And best of all
would be to enable authenticated network access. So, requiring that any
access to the network, any new device coming online has to authenticate.
Whether it's with a username and password or with a USB token or
something else. Requiring that it verify to a back-end system and
database that it is something that should be on the network and has the
right to use the network.

And whatever other low-level, layer 2, layer 3 defenses you've got in
place, firewalls and filters. You'll need to keep them in place but
you'll need to be cautious about their application to real-time traffic,
voice or video. In that a latency is the enemy of real-time
communications traffic And some devices, especially intrusion
prevention systems, have typically not been well suited to real-time
traffic processing. That may change. The devices get faster and faster
though the use of massively parallel processing. But for the time
being, if you've got intrusion prevention systems in place, you'll want
to make sure that they're not reading into your VoIP traffic too closely
or they will break it up and slow it down to the point where voice
quality degrades dramatically.

And, of course, things just get more complicated when the low-level
network goes from being your fixed static data network and the walls to
your dynamic roaming wireless network. In our research we have found
again and again that big project enterprises are interested in pursuing
with real-time communication After they've gotten them deployed,
getting them deployed over the wireless network. So that they're
available to mobile users on laptops moving around the campus.

And given that wireless data network security is still not terribly
mature and that most people still deploy WEP and WPA security on their
laptops with shared key passwords as the means of authentication, even
though those have been shown to be breakable by concerted attacks in a
pretty straightforward way. Even though they've been shown to be weak
in this way, that's still the most frequently deployed method. And the
best methods, which involve a certificate on the client, are still
little deployed comparatively and significantly more complicated to
deploy in many cases.

Another concern that you don't have as much with your wired network that
you have to worry about with your wireless is rogue access points.
Again, if you've got the possibility of people popping rogue access
points up on your wireless network, they have a platform from which to
eavesdrop on all the traffic that passes through them. If you're not
encrypting your voice traffic at the laptop, hence sending it out
encrypted, then that means that any voice communications or any video
communications could be intercepted in the clear.

And so, a comprehensive solution that address the wireless LAN has to
extend the idea of segmentation via VLAN so that it also separates
wireless from wired LAN and provides a layer of security at that
interface. And that can provide a level of network access control on
the wireless network. Not in the sense of verifying laptops but in the
sense of verifying access points. That it can locate rogue access
points and suppress them and knock them off the network whenever they're

Now, looking upward from the low-level network to the higher levels of
the network's stack, we need also to address security at the session
level. SIP is the session initiation protocol and weaknesses there
represent layer 5 attacks on your network. So, that's above the level
of firewalls and above the level of access control lists and above the
level of intrusion detection systems, typically.

You also have to look at presentation protocols if you're communications
software is swamping around voice traffic in the form of MPEG or if it's
swamping around traffic as the MIME attachment to things. Or that using XML
compromises on those format ways of forcing buffer overflow within the
interpreting software represent layer 6 attacks on your network. And
again, something that's typically out of range for most of your
low-level network security equipment.

And lastly, there are attacks on the protocol of the applications
themselves. HTTP attacks are well known and old now. FTP, SNMP, SMTP,
you name it. All of the high-level protocols that exist represent
vectors for attack for high-level application traffic.

And when the PBX that you're using to control calls is just another
layer of software on your servers, you have to worry about the
compromise of servers via the compromise of any of these protocol level
session presentation or application. When, for example, the Aastra PBX
software that you installed a few months back can be compromised by a
buffer overflow, is it then possible to compromise the whole system as a

What kinds of attacks are we worried about at these levels? Well, it
turns out we're worried about all the same attacks that we're worried
about generically. You can implement a denial of service attack at the
signaling level by attacking SIP weaknesses just as easily as you can at
any other level.

Just last week that a vendor, Typera exposed problems with several
hard and softphones from Avaya, from Nortel, from AOL, from MSN.
Problems that could variously be exploited for denial of service attacks
or for platform compromises. Skype has been showing to have several
attacks and is vulnerable to worms.

The point is that all the things that we worry about generically we have
to worry about specifically for SIP, for SIMPLE and for other high-level
protocols. And we have to implement a different kind of security to
watch for them at these levels. We're not looking at malformed packets
and we're not looking at rogue IP addresses. What we're looking at is
well formed network traffic from IP addresses we don't suspect of being
bad, but that has bad intent.

So, we need to look deep inside the network traffic. We need to do
what's called deep packet inspection to look beyond the headers. And
look beyond the protocol port and into the content of the packets
themselves. And we need to subject that content to analytics. We need
to look at it with respect to what we know about the protocol involved.
And then say, "Does this look like good behavior? Or is this suspicious
behavior? Or is this bad behavior?"

If I get a single request for initiating a conversation via SIP, I'm
just going to let that pass through. But if I get 1,000 requests in a
second and none of them is followed up after the session is initiated
with actual call traffic, well then I know there's something suspicious
going on. And I can start to block traffic if that's what my makers
have made me to do. Or I can flag for the attention of a human. So,
you need protocol analysis based on the high-level protocols like SIP or

And you need to pay more attention to identities. In this world, IP
addresses are no longer really in any way mappable to identities. We
just don't know who is implied by where. And we'll talk about this more
and more throughout the rest of the slides here.

But we need to be able to have a sense of who in order to properly
secure unified communications. And we need to be able to do it no
matter how that data is getting to the point where we're looking at it.
So, we need to not care whether it's coming over vendor specific
protocols at some level. Whether it's coming over MPLS from within our
WAN. Or whether it's coming over IP from the internet. We need to
address things as they come to us.

Another important point is that we need to act. What we're looking at
here really is a variation on intrusion prevention systems tailored to
unified communications protocols. And the key is to act when we see
that something bad is happening in order to defend the system's

A significant thing is that the bad guys have a whole economy for
cooperating in launching attacks including shared attack vectors, like
zombie PC armies, and lists of targets. And on our side of the
equation, we're developing a similar economy in blacklists. So, known
bad IP addresses or IP nets or subnets from which attacks frequently get
launched. That we can then use to pre-filter or to pre-badge
communications as at least suspect, if not simply to be denied.

And this represents a good measure of the rising security profile of
unified communications and also a good measure for furthering the
security of unified communications. If we share the information about
who has attacked us and expect to find more information about who has
attacked other people, we should all be able to raise our common
security profile by sharing that kind of information. You can never
just take it as gospel and block all communications from Finland or
South Korea. But you can take it as a cautionary note to the extent
that it's repeated and one more than one blacklist. And it's been there
for a long enough time.

As I said, ideally, all of this kind of security is going to be based on
identity. And in addition to what goes on with spoofing IP addresses
and spoofing even MAC addresses, the fact that our own users will want
to access our services from outside our enterprise networks and from
inside our enterprise networks, but from different locations all the
time, just reinforces the idea that where is not who anymore the way it
might have been at one time. That IP addresses are not identity. And
that both good security and regulatory compliance more and more require
that you know who is doing things. Who is accessing what within your
institution resources.

And that, ultimately, as we proceed down this road of identity-based
security, we'll be assigning identities and using identities not just at
the user level but also at the system, the application and even the
physical resource level. So that we can really control which systems,
for instance, have the ability to spawn a SIP or a SIMPLE session based
on what that system is. And what it's supposed to have access to.

And, of course, the continuing spread of interconnection amongst
institutions, amongst enterprises means that we need not only to be able
to securely associate security information with a user or a system, but
we need to be able to share that kind of verification and that kind of
information across boundaries between ourselves and other enterprises or
other entities. And there exist protocols for doing that. Directories
and usernames are the most common identity infrastructure. But moving
beyond that, there are now standards out there for exchanging this kind
of information between trusted partners. They connect these identity
islands together.

And this kind of federation will become more and more important as the
supply chains get inter-connected as enterprises continue to outsource
more of their operation and as they work more and more closely with the
systems at other enterprises.

Another important operational point at the enterprise level is that you
need to be prepared to address security problems as they come up. And
one of the worst ways to do that is to keep your security operation
separate from your network operations. Because your first clue at the
human level that something bad is happening might be a call to the help
desk. And if the help desk is not integrated into your security
operation, then security knowing about it will be delayed and possibly
delayed quite a long time. Depending on how quickly people at the help
desk and at the network operations center identify the problem as a
security problem and not just a network connectivity or a systems issue.

The end-user can't tell if it's a network server or a security problem,
necessarily. The help desk, the low level techs at the network
operations center or even the server admin sometimes can't tell that at
first either. Neither can your security people. If somebody did happen
to call security instead of network operations, well it might not be a
security problem. And treating it as one would be a waste of your
security techs' time and not give the user what they need.

And, of course, classifications change through the lifetime of an
incident. What might look like a security problem at first could turn
out to be a network problem, or vice versa. And that kind of switch in
perception can happen several times.

It's better by far to integrate operations at the lowest level so that
your first level security operations and your first level network
operations are the same. And that they share a system for ticketing and
tracking problems and tracking information at the second and third
levels. So that it's never a case of having to shift information from
system to system. But just a matter of flipping a field for what kind
of a problem we're dealing with and flipping the staff member who's
working on it or the staff team.

So, this is important to reduce duplication of effort and wasted effort
which are expensive. And important for streamlining processes and
getting a heads-up on security problems as quickly as is possible.

And lastly, we'll say that policy has to be a key driver for all
security activity. The infrastructure is getting too complicated. Too
many tens or dozens or hundreds of applications on a large enterprise
network to manage everything one at a time and uniquely and by hand.
You need first to have policy about what kinds of security you're going
to require at the highest level. Such as all access from remote sites
must be authenticated. And you need lower-level policies spawned off of
that to address specific details for specific classes of applications or
classes of users.

But most of all, you need to have the ability to drive automated
provisioning and requirements software so that much of this can be
handled by your systems and not by your techs. So, in the face of
complexity, policy and automation are no longer going to be optional.
Especially in the largest operation, they're going to become critical,
essential technique. And as evidence of that, and I'm sorry the next
two slides are slightly mislabeled. We saw that for folks who did have
a security plan for their unified communications, there was a
significant increase in their implementation of that plan.

This first slide labeled "Having a Plan Help" is the before picture. Or
actually it's the general picture all enterprises have. Just under 50
percent of enterprises reporting that they're doing some security at the
device level. And just over 55 percent, 57, saying they have security
at the network. Fifty-five percent minus a bit at the application
level. But when you look just at the folks who have a plan for mobile
security in place, those implementation rates rise anywhere from 5
percent on applications to nearly 10 percent on networks.

So, having a plan, having a mobility strategy that encompassed security,
raised the security profile at those companies. Because they knew what
they were supposed to be doing and they had a drive in policy to execute
on. A plan to architect defense in-depth.

And that's just reinforcing the idea that there is no perimeter anymore.
That we have to treat all the desktops that we deal with, whether
they're inside or outside our LANs, as being in the wild. And that we
need to have security at the desktop level. We need to have security at
the network level. Right out at the edges, in the core, in the WAN.
And that we need to have security around our data centers. And within
our data centers we need to have security around each system. And that
it needs to be addressing everything from layer 2 all the way up through
layer 7.

By and large, we're seeing that enterprises are, as I said earlier on,
using VLAN segmentation for security. And at much lesser degrees of
implementation, Putting out encryption. Putting out voice firewalls.
Or doing nothing in particular. What enterprises are not doing is
staffing for unified communications security. We're seeing typically
less than a tenth of an FTE dedicated to communication security for VoIP
or for associated tools. We're also seeing less than 15 percent of
enterprises buying specific tools for addressing VoIP or other unified

But they're not suffering the consequences from this kind of a lack yet.
Only a small percentage, around 2 percent, have seen actual
compromises. And by and large, people feel because they have not seen a
compromise yet, that they're very successful at what they're doing.
However, it only takes one compromise to turn a complete success into
complete failure if that's your standard. If you instead have a more
mature standard for judging your success based on raising your security
profile, self-rated successes should be a lot lower than they are. But
people are currently riding high on the tide of not having been attacked

Our conclusions. As we've just covered, more complexity. Every part of
the infrastructure means that we need policy driving automation to
address security problems in order to address the security problems that
are created by mobile virtual workers who will combine all their work
effort and their personal lives on the same network on the same

We've talked about how attacks are more sophisticated. They're
organized. There's an economy for generating them. And they're
targeted on specific people. And that the attackers are now
sophisticated, organized and specifically picking targets. They're
thieves, they're extortionists or they're vandals.

And that protecting your enterprise network and unified communications
along with requires multiple layers, authentication and identity
management and defense in-depth from emerging threats on your new
protocols and your new tools.

And lastly, speaking specifically to unified communications, it's not
just about VoIP and the threats to that. It's about the higher-level
protocols and especially SIP and SIMPLE which are used to glue together
everything else. These security concerns are real and although they're
not biting people much now, the rising profile of unified communications
means that they have to be addressed soon.

And they have to be addressed not just by putting in a specific box or
software package to deal with threats to SIP or SIMPLE or VoIP, but by
raising security profiles overall. That policy has to drive it, that
operations have to be combined and that you have to spend some money and
some brain time planning what you're going to do as a part of rolling
out unified communications.

That takes us to the end of my presentation. And we can take some
questions and answers.

Billy Hurley: Great presentation, John. Thank you very much.

John Burke: Thank you.

Billy Hurley: We have time for about one question. From a strategic
perspective, how do you reconcile encryption, which obscures data, and
then deep packet inspection, which has to understand it?

John Burke: Well, you can take one of two approaches. And one is that if you
set your network up to require encryption internally, you can treat
internal encrypted traffic as, by default, okay. Not necessarily always
a valid assumption but a livable one in most cases. And then you can
ignore it. Not make it a part of your deep packet inspection regime.

The other solution is to integrate an encryption endpoint with your deep
packet inspection device. So, get your security appliance that will be
your SIP proxy and your SIP firewall. And have that be the endpoint for
encrypted tunnels. So, from the client to the appliance. From the
appliance to the server or to the other client. And traffic is
encrypted as it comes into the appliance. Inspected, passed judgment on
and then re-encrypted on its way out.

Basically, those are your only two options. You can have variations
depending on where you're doing your packet sniffing. But you either
have to ignore it or you have to bring the encryption endpoint together
with the inspection endpoint.

Billy Hurley: Great. John, thanks for your insight. Once again we'd like
to thank John Burke of Nemertes Research for joining us today. For more
information on unified communications security, read John's exclusive
companion tip on combating threats to unified messaging systems via the
link on your screen.

Also be sure to check out more of the comprehensive resources in our
integration of networking and security school at

Thanks to all our listeners for joining us on this SearchSecurity.com
webcast. I'm Billy Hurley. Have a great day.

View All Videos

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.