Secure Real Time Communications

SecuringReal‐Time
Communications
by Lawrence C. Miller
and Walter Kenrich
Sonus Special Edition

Securing Real‐Time Communications For Dummies®
, Sonus Special Edition
Published by
John Wiley & Sons, Inc.
111 River St.
Hoboken, NJ 07030‐5774
www.wiley.com
Copyright © 2016 by John Wiley & Sons, Inc.
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise,
except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the
prior written permission of the Publisher. Requests to the Publisher for permission should be
addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ
07030, (201) 748‐6011, fax (201) 748‐6008, or online at http://www.wiley.com/go/permissions.
Trademarks: Wiley, For Dummies, the Dummies Man logo, The Dummies Way, Dummies.com,
Making Everything Easier, and related trade dress are trademarks or registered trademarks of John
Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used
without written permission. Sonus and the Sonus logo are registered trademarks of Sonus. All other
trademarks are the property of their respective owners. John Wiley & Sons, Inc., is not associated
with any product or vendor mentioned in this book.
LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE
NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR
COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL
WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A
PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR
PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE
SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE
PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL
SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT
PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR
SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION
OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE
OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER
ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR
RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET
WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN
THIS WORK WAS WRITTEN AND WHEN IT IS READ.
For general information on our other products and services, or how to create a custom For Dummies
book for your business or organization, please contact our Business Development Department in
the U.S. at 877‐409‐4177, contact info@dummies.biz, or visit www.wiley.com/go/custompub.
For information about licensing the For Dummies brand for products or services, contact Branded
Rights&Licenses@Wiley.com.
ISBN: 978‐1‐119‐32892‐6 (pbk); ISBN: 978‐1‐119‐32895‐7 (ebk)
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
Publisher’s Acknowledgments
Some of the people who helped bring this book to market include the following:
Project Editor: Carrie A. Burchfield
Editorial Manager: Rev Mengle
Acquisitions Editor: Katie Mohr
Business Development Representative:
Sue Blessing
Production Editor: Siddique Shaik

Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
About This Book......................................................................... 1
Foolish Assumptions.................................................................. 2
Icons Used in This Book............................................................. 2
Beyond the Book......................................................................... 3
Where to Go from Here.............................................................. 3
Chapter 1: Recognizing Current Trends in
Real-Time Communications. . . . . . . . . . . . . . . . . . . . . . 5
Shifting Business from Circuit-Switched
Voice to SIP Communications............................................... 5
Remote Worker Use Cases and BYOD Are Pervasive............. 6
RTC Increases Productivity — and Risk.................................. 7
Chapter 2: Understanding the Threat
Landscape in RTC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
RTC Attacks Are on the Rise..................................................... 9
RTC Threats Are Rapidly Evolving......................................... 10
Denial of Service (DoS).................................................. 11
Toll fraud......................................................................... 14
Identity theft.................................................................... 16
Exposing New Attack Vectors with RTC................................ 17
Linux and COTS.............................................................. 17
Porous firewalls.............................................................. 18
RTC traffic flows — signaling and media..................... 19
Chapter 3: Securing Real-Time Communications. . . . . 21
Encrypting RTC Signaling and Media..................................... 21
Complying with Regulatory Requirements............................ 24
Looking at the Cost of “No Security” In RTC......................... 24
Chapter 4: Understanding Why a Firewall
Can’t Secure RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Understanding the Role of Firewalls and SBCs..................... 27
Comparing Firewalls and SBCs................................................ 29

Securing Real-Time Communications For Dummies, Sonus Special Edition iv
These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
Chapter 5: Looking to the Future in Securing RTC. . . . . 33
New Strategic Approaches to RTC Security
Are Needed............................................................................ 33
Multi-layered Security in the Network................................... 34
Firewall and SBC sharing contextual
awareness.................................................................... 35
SDN to augment multi-layer security........................... 38
Chapter 6: Ten Ways SBCs Secure RTC. . . . . . . . . . . . . 41
B2BUA/Network Topology Hiding.......................................... 41
DoS and DDoS Defense (Policers)........................................... 42
Encryption (Media)................................................................... 42
Encryption (Signaling).............................................................. 42
Toll Fraud Protection............................................................... 43
Malformed Packet Protection.................................................. 43
Call Admission Control/Overload Controls........................... 43
NAT Traversal (Remote Workers).......................................... 44
Endpoint Registration.............................................................. 44
Full SIP Session State Awareness............................................ 44

Introduction
Recent high‐profile cyberattacks have many organizations
understandably focusing their security efforts on pre-
venting data breaches. While ensuring data security is indeed
a top priority, enterprises must not become complacent in
securing their mission‐critical, real‐time communications
(RTC) applications, systems, and networks — including voice
over IP (VoIP) and unified communications (UC) — which
can be directly targeted as an attack objective in itself, or to
exploit a new attack vector into other applications, systems,
and networks, in order to effect a data breach.
With the convergence of data and telephony networks and
the ubiquity of RTC (including VoIP, UC, and mobile phones),
hacking has come full circle as telephony attacks are on the
rise — or, more correctly, re‐rise. As a consequence, enter-
prises must revisit their RTC security posture using a holistic
approach, to ensure the integrity and availability of these
applications and systems, as well as the confidentiality and
privacy of sensitive data on converged networks and data
center infrastructures.
About This Book
Securing Real‐Time Communications For Dummies, Sonus
Special Edition, consists of six short chapters that explore
✓✓ Current trends in RTC, including the shift to session ini-
tiation protocol (SIP), enterprise mobility, and VoIP and
UC (Chapter 1)
✓✓ The modern security threat landscape, specifically denial
of service (DoS) and telephony denial of service (TDoS),
toll fraud, identity fraud, and new attack vectors exposed
by RTC (Chapter 2)
✓✓ How to secure RTC, including encrypting VoIP signaling
and media, addressing specific security use case scenar-
ios, understanding application reachability issues, and
meeting regulatory compliance requirements (Chapter 3)

Securing Real-Time Communications For Dummies, Sonus Special Edition 2
✓✓ The differences between firewalls and session border
controllers (SBCs) (Chapter 4)
✓✓ Emerging trends in securing RTC (Chapter 5)
✓✓ Key capabilities that an SBC brings to the fight in
securing RTC (Chapter 6)
Foolish Assumptions
It’s been said that most assumptions have outlived their
uselessness, but I’ll assume a few things nonetheless!
Mainly, I assume that you are an IT security or network pro-
fessional, such as an engineer, manager, decision influencer,
or decision maker. As such, this book is written primarily for
technical readers working for a large enterprise or service
provider.
If any of these assumptions describe you, then this book is
for you! If none of these assumptions describe you, keep read-
ing anyway. It’s a great book, and when you finish reading it,
you’ll know enough about securing RTC to be dangerous!
Icons Used in This Book
Throughout this book, I occasionally use special icons to call
attention to important information. Here’s what to expect:
This icon points out information that you should commit
to your non‐volatile memory, your gray matter, or your
noggin’ — along with anniversaries and birthdays!
You won’t find a map of the human genome here, but if you
seek to attain the seventh level of NERD‐vana, perk up! This
icon explains the jargon beneath the jargon and is the stuff
legends — well, nerds — are made of!
Thank you for reading, hope you enjoy the book, please take
care of your writers! Seriously, this icon points out helpful
suggestions and useful nuggets of information.

