Unified Communications Creates Security Holes. Here's How To Plug Them.

UC Exposes Security Gaps That Your Regular Firewall Can’t Even Begin To Sew Up. But A Combination Of Smart Policies And The Right Hardware Can Make Sure Your Company Is Safe.

stevens odean small.jpg

By Gilman Stevens, Director of SBC R&D and the VIPER Lab, Avaya and Gina Odean, National Director of Converged Solutions, NACR

(Note: This is an excerpt from Avaya’s recently-published e-book, The 2013 Guide To Collaboration Trends. Download the full 160-page PDF here.)

Your desk phone at work may seem no more dangerous than your coffee mug or stapler. But appearances can be deceiving. Unlike yesterday’s “dumbphone,” today’s VoIP-enabled phones combine the features of a computer and a network router in one.

The power and accessibility of these phones can be turned against them. Researchers at Avaya’s VIPER Lab and NACR have found that an unprotected IP phone gateway will be found and broken into by hackers located anywhere in the world within a week. Our research shows you can expect hackers to use your corporate network to rack up about $2,000 worth of fraudulent calls in just 8 hours–or half the time between the end of one workday and the start of the next one.

That’s not just theory; it’s reality. Enterprise customers hit by “toll fraud” tell VIPER Lab experts that they lost on average between $10,000 and $20,000 per month. One company lost $200,000 in a single month due to unauthorized international calls, usually to premium 1-900 numbers such as phone sex lines that charge hefty per-minute fees and from which the hackers directly or indirectly earn a cut.


Today’s unified communications (UC) networks mean that VoIP and SIP traffic runs over the same networks as your corporate data. That means that if you don’t take steps to secure your VoIP/SIP networks, you can make the latter vulnerable to malware and the hackers who create them. For example, using a VoIP phone in a company lobby or public area, a hacker with the right skills and knowledge of open- source tools can gain entrance into the corporate data network. Exploiting all-too-common weak passwords, the hacker can gain access to confidential company information and customer information in a matter of several hours.

Even More Threats

Again, all of this can be avoided if enterprises take common-sense steps to secure their VoIP/SIP networks (detailed below). But fail to do so and you expose other potential gaps. Just as hackers have extorted online retailers by threatening to disrupt their Web servers using mass denial of service (DoS) attacks, hackers can extort businesses by threatening to launch worker-crippling DoS attacks against UC networks. Or they can easily steal corporate information, either by eavesdropping on unencrypted VoIP conversations or by breaking into corporate servers as demonstrated by VIPER Lab researchers above.

The number of potentially unprotected pathways into your network is also growing, for two reasons:

1) the rise of telecommuting and home-based workers (and their often-insecure home Wi-Fi networks), and

2) the explosion in employees using tablets and smartphones at work, especially personally owned mobile devices.

To satisfy workers, companies are extending their VoIP and UC networks out to these endpoints. But in their rush, even healthcare and financial services organizations that operate under heavy security and privacy rules such as PCI DSS or HIPAA are often failing to create or enforce strong security policies protecting these remote outposts.

For example, a company may deploy a VoIP phone to a home office worker without forcing him or her to change the default “1234” access password. In that state, a hacker can easily take control of your phone, either to break into your main corporate network or use it for social engineering purposes. For example, the hacker could change your caller ID to “IT Support” and use it to start calling employees and asking for their login and password details.

Gaining Peace of Mind

There are steps you can take with your VoIP software to cut down on risks. For instance, make it standard policy to encrypt all VoIP calls, whether they are between employees in the office (and thus behind your enterprise firewall) or if they are from workers’ mobile and home office phones outside your network DMZ. Avaya Aura® Communication Manager lets you turn encryption on or off for such calls. The peace of mind you’ll enjoy will outweigh any potential hit on performance.

Companies are also starting to ensure that their annual independent security audits include testing of how vulnerable their VoIP and SIP networks are. We are seeing financial firms, airlines, and other global service companies starting to include this in their network assessments. Very soon, this will become mainstream.