Introduction 3
This icon points out the stuff your mother warned you about.
Okay, probably not. But you should take heed nonetheless —
you might just save yourself some time and frustration!
Beyond the Book
There’s only so much I can cover in 48 short pages, so if
you find yourself at the end of this book, thinking “gosh,
this was an amazing book; where can I learn more?” just
go to www.sonus.net.
Where to Go from Here
With my apologies to Lewis Carroll, Alice, and the Cheshire
cat:
“Would you tell me, please, which way I ought to go from
here?”
“That depends a good deal on where you want to get to,”
said the Cat — err, the Dummies Man.
“I don’t much care where . . . ,” said Alice.
“Then it doesn’t matter which way you go!”
That’s certainly true of Securing Real‐Time Communications
For Dummies, Sonus Special Edition, which, like Alice in
Wonderland, is also destined to become a timeless classic!
If you don’t know where you’re going, any chapter will get
you there — but Chapter 1 might be a good place to start!
However, if you see a particular topic that piques your inter-
est, feel free to jump ahead to that chapter. Each chapter
is written to stand on its own, so feel free to start reading
anywhere and skip around to your heart’s content! Read this
book in any order that suits you (though I don’t recommend
upside down or backwards).
I promise you won’t get lost falling down the rabbit hole!

RecognizingCurrent
TrendsinReal‐Time
Communications
In This Chapter
▶▶ Evolving from legacy phone systems to SIP‐enabled telephony
▶▶ Enabling the digital workplace
▶▶ Addressing increased risk in RTC environments
In this chapter, I describe some of the current trends in
real‐time communications (RTC) and their security
implications.
Shifting Business from
Circuit‐Switched Voice
to SIP Communications
For many decades, enterprise telephony systems were pri-
marily comprised of legacy time‐division multiplexing (TDM),
circuit‐switched private branch exchanges (PBXs). These
monolithic systems were costly to acquire and maintain, often
proprietary, difficult to scale, and — compared to the features
and functionality of modern RTC systems and applications —
provided little more than dial tone to a desk phone.
Chapter 1

Many modern RTC systems use standard server and network-
ing hardware components, are built on open source software,
can be massively scaled with on premises, private and public
cloud deployment options, and provide robust features and
functionality, such as video and web conferencing, instant
messaging, presence, unified messaging, collaboration tools,
and mobility.
Session initiation protocol (SIP) is a key enabling standard for
RTC (see Figure 1‐1). Over the past 20 years, SIP has matured
considerably and has largely become the standard in service
provider and enterprise communications networks.
Today, enterprises have largely replaced their aging, legacy
TDM switches with SIP‐enabled voice over IP (VoIP) and uni-
fied communications (UC) systems that provide unmatched
business value, innovation, and flexibility in RTC.
Remote Worker Use Cases
and BYOD Are Pervasive
The modern digital workplace is another key trend with
several implications for RTC. As defined by Gartner, a
digital workplace
Figure 1-1: SIP enables new services and modalities for RTC and exposes
new security risks.

Chapter 1: Recognizing Current Trends in Real‐Time Communications 7
✓✓ Enables new and more effective ways of working: RTC
enables geographically dispersed teams to communicate
and collaborate more effectively with voice, video and
web conferencing, instant messaging and more, from
practically anywhere and on any device.
✓✓ Improves engagement and agility: The workplace has
become decentralized, with employees increasingly
working offsite rather than being tethered to a desk.
For example, many employees now routinely work from
home, in a vehicle, on an airplane, at a hotel or coffee
shop, or while visiting a customer or client. This mobil-
ity improves enables greater responsiveness by keeping
employees, partners, clients, and customers connected.
✓✓ Exploits consumer‐oriented styles and technologies:
“Bring your own device” (BYOD) policies — in which
employees are permitted to use their personal mobile
devices and installed apps for work‐related purposes —
have also become more common in the workplace. These
personal technologies drive higher productivity by allow-
ing employees to use the devices and apps they’re most
familiar with to get their work done more efficiently.
Remote/mobile worker and BYOD scenarios provide one
of the strongest use cases for RTC, allowing businesses to
adopt virtual user models, optimize office space and be
more responsive to customers. The challenge is to enable
RTC in a secure environment. As endpoints, such as tablets
and mobile phones, move farther from the core network, it
becomes harder to control authorized access to the network.
Additionally, a great deal of the RTC traffic traverses the
public Internet, and is often accessed via unsecure public
WiFi connections. Remote and mobile worker productivity is
reliant on this access, but the associated security risks must
be fully understood and properly addressed.
RTC Increases Productivity —
and Risk
There was a time when IT and security managers rarely lost
sleep over the threat of a potential attack against their voice
communications systems and networks, but the migration
from legacy TDM to RTC systems and networks changed all

that. Today, attacks targeting RTC systems, networks, and
applications are as real and increasingly prevalent as attacks
targeting data systems, networks, and applications in the
modern threat landscape.
SIP‐enabled, IP‐based voice communications have ushered in
a new era in RTC, enabling organizations to achieve significant
benefits with converged voice and data networks, including
✓✓ Lower costs through lower CAPEX investment in data
center and network infrastructure, as well as lower
OPEX for recurring telco services
✓✓ Increased bandwidth capacity and higher utilization,
resulting in better overall performance of voice and
data networks
However, as organizations move to RTC to realize benefits
such as these, a new threat emerges: the introduction of
IP‐based attacks, network intrusions, and information theft
through RTC. The security stakes are especially high for
enterprises, as compromised customer data can generate
stiff penalties and losses totaling several millions of dollars.
As enterprises implement and increasingly rely on RTC,
they must also enforce RTC security. Enterprises must pro-
tect their network boundaries against internal security risks
(for example, employees and partners) and external security
threats and attacks (for example, cybercriminals).
Enterprises must balance security requirements with real‐
time network performance to protect their systems and data.

UnderstandingtheThreat
LandscapeinRTC
In This Chapter
▶▶ Recognizing threat actors and their tools and motivations
▶▶ Looking at evolving RTC threats
▶▶ Discovering new attack vectors in RTC
This chapter explores the real‐time communications (RTC)
threat landscape, including the different threat actors, the
tools they use, and their motivations, as well as different RTC
threats and new attack vectors introduced by RTC.
RTC Attacks Are on the Rise
The proliferation of enterprise RTC — voice over IP (VoIP)
and unified communications (UC) — and the widespread and
rapidly growing availability of surreptitious tools for inter-
cepting IP packets and cracking code, make it increasingly
easy for attackers to target RTC.
For example, attackers can freely download network protocol
analyzers to capture and interpret VoIP calls, record media
streams, and intercept instant messaging (IM) communica-
tions. Other tools, such as UCSniff, can be used to identify,
record, and replay VoIP conversations or IP videoconferenc-
ing sessions.
SIP‐sniffing software is readily available on the Internet, which
makes securing RTC particularly challenging.
Chapter 2

The roster of potential attackers is expanding too. Organized
criminal groups have found the Internet to be a profitable
avenue from which to mount high‐tech fraud, identity theft,
and extortion schemes. In fact, cybercrime has become so
lucrative that a cottage industry of global hackers‐for‐hire —
selling their services on a contract basis — has been created.
Rogue nations are also increasingly involved in cyberespio-
nage, cyberterrorism, and cyberattacks against defense, gov-
ernment, and private industry targets.
Finally, hacktivists — motivated by political or social causes —
often target high‐profile organizations. Denial of service (DoS)
attacks, in particular, are a favorite tactic used by hacktivists
to draw publicity and/or notoriety to their various causes.
RTC Threats Are
Rapidly Evolving
There are many variants of RTC threats (see Figure 2‐1); how-
ever, the most common threats for RTC attacks are as follows:
✓✓ Denial of service (DoS) attacks, including distributed
denial of service (DDoS) and telephony denial of service
(TDOS)
✓✓ Toll fraud, including number harvesting, spam over
Internet telephony (SPIT), and spam over instant
messaging (SPIM)
✓✓ Identity theft, including caller ID spoofing, eavesdrop-
ping, and call hijacking
Call hijacking is another form of identity theft that can be
used to redirect a call session or text message to a different
number. In addition to call hijacking against organizations,
individual users can be targeted. For example, call hijacking
scenarios commonly redirect a call intended for the victim’s
bank to a criminal organization in order to fraudulently collect
financial information.

Chapter 2: Understanding the Threat Landscape in RTC 11
Denial of Service (DoS)
Denial of Service (DoS) attacks were virtually non‐existent
in legacy circuit‐switched time‐division multiplexing (TDM)
telephony systems, which operated as monolithic systems on
isolated voice networks — much like a castle protected by a
moat and towering walls. However, as I discuss in Chapter 1,
such legacy systems are costly, and lack the scalability, inno-
vation, and functionality that modern enterprises require.
Unfortunately, DoS attacks have new and specific applications
in RTC. For example, an attacker can disrupt a target organiza-
tion’s communications infrastructure:
✓✓ At the desktop level, by crashing endpoints (such as
phones and desktop PCs)
✓✓ At the gateway level, by taking out the network nodes
that provide the interface between an enterprise VoIP
environment and the outside world
✓✓ At the network level, by directly targeting an enterprise
IP private branch exchange (PBX) using SIP or other
protocols to crash the session manager with an endless
flood of session requests
An attacker’s motivation for a DoS attack may include
extortion (demanding a ransom payment from the victim
organization to suspend the attack) or other financial gain
Figure 2-1: RTC threats are rapidly evolving.

(cybercriminals are sometimes paid to target a specific orga-
nization), as well as publicity for a political or social cause.
Attackers often plan the timing of their attacks in order to
maximize financial damage. For example, online retailers
might be targeted during the heavy traffic of holiday shopping
seasons. Beyond lost revenue, financial losses often include
the cost of responding to and remediating an attack, expenses
related to customer support and public relations, and, in
some cases, litigation and civil penalties.
With media attention largely focused on cyberattacks involv-
ing data theft, DoS attacks may seem irrelevant and rare, but
the frequency and impact of these attacks may surprise you.
According to research by the Ponemon Institute and security
content delivery network (CDN) Incapsula, DoS and DDoS
attacks, in general
✓✓ Are increasing 100 percent year over year (YoY)
✓✓ Targeted one in two companies in 2015
✓✓ Hit the average company four times per year, costing an
estimated total of $1.5 million
✓✓ Cost an average of $40,000 per hour last at least five days
in 20 percent of attacks, which can be devastating for
many businesses
DDoS attacks are often used as smokescreens by attackers
to spread malware or take control of other systems in the
background.
One example of a DDoS attack against RTC is a SIP registration
flood, in which millions of TCP/UDP packets flood the SIP/UC
ports on a SIP trunk (see Figure 2‐2).
SIP trunks are typically created over multiprotocol label
switching (MPLS) or over‐the‐top (OTT) networks, which
themselves introduce additional security risks.
To stop a SIP registration flood attack, you need to differenti-
ate “good” registrations from “bad” ones. Although it may be
possible to create a rule on a firewall in your data center to
block bad registrations, the attack may still succeed because
the bandwidth on your SIP trunk can be overwhelmed with
attack traffic before it reaches the firewall.

Ideally, you need to stop the DoS attack traffic at the farthest
edge of your network. A session border controller (SBC, dis-
cussed in Chapter 4) can detect an RTC DoS/DDoS attack and
block that traffic from disrupting the valid RTC traffic.
DDoS attacks aren’t unique to RTC. However, it’s important
to know that in addition to source IP addresses, the source
telephone numbers or SIP uniform resource identifiers (URI)
identifying users, are also relevant in DDoS attacks against
RTC. More sophisticated DDoS attacks use multiple IP and SIP
level sources to further complicate the task of determining
and filtering out unwanted traffic.
Like IP‐based data attacks, RTC is vulnerable to DoS attacks
from the IP layer and up. However, RTC is also vulnerable to
specific types of DoS attacks — telephony DoS (TDoS) — that
target the telephony application itself. TDoS attacks differ
from other types of DoS attacks in that they involve RTC ses-
sions, rather than various packets at different protocol layers.
TDoS attacks typically target the RTC layer protocols such as
session‐initiation protocol (SIP), for example, by sending large
volumes of SIP messages that require complex parsing or
state information to be held, resulting in resource consump-
tion (see Figure 2‐3).
Another form of TDoS simply requires the attacker to direct
high call volumes to a server, either consuming all of the serv-
er’s resources, or preventing legitimate users from accessing
a specific number by flooding it with bogus traffic and keep-
ing sessions active for extended durations. TDoS attacks are
usually automated, but can also involve large groups of indi-
viduals organized through social networking.
Figure 2-2: A SIP registration flood is one example of a DDoS attack
against RTC.

TDoS attacks are very hard to detect and mitigate. Mitigation
involves quickly detecting and determining which calls are
part of an attack, and terminating those calls to provide band-
width and resources for legitimate users. Network equipment,
such as a firewall, which is not part of the call session cannot
stop a TDoS attack — it can only provide alerts.
Toll fraud
Toll fraud is one of the oldest forms of computer crime. Toll
fraud involves a malicious user gaining unauthorized access
to voice services on a service provider or enterprise network,
for example, to make international calls or use other toll ser-
vices. In other cases, a cybercriminal might gain access to
special classes of numbers to extract revenue, such as repeat-
edly calling a duplicitous premium rate number (perhaps a
“1‐900 psychic hotline”) that the cybercriminal operates.
The global impact of toll fraud has soared to more than $46.3
billion annually, or slightly more than 2 percent of all global
telecom revenues, according to a recent Communications
Fraud Control Association (CFCA) Global Fraud Loss survey.
To put that into perspective, credit card fraud was around
$14 billion dollars over the same period. More ominously, toll
fraud losses are growing at a faster rate than global telecom-
munications revenue.
Dial‐Through fraud (DTF) is the most damaging form of toll
fraud, in which an IP PBX is compromised in such a way that
an attacker using a robocall generator can dial in to the PBX,
get a dial tone, then hairpin dial out to an international pre-
mium number to generate fraudulent revenue that is charged
to the target enterprise (see Figure 2‐4).
Figure 2-3: TDoS attacks target RTC sessions directly.