The real panacea for your UC security woes is something called a session border controller (SBC). Like a traffic cop for your IP voice and video traffic, a properly configured SBC can enhance the performance of your VoIP/SIP network while protecting you from disaster.

Avaya offers just such an SBC. Moreover, that SBC is bolstered by proactive research from the VIPER Lab that enables threats to be anticipated and locked down years before they are discovered. And it comes in versions suitable for both Fortune 500 firms and smaller companies.

Ah! you say, but my carrier or SIP trunking service provider says it uses an SBC. Isn’t that enough to protect me? Actually, no. The main job of a service provider’s SBC is to protect its network from potentially malevolent traffic coming via YOUR leased lines. Protecting your enterprise from things like potential toll fraud is a secondary concern. That means that if a hacker successfully sniffs out your company’s VoIP network, he or she could likely successfully make thousands of short calls that rack up as much as $1,000 in toll bills in a few seconds. While a service provider’s SBC is unlikely to block such calls, an enterprise- controlled SBC can easily be set to do so.

Also, enabling your service provider’s SBC to protect your enterprise SIP/ VoIP network requires you to open up and share your full internal topology with your service provider. Not only is that counter-intuitive, but it would require an extraordinary amount of trust in your service provider. It would be like a homeowner giving ADT a map to all of the valuables in their home, including the code to their safe, in the hope that it would make their home safer from thieves.

The final analysis: Any enterprise that wants to protect its UC network needs to take all of the steps above, including deploying its own SBC. It is as much of a must-have as a network firewall for any company connected to the Internet.


Gil Stevens is Director of Avaya’s Session Border Controller product R&D team and the VIPER (VoIP Exploit Research) Lab. He has nearly three decades of telecom network experience with a passion for software quality and network security.

Gina Odean is National Director of Convergence at NACR, leads a team of highly certified Convergence Engineers who serve its customer base locally and globally. NACR is one of the largest Avaya channel partners worldwide and nine-time Avaya Business Partner of the Year. It is also the 2012 Avaya U.S. Services Partner of the year and a leading global integrator of business communications solutions and services.

Related Articles:

Understanding Avaya Aura Media Server Survivability Settings

My recent articles have explored how Port Networks and H.248 Media Gateways invoke the survivable modes of Avaya Aura Communication Manager (CM). In this article, I describe how the newest actor, Avaya Aura Media Server (AAMS) can also activate a CM-Survivable Core (fka Enterprise Survivable Server) and CM-Survivable Remote (fka Local Survivable Processor). In this article I will use the generic term CM-Survivable to reference both the Survivable Core and Survivable Remote servers.

If you follow Avaya’s announcements, then I’m sure you have heard that AAMS is one of the significant enhancements introduced in Avaya Aura 7.0. Actually, AAMS is a mature product that was created at Nortel circa 2003 to provide additional capabilities to their various communication servers. Back then, it was known as the Media Application Server. Since then, it has grown to provide a plethora of services, such as software-based DSPs, many leading voice and video CODECs, announcements, text-to-speech conversion, speech recognition, and DTMF detection.

Those abilities have been available to other formerly-Nortel products. Now, the abilities are also available to Communication Manager. Because AAMS has been around for a while, if CM is to use it AAMS must be release 7.7 or newer.

CM accesses the services of AAMS with SIP connections. You start by defining the AAMS as a “media server.” Interestingly, communication from CM to AAMS is defined within a SIP Signaling-Group, but lacks a corresponding Trunk-group. Further, the SIP communication is directly between the two devices and must not traverse a Session Manager. Similarly, AAMS needs to be configured to communicate with CM.

As described in other articles, a CM (either CM-Main or CM-Survivable) server becomes active whenever it controls DSP resources, which happens when either a H.248 Media Gateway (MG) or Port Network (PN) registers to the server. Because the AAMS contains DSP resources, it can also activate a CM server.