Attackers may use DTF themselves to generate revenue
directly, or they may sell access to the compromised PBX to
other cybercriminals to generate calls. DTF calls are usually
short and variable in duration, and are usually generated out-
side of normal business hours to avoid detection.
Other examples of toll fraud involve opening a connection
for a voice call, but instead streaming high‐definition, com-
pressed video, essentially defrauding the interconnect net-
work out of the higher rates typically charged for video traffic.
Number harvesting schemes, in which cybercriminals collect
and sell phone numbers to other cybercriminals, may be used
for identity fraud, or to perpetrate SPIT and SPIM campaigns.
SPIT involves sending prerecorded, unsolicited messages to
an RTC endpoint. Because SIP acknowledges the presence
of an RTC endpoint, dialer programs can transmit SPIT with
a high probability of a recipient picking up the call. Other
risks associated with SPIT include denial of service and
unauthorized use of network bandwidth. In the same vein,
SPIM involves sending unsolicited instant messages to SIP
endpoints, particularly PCs and mobile phones. In addition to
the risks associated with SPIT, SPIM (like email spam) can be
used to transmit malware to a SIP endpoint. Current methods
of countering SPIT and SPIM are similar to those employed
against email spam: it’s practically impossible to prevent it,
you can only attempt to filter it and thereby limit its impact.
Figure 2-4: An example of DTF.

Identity theft
Identity theft is a common objective in many types of cyber-
attacks, and RTC attacks are no exception. In addition to
defrauding an individual, a compromised identity can be used
to allow an attacker to gain unauthorized access to enterprise
RTC services (among others), or to prevent the legitimate use
of these services by an authorized user.
A cyberattack can exploit vulnerabilities in various RTC pro-
tocols, such as SIP, for the purpose of identity theft. Some
examples include caller ID spoofing, media access control
(MAC) spoofing, IP spoofing, and call control/proxy/trivial file
transfer protocol (TFTP) spoofing. Freely available tools, such
as MacMakeUp and Nemesis, can be downloaded from the
Internet to help an attacker spoof an identity. A spoofed iden-
tity allows a cybercriminal to impersonate a legitimate user in
an RTC session.
There are many well established authentication and encryp-
tion protocols available to secure RTC signaling and media.
However, these protocols aren’t always used by enterprises,
leaving the user and the service open to identity theft. Thus,
in some cases, a simple packet capture may be all that’s
needed for an attacker to gain unauthorized access to an orga-
nization’s RTC environment.
Although authentication may help to prevent illicit access to
RTC services, without encryption it doesn’t prevent certain
signaling injection attacks. These types of attacks may be
used in DoS attacks or for toll fraud, as well as for identity
theft, for example, by eavesdropping on calls or accessing
voice mails and messaging to collect sensitive data.
Vishing is the VoIP‐enabled form of email phishing. As effec-
tive a tool as email phishing is for cybercriminals, it is abso-
lutely amazing how willing people are to disclose personal
information to a live voice on the other end of a phone.
Many legitimate U.S. businesses knowingly outsource their
customer service to call centers staffed by prison inmates!
Although such call centers are closely monitored and do not
knowingly engage in identity fraud, this example illustrates
the point that people will often implicitly trust a live person
on the other end of a call. To exploit this false sense of secu-
rity, many criminal organizations are known to set up their
own call centers to extract information from hapless victims.

Exposing New Attack
Vectors with RTC
Hacking into RTC sessions requires that the malicious party
intercept signaling and/or media flowing between two end-
points at any of several points along the communications
path. Several potential points of attack — or attack vectors —
exist in RTC sessions, including
✓✓ UC application servers
✓✓ Call control elements, such as PBXs and automatic call
distributors (ACDs)
✓✓ Session‐layer servers and proxies, such as SBCs
✓✓ Transport and network layer elements, such as routers
✓✓ Link‐layer elements, such as Ethernet switches and
wireless LANs
✓✓ Endpoints, such as desktop and laptop PCs, mobile
devices, IP phones and videoconferencing terminals
In addition to traditional network attack methods — such as
infecting an endpoint with malware to establish administrator‐
level remote access — man‐in‐the‐middle attack techniques,
in which certain packets are selectively altered between two
endpoints in a voice, video, or instant messaging stream, may
be used. Modifying, disrupting, or lowering the quality of IP
communications in this manner can have a variety of adverse
effects on the enterprise. For example, an attacker can modify
or discard critical financial transactions, disrupt business
operations, or reduce the quality of the customer experience.
Some common attack vectors that RTC exposes include Linux
and COTS, porous firewalls, and RTC traffic flows.
Linux and COTS
Unlike legacy circuit‐switched TDM PBXs that were often
comprised of proprietary hardware and software, many RTC
systems use open source Linux operating systems and com-
mercial off‐the‐shelf (COTS) software running on commodity
hardware, such as Intel‐based servers. Thus, RTC systems

expose many of the same attack vectors as any other server
in an enterprise network, and need to be patched and safe-
guarded accordingly. If compromised, these systems can be
used not only to attack RTC services, but also as a platform
for lateral movement throughout the enterprise network.
Porous firewalls
RTC protocols, such as SIP, session description protocol
(SDP), and real‐time transport protocol (RTP), are designed
to require multiple source and destination sockets (IP and
port combinations) during an RTC session. Given the number
of users in a typical enterprise or carrier network, it is not
uncommon for thousands of firewall “holes” to be opened
in order to support RTC services. Not only does this give an
attacker ample attack vectors to target RTC servers, but also
it provides an opportunity to flood common network seg-
ments with traffic that could hinder or knock out other enter-
prise systems and services.
For example, enterprises using SIP for remote user connectiv-
ity typically configure their perimeter firewalls to forward SIP
traffic (port 5060) to an internal IP PBX. Using this forwarding
rule, an attacker can send fuzzed (or malformed) messages
with embedded shell code to a vulnerable endpoint (such as
a softphone installed on a laptop computer) via the IP PBX,
which treats the fuzzed message as a new call and forwards
it to the endpoint. When the endpoint receives the fuzzed
message it executes the embedded shell code, causing the
endpoint to connect back to the attacker’s computer over
port 80. Enterprise firewalls typically allow outgoing connec-
tions to port 80, as this is the standard port for web traffic
(hypertext transfer protocol, or HTTP). Once the connection
back to the attacker is established, the attacker can get take
control of the victim’s endpoint, access any data stored on
the endpoint, and probe the network for other vulnerabilities
(see Figure 2‐5).
More than 50 percent of all cyberattacks will be SIP‐based in
2016, and the annual cost of SIP attacks alone is estimated at
$11.7 billion, according to CFCA, the SIP Forum, and Telecom
Reseller.

RTC traffic flows —
signaling and media
It isn’t uncommon for network administrators to assume RTC
protocols are inherently secure. After all, you need special-
ized codec algorithms to make sense of an RTP flow, for exam-
ple. However, this notion of security is false. For example, it’s
well known that it’s possible to embed attacks, such as SQL
injections, into SIP headers that can cause servers to crash,
corrupt data, or allow unauthorized access to an attacker.
An attacker can also embed malware in a SIP or RTP signaling
or media stream to infect an RTC endpoint on the network.
Finally, an RTC media session can be used by an attacker to
exfiltrate (or steal) sensitive data from a network using RTP,
for example, as a covert channel.
Figure 2-5: SIP sessions create dynamic firewall rules (or “holes”) that can
be used for network penetration by an attacker.

SecuringReal‐Time
Communications
In This Chapter
▶▶ Securing RTC signaling and media with encryption
▶▶ Maintaining regulatory compliance
▶▶ Seeing how “no security” costs you in RTC
In this chapter, you learn about the role of encryption in
securing real‐time communications (RTC), as well as
regulatory compliance issues.
Encrypting RTC Signaling
and Media
To protect voice networks against the widest possible range
of attacks, an enterprise RTC security strategy should protect
both the endpoint and the media itself. This can be achieved
through a holistic security approach that includes
✓✓ Virtual private networks (VPNs) to logically separate
voice and data traffic on the common IP network
✓✓ Border security elements such as session border control-
lers (SBCs) to provide call admission control (CAC) and
protect against denial of service (DoS) attacks
✓✓ Signaling and media encryption of RTC sessions, includ-
ing those sessions stored on voice messaging and call
recording systems
Chapter 3

While many enterprises have implemented VPN and border
security technologies to protect their IP‐based data networks,
the encryption of RTC signaling and media is a unique consid-
eration that has grown in importance with the advent of more
pervasive RTC implementations in the enterprise.
The encryption of RTC signaling and media mitigates a
number of IP‐based threats including
✓✓ Passive monitoring and recording
✓✓ Packet decryption and modification
✓✓ Service or bandwidth theft
✓✓ Endpoint impersonation
✓✓ Denial of service (DoS)
✓✓ Escalation of network user privileges
Because signaling and media use different protocols with
unique properties and constraints, RTC networks employ
Transport Layer Security (TLS) and/or IPsec (IP Security) for
signaling encryption and Secure Real‐time Transport Protocol
(SRTP) for encrypting RTP media.
TLS and IPsec provide bilateral endpoint authentication and
secure transport of signaling information using advanced
cryptography. SRTP provides encryption (and decryption) of
the RTP media used in RTC applications (such as conferenc-
ing and instant messaging).
TLS, IPsec, and SRTP encryption enable enterprises to secure
RTC communications by performing three key functions:
✓✓ Endpoint authentication: This supports the use of digital
signatures (which may be proprietary or verified by a
trusted third party) and pre‐shared, secret‐based authen-
tication to verify the identity of session endpoints.
✓✓ Message integrity: This ensures that media and signal-
ing messages have not been altered or replayed between
endpoints.
✓✓ Privacy: Encrypted messages can only be viewed by
authorized endpoints, mitigating information/service
theft and satisfying both regulatory and corporate
requirements for private communications.

Chapter 3: Securing Real‐Time Communications 23
However, deploying TLS, IPsec, and SRTP encryption in the
enterprise may increase call latency. Therefore, signaling and
media encryption must be thoughtfully integrated into the
IP network traffic flow to prevent added network latency or
decreased performance under load. Enterprises must weigh
several considerations before they deploy RTC encryption in
their network:
✓✓ Session performance: Remember that encryption
requires additional processing of signaling and media.
Extra “hops” to a separate encryption device in the net-
work or an SBC that performs encryption from the main
CPU can add unwanted latency to RTC sessions or com-
promise call handling capacity. Therefore, it’s important
to find an encryption solution that has minimal impact
on session capacity and network performance. While
enterprises should consider implementing security
solutions such as standalone SBCs, they should be
aware that SBCs without dedicated encryption hardware
will normally encrypt traffic at the expense of session
performance.
✓✓ Multimedia support: As RTC initiatives grow, enterprises
will be required to handle a variety of multimedia ses-
sions including voice, video, instant messaging (IM), and
collaboration apps. To reduce cost and network complex-
ity, enterprises should look for an SBC that has robust
transcoding capabilities and supports multiple media
types.
✓✓ Encryption standards: Simply put, some encryption
standards are more accepted/effective than others. Your
RTC security solution needs to use the latest encryption/
decryption methods to ensure broad network and RTC
interoperability in the future.
✓✓ Disaster/failover recovery: Network equipment failures,
fiber cuts, and natural disasters happen despite the best
precautions. Enterprise security systems need to be
prepared for this reality with a backup/failover plan for
all aspects of security including RTC session encryption.
This can best be achieved by deploying SBCs in redun-
dant, paired configurations.
✓✓ Centralized policy management: To reduce human error
and operational costs, a central management console for
encryption policies in the network is both desirable and
essential.

Complying with Regulatory
Requirements
There are myriad regulatory requirements for data security
and privacy that are applicable in various industries and
regions throughout the world (see the sidebar, “The cost of
‘no security’ in real‐time communications”). In RTC environ-
ment, voice, video, and other media is another form of IP‐
based data in the network that must also be safeguarded.
Eavesdropping, or the unauthorized interception of RTC traf-
fic between endpoints, can be a major security and privacy
threat for organizations. An RTC session can be tapped by
compromising the network anywhere along the data route.
Moreover, it’s possible to remotely activate conferencing or
handset/headset microphones on compromised endpoints.
Eavesdropping can be implemented using SIP proxy imperson-
ation or registration hijacking. To counter the eavesdropping
threat, enterprises and service provider should encrypt media
signaling in their RTC environments.
Session replication for recording is another common use
case that can be impacted by regulatory requirements.
Organizations that record RTC sessions, either for the pur-
pose of regulatory compliance directly, or for quality control
purposes in a call center, must be able to replicate all SIP
signaling and media to a recording server(s), as well as to the
intended recipient. Organizations must also be able to repli-
cate all or only selective sessions and store recorded media in
an encrypted format on a secure server.
Looking at the Cost of
“No Security” In RTC
Most businesses understand the risks posed by attacks on the
data side of the network: stolen credit card numbers, compro-
mised passwords, denial of service, financial fraud and iden-
tity theft, among others. Those same risks apply to real‐time
communications as well, though they may manifest them-
selves as different threats, such as eavesdropping, telephony

Chapter 3: Securing Real‐Time Communications 25
denial of service (TDoS) attacks, and automatic number iden-
tification (ANI) spoofing targeting call centers. These real‐time
communications threats can be as destructive as data threats,
consuming valuable resources, driving down revenue, and
damaging brand equity.
The most serious risk in a VoIP network that isn’t properly
secured is the potential exposure of confidential, sensitive,
private, or otherwise protected information, including
✓✓ Private data and personally identifiable information,
or PII (for example, names, addresses, birthdates, and
Social Security numbers)
✓✓ Financial data (for example, credit or debit card num-
bers and banking or financial account information)
✓✓ Protected health information, or PHI (for example,
physical examinations, lab tests, diagnosis, and
prescription records)
✓✓ Sensitive company information (for example, sales data,
marketing plans, research and development, intellectual
property, trade secrets, and new product details)
An enterprise security breach can result in financial penalties
and other consequences for the organization. For example,
a single security incident in a credit card processing envi-
ronment can result in multimillion dollar fines and other
liabilities, due to losses from fraud and theft. Other costs can
include reissuing credit cards, communicating the breach
to customers, and mandatory credit monitoring services. In
some cases, a business may have its card processing privi-
leges suspended or revoked.
Noncompliance with federal and industry security regulations
can cost enterprises millions of dollars in fines, legal fees,
damages and lost revenue. Some regulations and industry
standards that address VoIP security requirements include
✓✓ Gramm‐Leach‐Bliley Act (GLBA): Applicable to any
public company involved in financial services (such as
banking, credit, securities and insurance); relevant VoIP/
UC issues for GLBA include preventing unauthorized VoIP
packet interception and decryption, and securing inter-
nal wireless networks and communications over public
wireless networks.