The first issue is determining which of up to 313 CM-Survivable (63 Survivable Core + 250 Survivable Remote) servers an AAMS could register to. That begins with an option on the third page of the change survivable-processor form called “Priority with respect to Media Servers.”

If no priority is assigned, then an AAMS cannot register to that CM-survivable and make it go active. However, this setting does not prevent a PN or MG from registering to this CM-Survivable server.

The next challenge is deciding exactly which priority to assign. This requires an analysis of your network topology, an estimation of what network failures are likely and/or most catastrophic, and a ranking of several survivability possibilities depending on how the network might fracture. That plan should drive the placement of resources such as AAMS, PNs, MGs and CM-Survivable servers. It would also suggest which priority to assign to each CM-survivable.

If your environment contains a mix of PN, MG and ASMS, you will want a failover strategy that causes as many as possible of them to register to the same CM-Survivable Processor. That administration needs to apply to your H.323 endpoints as well.

Assignable priorities start at 2 and go up to 9999. Since CM-Main is implicitly assigned priority of 1, it is obvious that larger integers mean lower priorities. By the way, priorities do not need to be assigned sequentially, allowing an administrator to deliberately leave numerical gaps that could be filled in later.

Only if a priority is assigned on page 3 of the change survivable-process form will you be able to populate the MEDIA SERVER REPORTING LIST on page 4. Effectively, this list identifies which of the potentially 250 AAMS servers could register to this CM-Survivable server.

Each AAMS needs to receive a list of all the CM-Survivable servers it might communicate with. So, CM-Main analyzes all the CM-Survivable entries and compiles a list per AAMS. I speculate that as part of its reporting mechanism, CM-Main then provides each AAMS with its custom list of CM-survivable servers and their assigned priorities.

03-29-16 Image 1 Understanding Avaya Aura Media Survivability Settings
03-29-16 Image 2 Understanding Avaya Aura Media Survivability Settings

Next, we need a heartbeat mechanism for AAMS to learn when CM-Main has become unavailable. AAMS periodically sends a status “report” to CM-Main that CM must promptly acknowledge. The Report Interval (RI) determines the frequency of this “heartbeat” (default 60 seconds). The Report Expiration (RE) timer (default 180 seconds) determines how long AAMS will wait for a response from CM-main.

If the Report Expiration timer expires, the AAMS will look to its list of assigned CM-Survivable servers. It will then work its way down the list, sending status reports to each CM-survivable until one responds. The available documentation suggests that each AAMS simultaneously sends reports to all its configured CMs (CM-Main and all assigned CM-Survivable servers). When a CM-Survivable receives a report from AAMS telling it that CM-Main is down, it is effectively a registration that activates CM-Survivable.

03-29-16 Image 3 Understanding Avaya Aura Media Survivability Settings

If you assign the same priority (for example ‘3’) to two or more CM-Survivable servers, then you need to make sure that each one has unique AAMS assigned to it on the Media Server Reporting List. In other words, no AAMS can be assigned a list of CM-Survivable servers with duplicated priorities.

In a different article, I discussed how the Split Registration Prevention feature (SRPF) works with MGs. I was surprised to learn that it works the same way with AAMS devices.

Fallback to CM-main can be invoked automatically when the ms-recovery-rule threshold is met (i.e. as soon as possible, or at a particular day and time). Alternatively, failback can be invoked manually from CM-Main with the command: enable ms-return.

Another implication of the introduction of AAMS is that it modifies a technical distinction between CM-Survivable Core (SC) and CM-Survivable Remote (SR). Previously either a PN or a MG could register to Survivable Core, but only a MG could register to a Survivable Remote. An AAMS can register to either a Survivable Core or a Survivable Remote. In other words, now the distinction between the two types of survivable servers is simply that PN cannot register to a Survivable Remote server.

With the addition of AAMS in Aura 7, Avaya has introduced some fantastic features. It also added flexibility to the survivability strategies that can be applied to CM.