✓✓ Health Insurance Portability and Accountability Act
(HIPAA): Applicable to any organization that handles
medical records or other protected health information
(PHI); relevant VoIP/UC issues for HIPAA include securing
authorized internal and external access to patient data.
✓✓ Sarbanes‐Oxley (SOX) Act: Applicable to public compa-
nies; relevant VoIP/UC issues for SOX include maintaining
VoIP usage logs and tracking administrative changes, and
implementing strong authentication policies to prevent
unauthorized system use.
✓✓ Federal Information Security Management Act (FISMA):
Applicable to any federal agency, contractor, or
company/organization that uses or operates an informa-
tion system on behalf of a federal agency; relevant VoIP/
UC issues for FISMA include System and Information
Integrity (SI) requirements, implementing solutions to
remediate security flaws, providing security alerts and
advisories, protecting against malicious code, detecting
and preventing network intrusions and malware, and
maintaining application and information integrity.
✓✓ Payment Card Industry Data Security Standard (PCI
DSS): Applicable to any organization that issues, accepts,
or processes VISA, MasterCard, American Express,
Diners Club, or Discover credit or debit cards; relevant
VoIP/UC issues for PCI DSS include protecting cardholder
data and sensitive information shared between employ-
ees and/or customers (for example, in a call center) over
VoIP calls or UC sessions, protecting stored information
stored on voice messaging or call recording systems (for
example, for call center quality control purposes), and
tracking and monitoring access to network resources and
cardholder data.

UnderstandingWhya
FirewallCan’tSecureRTC
In This Chapter
▶▶ Defining the role of firewalls and SBCs in RTC security
▶▶ Recognizing different capabilities in firewalls and SBCs
In this chapter, you learn about the role of session border
controllers (SBC) in real‐time communications (RTC),
and why a firewall alone isn’t enough to secure real‐time
communications.
Understanding the Role
of Firewalls and SBCs
Firewalls are designed to protect data networks and services
from external threats and attacks. In a typical network config-
uration, a router forwards IP packets to servers and endpoints
through a firewall that connects a trusted (internal) network
to an untrusted (external) network. The firewall determines
which connection are permitted to and from the server or
endpoint based on a statically configured rule base that
allows or blocks specific port connections that correspond to
specific source and destination IP address combinations.
Different firewall types include static or dynamic packet filter-
ing firewalls, stateful inspection firewalls, proxy servers, appli-
cation firewalls, and next‐generation firewalls (NGFWs).
Chapter 4

The most commonly deployed types of enterprise firewalls
today are dynamic packet filtering and stateful inspection
firewalls. However, NGFWs — generally recognized to have
superior security capabilities to other firewall types — are
increasingly being deployed in enterprise networks.
SBCs are designed to create a secure RTC environment in
which numerous devices across multiple networks interwork
to create a seamless user experience. An SBC’s main func-
tion is to deliver session initiation protocol (SIP) trunking for
enterprises and interconnection to other service providers
(see Figure 4‐1).
SBCs can also support the hosting of business voice over IP
(VoIP) services in delivering an RTC environment of linked
media and voice communications. VoIP‐based RTC services
present a packet‐based, IP solution that supports concurrent
voice and data in a very efficient and cost‐effective manner
over high‐speed mobile data connections.
Enterprises and service providers can also leverage SBCs
(along with policy engines) to improve the security of their
networks. SBCs prevent unauthorized access to the RTC envi-
ronment, while policy engines ensure that any unauthorized
access doesn’t lead to stolen, completed calls to high cost
locations.
Figure 4-1: The primary function of an SBC is to provide SIP trunking for
enterprises and interconnection between service providers.

Chapter 4: Understanding Why a Firewall Can’t Secure RTC 29
Other SBC functions include
✓✓ SIP session management and interworking
✓✓ Denial of service (DoS) and distributed denial of
service (DDoS) protection
✓✓ Protocol interworking
✓✓ Call detail record (CDR) and billing
✓✓ IP multimedia subsystem (IMS) and SIP application
support
✓✓ Rich communication suite (RCS) and IP exchange
(IPX) support
✓✓ WebRTC and RTC support
✓✓ Policy and routing enforcement
✓✓ Media services (transcoding and transrating)
✓✓ Encryption, using Transport Layer Security and IP
Security (TLS/IPSeC) and Secure Real‐Time Transport
Protocol (SRTP)
Comparing Firewalls and SBCs
Firewalls and SBCs provide different security functions in
a converged IP data and RTC network. Table 4‐1 provides a
summary comparison of key firewall and SBC functionality
and capabilities.
Table 4-1 Firewalls versus SBCs
Firewall SBC
Maintains single session through
firewall
Implements a SIP back‐to‐back
user agent (B2BUA) for complete
session control
Fully state‐aware at Open
Systems Interconnection (OSI)
model layers 3 (network) and 4
(transport) only (except applica-
tion firewalls, proxy servers, and
NGFWs)
Fully state‐aware at OSI layers 2
(data link) through 7 (application)
(continued)

When developing an RTC security strategy, you should con-
sider four key RTC threat vectors:
✓✓ UC as a delivery mechanism for malware and/or spyware
✓✓ Denial of service along two vectors, each of which
compromises UC such that the service is interrupted
or suspended:
•• Network layer denial of service: Network layer
packet floods and replays attacks to overload UC
elements and take away from “good‐put” processing
•• Application layer denial of service: Protocol aware
attacks to crash the UC stack (for example, mal-
formed SIP packets, illegal headers, out of order
messages, and others)
✓✓ Theft of service
✓✓ Identity management
Tables 4‐2 and 4‐3 outline the capabilities of NGFWs and SBCs,
respectively, in protecting RTC networks against these differ-
ent attack vectors.
Firewall SBC
Inspects and modifies only
application layer addresses (such
as SIP and session description
protocol or SDP, and others)
Inspects and modifies any appli-
cation layer header info (such as
SIP, SDP, and others)
Unable to terminate, initiate,
re‐initiate signaling and SDP
Can terminate, initiate, re‐initiate
signaling and SDP
Typically only supports static
access control lists (ACLs)
Supports static and dynamic
ACLs
Not able to decode encrypted SIP
signaling and/or media
Able to decode RTC encryption
(IPSec/TLS and SRTP
Table 4-1 (continued)

Chapter 4: Understanding Why a Firewall Can’t Secure RTC 31
Table 4-2 NGFW Scorecard for RTC Security
Security Domain Capabilities
Malware and
spyware [strong]
In depth signature library, scanning, and
pattern matching on the payload
Note: Encryption of SIP and RTP‐media flows
is becoming increasingly common in RTC and
compromises the strengths of NGFWs as
signatures become obscured.
RTC denial of
service (DoS)
[weak]
Network: Requires deep SIP awareness to
track port numbers, user datagram protocol
(UDP) service types, stream activity/inactivity,
and bandwidth requirements
Application: Requires full stack parsing, valida-
tion, and session state to protect downstream
RTC elements
Theft of service
[weak]
Requires knowledge and state around RTC
user identity via SIP registration parsing and
state caching (not implemented in NGFW)
Requires understanding of negotiated services
(such as audio, video, and collaboration) and
tight management of per session bandwidth
utilization
Identity manage-
ment [modest]
Can effectively identify RTC applications and
whether they should be allowed into the net-
work (for example, a go/no‐go policy decision)
The challenge is understanding the validity of
the identity as it relates to the RTC service (for
example, is the user trusted and allowed to
invoke the service).

Table 4-3 SBC Scorecard for RTC Security
Security Domain Capabilities
Malware and spyware
[weak]
No in‐depth signature library, scanning,
and pattern matching on the payload
Denial of service (DoS)
[strong]
This is a primary security function in an
SBC with full SIP awareness, full call
state awareness, and session aware-
ness from beginning to end of call.
DOS requires full stack and session
state knowledge to protect downstream
UC elements (such as phones, PBX, the
UC stack itself, and others).
Theft of service [strong] This is a primary security function in an
SBC with full SIP awareness, full call
state awareness, and session aware-
ness from beginning to end of call.
An SBC understands the negotiated
services (for example, audio/video/
collaboration) and provides tight man-
agement of per‐session bandwidth
utilization.
Identity management
[strong]
Tracks the multiple states of authen-
tication as RTC users advance from
untrusted, through known but not vali-
dated, to fully trusted states
Strong understanding of the validity of
user identity in the context of the RTC
stack

LookingtotheFuturein
SecuringRTC
In This Chapter
▶▶ Recognizing the widening vulnerability gap
▶▶ Countering RTC threats with a multilayer security stack
In this chapter, you explore the need for a comprehensive
security strategy to address the widening vulnerability gap
in enterprise and service provider networks, and you look
to the future of network security: the multi‐layered security
stack.
New Strategic Approaches to
RTC Security Are Needed
Security organizations, in general, aren’t innovating fast
enough. As a consequence, the following happens:
✓✓ Existing controls are ineffective against new threats, and
new controls aren’t being developed and deployed in a
timely manner.
✓✓ The internal network can’t be trusted due to the pro-
liferation of mobile bring your own device (BYOD) and
cloud computing trends that blur the border between the
internal and external network and introduce pervasive
vulnerabilities throughout the network.
Chapter 5

In contrast, attackers are rapidly and continuously evolving
their tactics and becoming increasingly sophisticated, lured
by easier targets — such as BYOD mobile devices and apps —
and the increasing value of sensitive information — such as
medical or healthcare information and credit card data.
This polarization between security innovation and attacker
innovation is creating an ever widening vulnerability gap, as
seen in Figure 5‐1.
Multi‐layered Security
in the Network
A multi‐layered security stack provides a new model for RTC
network architectures, with a service delivery logic layer that
defines where and when security will be applied in the net-
work (see Figure 5‐2).
Figure 5-1: New strategic approaches to security are needed as the
vulnerability gap continues to widen.

Chapter 5: Looking to the Future in Securing RTC 35
RTC services, such as voice and video, are applications that
should be routed over a network via session border control-
lers (SBCs) with policy capabilities that, in turn, programmati-
cally use the network as a security function. The idea here is
that every RTC flow is metered. The higher application levels
utilize the service delivery logic of the SBCs, via application
programming interfaces (APIs), to push appropriate policies
down through the network control interface and apply and
enforce any security decisions for each RTC flow.
The packet forwarding (or network) layer is an “enabler” to
security policy: It can augment security in the service delivery
layer by preventing a breach or attack with policies that are
implemented at the transport layer. This is what a multi‐layered
security approach is all about.
The examples in the following sections demonstrate the multi‐
layered security model in action.
Firewall and SBC sharing
contextual awareness
As I describe in Chapter 4, neither a next‐generation firewall
(NGFW) nor an SBC alone is sufficient to provide such a com-
prehensive enterprise security solution. However, an inte-
grated NGFW and SBC solution provides coverage across all
enterprise security domains, as shown in Table 5‐1.
Figure 5-2: A multi‐layered security model for the network.

An integrated NGFW and SBC solution is accomplished by
exchanging RTC context information between the NGFWs
and SBCs deployed in an enterprise or service provider
network. This integrated solution raises the trust level of
RTC by enhancing the RTC awareness of the NGFW, which
translates into
✓✓ A deeper level of RTC security at the NGFW
✓✓ A broader enforcement of security countermeasures
when RTC is attacked
Table 5-1 NGFW and SBC Integrated Security Solution
Security Domain Solution Description
Malware and
Spyware
SBCs share decrypt keys with NGFWs to
leverage full malware/spyware capabilities of
NGFWs in encrypted sessions.
SBCs provides more granular visibility into
application ID for RTC (for example, video,
audio, and file transfer) to enable NGFWs
to enforce more granular security actions/
scanning on RTC flows.
DoS (network and
application layers)
and Theft of Service
SBCs share detailed port, addressing, and
bandwidth information with NGFWs for more
restrictive admission of RTC flows (that is, the
attack surface is significantly reduced).
SBCs shares threat information with NGFWs,
enabling threats to be blocked by NGFWs
beyond RTC services.
The RTC security enforcement point moves
from the SBC to the NGFW, which can then
apply policy and actions on a much broader
scope.
Identity Management Sharing identity status (such as trusted,
unknown, bad) enables broader policy
controls.
SBC identity state can be factored into other
security actions by NGFWs.
NGFW identity state can be factored into SBC
call admission control (CAC) decisions.

Consider the following example of toll fraud using IP address
spoofing, illustrated in Figure 5‐3:
1. The attacker probes the target network by making
a call with a spoofed IP address. The call appears
normal to the firewall and is routed to the SBC.
2. The SBC asks the policy routing engine where to send
the call and authorizes the session.
3. The application server provides the voice over IP
(VoIP) service.
4. The call is routed back to the fraudulent destination,
Nigeria in this example.
5. The initial toll fraud incident may go undetected
because, in this example, the policy engine is con-
figured to allow a small volume of calls to certain
restricted countries.
6. As the toll fraud continues, the policy engine thresh-
old is met, triggering a detection alert.
7. The policy engine responds by instructing the SBC
not to accept future call attempts from the spoofed IP
address.
8. The SBC prevents future calls from the spoofed IP
address to the fraudulent destination.
Figure 5-3: RTC security example — IP address spoofing.

9. The policy engine predicts future toll fraud attempts
using analytics gathered throughout the incident.
10. The policy engine instructs the firewall to modify its
packet forwarding rules to block future requests that
match the toll fraud heuristics.
11. The firewall prevents future toll fraud attacks by
adding the source and destination IP addresses
to a blacklist.
SDN to augment
multi‐layer security
Another scenario uses software‐defined networking (SDN) to
augment the multi‐layer security stack (see Figure 5‐4).
In this case, the underlying network is used as a security
function. The network edge has a number of “white box” rout-
ers that are under SDN control. The SDN controller defines
application flows such as per flow service level agreements
(SLAs) and guaranteed bandwidth. In the multi‐layered secu-
rity model, a security perimeter is created at the farthest
egress/ingress point of the network. The higher level security
delivery logic layer programmatically tells the SDN controller
to implement a policy to move an internal rogue endpoint to
a new flow or bit bucket, or to stop ingress traffic based on a
predictive model of heuristic analytics.
Figure 5-4: SDN augments multi‐layer security to raise the security trust
level of RTC in the network.

In other words, the network is now metering based on the ser-
vice delivery logic programmatically telling the SDN controller
what policies to implement on every RTC flow. Access con-
trols or network policing can be applied on a per flow basis.
By coupling the service delivery logic (network policy and
intrusion prevention logic) to the SDN controller, the security
trust level of RTC in the network is increased as
✓✓ Every RTC flow is metered
✓✓ Data gathered by the network is fed into network analyt-
ics tools, which then configure the network automatically
and optimize it for individual applications (that is, the
higher level service delivery logic tells the SDN controller
what to do in the network)
✓✓ The SDN controller augments a multi‐layer security
network, enabling security at the transport level
Consider the following example of a distributed denial of ser-
vice (DDoS) attack using a session initiation protocol (SIP)
registration flood, illustrated in Figure 5‐5:
1. A DDoS attack floods the network with SIP
registration messages from multiple sources.
2. The SBC at the service delivery logic layer detects
the DDoS attack and SIP registration flood.
3. The SBC programmatically tells the SDN controller
to respond to the DDoS attack, based on its detection
and uses analytics to thwart future attacks.
Figure 5-5: Hosted network/cloud — SBC integration with SDN‐enabled
network control.

4. The SDN controller responds by modifying the
packet forwarding rules at the edge of the network.
5. The SDN controller prevents the DDoS attack from
succeeding at the network edge (or the security
perimeter of a virtualized SBC in the cloud).
In the same way that the SBC sends instructions to blacklist
bad IP addresses (blacklists), it can also enable whitelist
policies that ensure good traffic is always permitted to flow
through the RTC infrastructure.

TenWaysSBCsSecureRTC
In This Chapter
▶▶ Hiding the RTC network topology and preventing denial of service
attacks
▶▶ Encrypting RTC media and signaling traffic
▶▶ Preventing toll fraud and malformed packets
▶▶ Managing performance and enabling remote access
▶▶ Registering endpoints and maintaining session state awareness
Session border controllers (SBCs) play a critical role in
securing enterprise real‐time communications (RTC). In
this chapter, I outline ten key security capabilities of SBCs.
B2BUA/Network Topology Hiding
The SBC hides the network topology by acting as a back‐to‐
back user agent (B2BUA), defined in Internet Engineering Task
Force (IETF) Request for Comments (RFC) 3261. A B2BUA
divides a session initiation protocol (SIP) session into two
distinct segments: one between the endpoint and the SBC, the
other between the SBC and the IP private branch exchange
(PBX) or unified communications (UC) server.
Trunk Groups are employed at the network edge to manage
call admission, traffic controls, and other functions between
the carrier network and the peering partner; consequently,
all call signaling traffic is routed through the SBC.
Similarly, real‐time transport protocol (RTP) relay allows
media flows to be proxied through the SBC. Thus, the SBC
translates IP addresses and ports for signaling and media
Chapter 6

streams that traverse the system to hide the core network
addressing schemes and translations.
DoS and DDoS Defense (Policers)
The SBC uses specialized hardware and policing software to
deal with high traffic volumes and protect the core network
from denial of service (DoS) and distributed denial of service
(DDoS) attacks. Different policers include the following:
✓✓ Static blacklisting: IP addresses and/or network prefixes
that are discarded on ingress
✓✓ Dynamic blacklisting: Designed to detect and block
misbehaving endpoints for a configured period of time
rather than prevent malicious attacks, for which the
system employs other defense mechanisms
✓✓ Whitelisting: Static list of IP addresses and/or network
prefixes that are allowed to access the SBC
✓✓ Micro‐flow policer: Allows registered endpoints through
the SBC (primarily used in access scenarios)
✓✓ Unknown peer: Allows any unknown packet through the
SBC up to the specified packet rate limit
Encryption (Media)
RTC traffic needs to be encrypted for privacy and regulatory
compliance purposes. SBCs use secure RTP (SRTP) to encrypt
media packets and all SRTP encrypted calls are routed
through the SBC. SRTP can be used inside or outside the net-
work. SRTP on one call leg is independent of its use on other
legs of the same call, and is negotiated for each packet leg.
SBCs without dedicated encryption hardware will normally
encrypt traffic at the expense of RTC session performance.
Encryption (Signaling)
SIP signaling messages are plain text and relatively easy to
intercept. SBCs use transport layer security (TLS) and IPsec
to encrypt signaling traffic. TLS supports peer authentication,

Chapter 6: Ten Ways SBCs Secure RTC 43
confidentiality, and message integrity. IPSec supports
cryptographic protection for non‐media IP packets using
the management or packet interfaces.
Toll Fraud Protection
Toll fraud losses total more than $46 billion annually and
exceed the rate of revenue growth for the telecommunica-
tions industry. Toll fraud schemes, such as dial‐through fraud
(DTF), enable a cybercriminal to make “free” international
calls (or sell international access to other cybercriminals)
or auto‐dial premium numbers to run up fraudulent charges
against the victim organization. SBCs can be configured to dis-
able secondary dial tone sources in order to prevent toll fraud.
Malformed Packet Protection
An attacker may attempt to send malformed packets to cause
an RTC application or service to crash, or exploit a vulner-
ability that provides unauthorized access. An SBC maintains
full session state information and is therefore able to detect
and respond to attempts to send malformed packets over the
network.
Call Admission Control/
Overload Controls
Call admission control limits the number of RTC sessions that
can be simultaneously active in order to prevent network
overload. An overload can degrade the performance of other
calls on the network, or crash an RTC environment — in
effect, a self‐inflicted denial of service.
Overload threshold parameters can be configured on the
SBC based on CPU and memory utilization. When a thresh-
old is reached, the SBC adjusts the system call and registra-
tion acceptance rate up or down to maintain the target CPU
usage configured for that level. This capability maximizes the
system throughput without exceeding the desired CPU utiliza-
tion threshold. During adaptive throttling, the SBC can assign

different preferences (priorities) to normal calls, emergency
calls, and initial SIP registrations.
NAT Traversal (Remote Workers)
Enabling RTC for remote users behind firewalls performing
network address translation (NAT) can be a challenge for
enterprises. An SBC keeps firewall “holes” open by resetting
the SIP registration interval to a value lower that the firewall
port time‐to‐live (TTL) and caching SIP registrations by fire-
wall IP and port assignment.
Endpoint Registration
The SIP Signaling Registration facility enables an SBC to relay
SIP endpoint registration information between endpoints and
the Registrar. The registration facility allows different expira-
tion times on the untrusted versus trusted network. This can
be used to reduce the registration refresh load on the regis-
trars without sacrificing fast detection of failed endpoints.
Full SIP Session State Awareness
Full SIP session state awareness enables an SBC to initiate,
reinitiate, maintain, or terminate RTC sessions, as necessary.
RTC is only getting more complicated, and it’s becoming
increasingly difficult to capture and act on this information.
SBCs can dynamically process the deep RTC requirements
associated with SIP statefulness, including parsing and infer-
ring the following:
✓✓ Active and changing port numbers
✓✓ UDP service types
✓✓ Stream activity/inactivity
✓✓ Bandwidth requirements
In short, SBCs provide full SIP stack and session state knowl-
edge to protect downstream UC elements (such as phones,
PBX, the UC stack itself, and more) against DOS attacks.

WILEY END USER LICENSE AGREEMENT
Go to www.wiley.com/go/eula to access Wiley’s ebook EULA.

Secure Real Time Communications

Recommended

Recommended

More Related Content

More from Dejan Majkic

More from Dejan Majkic (12)

Recently uploaded

Recently uploaded (20)

Secure Real Time Communications