Securing Real-Time Communications For Dummies®, 2nd Ribbon ... · Any dissemination, distribution, or unauthorized use is strictly prohibited. be massively scaled with on premises,

These materials are © 2019 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.

Securing Real-Time

Communications

2nd Ribbon Special Edition

By Lawrence C. Miller and Walter Kenrich


Securing Real-Time Communications For Dummies®, 2nd Ribbon Special Edition

Published byJohn Wiley & Sons, Inc.111 River StreetHoboken, NJ 07030-5774www.wiley.com

Copyright © 2019 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, the Wiley logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, 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. Ribbon and the Ribbon logo are registered trademarks of Ribbon Communications, Inc. 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 [email protected], or visit www.wiley.com/go/custompub. For information about licensing the For Dummies brand for products or services, contact BrandedRights&[email protected].

ISBN: 978-1-119-60151-7 (pbk); ISBN: 978-1-119-60152-4 (ebk)

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

Publisher’s Acknowledgments

We’re proud of this book and of the people who worked on it. Some of the people who helped bring this book to market include the following:

Project Editor: Carrie Burchfield-Leighton

Acquisitions Editor: Katie Mohr

Editorial Manager: Rev Mengle

Business Development Representative: Sue Blessing

http://www.wiley.com

http://www.wiley.com/go/permissions

mailto:[email protected]

http://www.wiley.com/go/custompub

mailto:BrandedRights&[email protected]

Table of Contents iii


Table of ContentsINTRODUCTION ............................................................................................... 1

About This Book ................................................................................... 1Foolish Assumptions ............................................................................ 2Icons Used in This Book ....................................................................... 2Beyond the Book .................................................................................. 3Where to Go from Here ....................................................................... 3

CHAPTER 1: Recognizing Current Trends in Real-Time Communications .......................................................................... 5Shifting Business from Circuit-Switched Voice to SIP Communications ............................................................................ 5Remote Worker Use Cases and BYOD Are Pervasive ...................... 6RTC Increases Productivity — and Risk ............................................. 7

CHAPTER 2: Understanding the Threat Landscape in RTC ..................................................................................................... 9RTC Attacks Are on the Rise ................................................................ 9RTC Threats Are Rapidly Evolving ..................................................... 10

Denial of Service (DoS) ................................................................. 11Toll fraud ........................................................................................ 14Identity theft .................................................................................. 16

Exposing New Attack Vectors with RTC ........................................... 17Linux and COTS ............................................................................. 17Porous firewalls ............................................................................. 18RTC traffic flows — signaling and media .................................... 19

CHAPTER 3: Securing Real-Time Communications ....................... 21Encrypting RTC Signaling and Media ............................................... 21Complying with Regulatory Requirements ..................................... 24Looking at the Cost of “No Security” in RTC .................................... 24

CHAPTER 4: Understanding Why a Firewall Can’t Secure RTC ....................................................................................... 27Understanding the Role of Firewalls and SBCs .............................. 27Comparing Firewalls and SBCs ......................................................... 29

Securing Real-Time Communications

iv Securing Real-Time Communications For Dummies, 2nd Ribbon Special Edition


CHAPTER 5: Looking to the Future in Securing RTC ..................... 33New Strategic Approaches to RTC Security Are Needed ............... 33Multi-layered Security in the Network ............................................. 34

Firewall and SBC sharing contextual awareness ...................... 35SDN to augment multi-layer security ......................................... 38

CHAPTER 6: Ten Ways SBCs Secure RTC ................................................. 41B2BUA/Network Topology Hiding .................................................... 41DoS and DDoS Defense (Policers) .................................................... 42Encryption (Media) ............................................................................. 42Encryption (Signaling) ........................................................................ 43Toll Fraud Protection ......................................................................... 43Malformed Packet Protection ........................................................... 43Call Admission Control/Overload Controls ..................................... 43NAT Traversal (Remote Workers) ..................................................... 44Endpoint Registration ........................................................................ 44Full SIP Session State Awareness ..................................................... 44

Introduction 1


Introduction

Recent high-profile cyberattacks have many organizations understandably focusing their security efforts on prevent-ing 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) applica-tions, systems, and networks — including voice over IP (VoIP) and unified communications (UC) — which can be directly targeted as attack objectives in themselves, 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, enterprises 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 BookSecuring Real-Time Communications For Dummies, 2nd Ribbon Special Edition, consists of six short chapters that explore

» Current trends in RTC, including the shift to session initia-tion 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 scenarios, understanding application reachability issues, and meeting regulatory compliance requirements (Chapter 3)

» The differences between firewalls and session border controllers (SBCs) (Chapter 4)

2 Securing Real-Time Communications For Dummies, 2nd Ribbon Special Edition


» Emerging trends in securing RTC (Chapter 5)

» Key capabilities that an SBC brings to the fight in securing RTC (Chapter 6)

Foolish AssumptionsIt’s been said that most assumptions have outlived their useless-ness, but we assume a few things nonetheless!

Mainly, we assume that you’re 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 tech-nical 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 reading any-way. 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 BookThroughout this book, we 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, we hope you enjoy the book, and please take care of your writers. Seriously, this icon points out helpful suggestions and useful nuggets of information.

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!

Introduction 3


Beyond the BookThere’s only so much we 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.ribboncommunications.com.

Where to Go from HereWith 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, 2nd Ribbon 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 interest, 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 (although we don’t recommend upside down or backwards).

We promise you won’t get lost falling down the rabbit hole!

https://ribboncommunications.com/

CHAPTER 1 Recognizing Current Trends in Real-Time Communications 5


Chapter 1

IN THIS CHAPTER

» Evolving from legacy phone systems to SIP-enabled telephony

» Enabling the digital workplace

» Addressing increased risk in RTC environments

Recognizing Current Trends in Real-Time Communications

I n this chapter, we 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 primarily 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 function-ality of modern RTC systems and applications — provided little more than dial tone to a desk phone.

Many modern RTC systems use standard server and networking 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 functional-ity, such as video and web conferencing, instant messaging, pres-ence, 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 consid-erably 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 unified com-munications (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

» 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.

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


» 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 mobility 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 employ-ees 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 allowing 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 cus-tomers. 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 RiskThere was a time when IT and security managers rarely lost sleep over the threat of a potential attack against their voice commu-nications systems and networks, but the migration from leg-acy 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 compro-mised customer data can generate stiff penalties and losses total-ing several millions of dollars.

As enterprises implement and increasingly rely on RTC, they must also enforce RTC security. Enterprises must protect their network boundaries against internal security risks (for example, employ-ees 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.

CHAPTER 2 Understanding the Threat Landscape in RTC 9


Chapter 2

IN THIS CHAPTER

» Recognizing threat actors and their tools and motivations

» Looking at evolving RTC threats

» Discovering new attack vectors in RTC

Understanding the Threat Landscape 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 RiseThe proliferation of enterprise RTC — voice over IP (VoIP) and unified communications (UC) — and the widespread and rapidly growing availability of surreptitious tools for intercept-ing IP packets and cracking code, make it increasingly easy for attackers to target RTC.

For example, attackers can freely download network proto-col analyzers to capture and interpret VoIP calls, record media streams, and intercept instant messaging (IM) communications. Other tools, such as UCSniff, can be used to identify, record, and replay VoIP conversations or IP videoconferencing sessions.


SIP-sniffing software is readily available on the Internet, which makes securing RTC particularly challenging.

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 extor-tion schemes. In fact, cybercrime has become so lucrative that a cottage industry of global hackers-for-hire — selling their ser-vices on a contract basis — has been created.

Rogue nations are also increasingly involved in cyberespionage, cyberterrorism, and cyberattacks against defense, government, 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 EvolvingThere are many variants of RTC threats (see Figure 2-1); however, 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, eavesdropping, 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.




Denial of Service (DoS)Denial of Service (DoS) attacks were virtually non-existent in leg-acy 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 we discuss in Chapter 1, such legacy systems are costly, and lack the scalability, innovation, and functionality that modern enterprises require.

Unfortunately, DoS attacks have new and specific applications in RTC. For example, an attacker can disrupt a target organization’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 environ-ment 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 extor-tion (demanding a ransom payment from the victim organiza-tion to suspend the attack) or other financial gain (cybercriminals are sometimes paid to target a specific organization), as well as publicity for a political or social cause.

FIGURE 2-1: RTC threats are rapidly evolving.



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 cus-tomer support and public relations, and, in some cases, litigation and civil penalties.

With media attention largely focused on cyberattacks involving data theft, DoS attacks may seem irrelevant and rare, but the fre-quency and impact of these attacks may surprise you.

According to research by the Ponemon Institute and security con-tent 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 and 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).

FIGURE 2-2: A SIP registration flood is one example of a DDoS attack against RTC.


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 differentiate “good” registrations from “bad” ones. Although it may be pos-sible 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, discussed 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 num-bers 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 com-plicate 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 sessions, rather than vari-ous 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 consumption (see Figure 2-3).

FIGURE 2-3: TDoS attacks target RTC sessions directly.




Another form of TDoS simply requires the attacker to direct high call volumes to a server, either consuming all of the server’s resources, or preventing legitimate users from accessing a spe-cific number by flooding it with bogus traffic and keeping ses-sions active for extended durations. TDoS attacks are usually automated, but can also involve large groups of individuals orga-nized through social networking.

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 bandwidth 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 fraudToll 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 exam-ple, to make international calls or use other toll services. In other cases, a cybercriminal might gain access to special classes of numbers to extract revenue, such as repeatedly calling a duplic-itous 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 over the same period. More ominously, toll fraud losses are growing at a faster rate than global telecommunications 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 premium num-ber to generate fraudulent revenue that is charged to the target enterprise (see Figure 2-4).



Attackers may use DTF themselves to generate revenue directly, or they may sell access to the compromised PBX to other cyber-criminals to generate calls. DTF calls are usually short and vari-able in duration, and are usually generated outside 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, compressed video, essentially defrauding the interconnect network 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 prob-ability of a recipient picking up the call. Other risks associated with SPIT include denial of service and unauthorized use of net-work bandwidth. In the same vein, SPIM involves sending unso-licited 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 end-point. 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 theftIdentity theft is a common objective in many types of cyberat-tacks, 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 proto-cols, 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 identity allows a cybercriminal to impersonate a legitimate user in an RTC session.

There are many well established authentication and encryption 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 organization’s RTC environment.

Although authentication may help to prevent illicit access to RTC services, without encryption it doesn’t prevent certain signal-ing 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 effective a tool as email phishing is for cybercriminals, it is absolutely amaz-ing how willing people are to disclose personal information to a live voice on the other end of a phone. Many legitimate U.S. busi-nesses 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 security, many criminal organizations are known to set up their own call centers to extract information from hapless victims.



Exposing New Attack Vectors with RTCHacking into RTC sessions requires that the malicious party intercept signaling and/or media flowing between two endpoints at any of several points along the communications path. Several potential points of attack — or attack vectors — exist in RTC ses-sions, 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 end-points in a voice, video, or instant messaging stream, may be used. Modifying, disrupting, or lowering the quality of IP com-munications in this manner can have a variety of adverse effects on the enterprise. For example, an attacker can modify or dis-card 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 COTSUnlike legacy circuit-switched TDM PBXs that were often com-prised of proprietary hardware and software, many RTC sys-tems use open source Linux operating systems and commercial 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 safeguarded 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 firewallsRTC 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 combina-tions) 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 segments with traffic that could hinder or knock out other enterprise systems and services.

For example, enterprises using SIP for remote user connectivity 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 out-going connections 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 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).

FIGURE 2-5: SIP sessions create dynamic firewall rules (or “holes”) that can be used for network penetration by an attacker.



More than 50 percent of all cyberattacks were SIP-based in 2016, and the annual cost of SIP attacks alone was estimated at $11.7 billion, according to CFCA, the SIP Forum, and Telecom Reseller.

RTC traffic flows — signaling and mediaIt isn’t uncommon for network administrators to assume RTC protocols are inherently secure. After all, you need specialized codec algorithms to make sense of an RTP flow, for example. 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.

CHAPTER 3 Securing Real-Time Communications 21


Chapter 3

IN THIS CHAPTER

» Securing RTC signaling and media with encryption

» Maintaining regulatory compliance

» Seeing how “no security” costs you in RTC

Securing Real-Time Communications

In this chapter, you learn about the role of encryption in secur-ing real-time communications (RTC), as well as regulatory compliance issues.

Encrypting RTC Signaling and MediaTo 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 controllers (SBCs) to provide call admission control (CAC) and protect against denial of service (DoS) attacks

» Signaling and media encryption of RTC sessions, including those sessions stored on voice messaging and call recording systems



While many enterprises have implemented VPN and border secu-rity technologies to protect their IP-based data networks, the encryption of RTC signaling and media is a unique consideration 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 cryp-tography. SRTP provides encryption (and decryption) of the RTP media used in RTC applications (such as conferencing 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 authentication to verify the identity of session endpoints.

» Message integrity: This ensures that media and signaling 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.



However, deploying TLS, IPsec, and SRTP encryption in the enter-prise 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 perfor-mance 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 network or an SBC that performs encryption from the main CPU can add unwanted latency to RTC sessions or compromise 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 sessions including voice, video, instant messaging (IM), and collabora-tion apps. To reduce cost and network complexity, enter-prises 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 redundant, 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 “Looking at the Cost of No Security in RTC”). In an RTC environment, voice, video, and other media are other forms of IP-based data in the network that must also be safeguarded.

Eavesdropping, or the unauthorized interception of RTC traffic 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 impersonation or registration hijacking. To coun-ter the eavesdropping threat, enterprises and service providers 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 purpose of regulatory com-pliance directly, or for quality control purposes in a call center, must be able to replicate all SIP signaling and media to a record-ing server(s), as well as to the intended recipient. Organizations must also be able to replicate 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, compromised passwords, denial of service, financial fraud, and identity theft, among others. Those same risks apply to real-time communica-tions as well, though they may manifest themselves as different threats, such as eavesdropping, telephony denial of service (TDoS) attacks, and automatic number identification (ANI) spoofing tar-geting 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, pri-vate, 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 numbers 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 environment 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 man-datory credit monitoring services. In some cases, a business may have its card processing privileges 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 intercep-tion and decryption, and securing internal 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 companies; 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 information system on behalf of a federal agency; relevant VoIP/UC issues for FISMA include System and Information Integrity (SI) require-ments, 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 employees 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.

CHAPTER 4 Understanding Why a Firewall Can’t Secure RTC 27


Chapter 4

IN THIS CHAPTER

» Defining the role of firewalls and SBCs in RTC security

» Recognizing different capabilities in firewalls and SBCs

Understanding Why a Firewall Can’t Secure RTC

In this chapter, you learn about the role of session border control-lers (SBC) in real-time communications (RTC), and why a fire-wall 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 configuration, 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 connections are permitted to and from the server or endpoint based on a stati-cally configured rule base that allows or blocks specific port con-nections that correspond to specific source and destination IP address combinations.

Different firewall types include static or dynamic packet filtering firewalls, stateful inspection firewalls, proxy servers, application firewalls, and next-generation firewalls (NGFWs).



The most commonly deployed types of enterprise firewalls today are dynamic packet filtering and stateful inspection firewalls. However, NGFWs — generally recognized to have superior secu-rity 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 function 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 environment, 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.



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 SBCsFirewalls and SBCs provide different security functions in a con-verged IP data and RTC network. Table 4-1 provides a summary comparison of key firewall and SBC functionality and capabilities.

When developing an RTC security strategy, you should consider four key RTC threat vectors:

» UC as a delivery mechanism for malware and/or spyware

» Denial of service along two vectors, each of which compro-mises 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, malformed 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 different attack vectors.

TABLE 4-2 NGFW Scorecard for RTC SecuritySecurity 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, validation, and session state to protect downstream RTC elements

TABLE 4-1 Firewalls versus SBCsFirewall 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 application firewalls, proxy servers, and NGFWs)

Fully state-aware at OSI layers 2 (data link) through 7 (application)

Inspects and modifies only application layer addresses (such as SIP and session description protocol or SDP, and others)

Inspects and modifies any application 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-3 SBC Scorecard for RTC SecuritySecurity 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 awareness 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 awareness from beginning to end of call.

An SBC understands the negotiated services (for example, audio/video/collaboration) and provides tight management of per-session bandwidth utilization.

Identity management [strong]

Tracks the multiple states of authentication as RTC users advance from untrusted, through known but not validated, to fully trusted states

Strong understanding of the validity of user identity in the context of the RTC stack

Security Domain Capabilities

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 management [modest]

Can effectively identify RTC applications and whether they should be allowed into the network (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).

CHAPTER 5 Looking to the Future in Securing RTC 33


Chapter 5

IN THIS CHAPTER

» Recognizing the widening vulnerability gap

» Countering RTC threats with a multi-layer security stack

Looking to the Future in Securing RTC

In this chapter, you explore the need for a comprehensive secu-rity strategy to address the widening vulnerability gap in enter-prise 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 proliferation of mobile bring your own device (BYOD) and cloud comput-ing trends that blur the border between the internal and external network and introduce pervasive vulnerabilities throughout the network.



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 inno-vation is creating an ever widening vulnerability gap, as seen in Figure 5-1.

Multi-layered Security in the NetworkA multi-layered security stack provides a new model for RTC net-work architectures, with a service delivery logic layer that defines where and when security will be applied in the network (see Figure 5-2).

RTC services, such as voice and video, are applications that should be routed over a network via session border controllers (SBCs) with policy capabilities that, in turn, programmatically use the net-work 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 inter-face and apply and enforce any security decisions for each RTC flow.

FIGURE 5-1: New strategic approaches to security are needed as the vulnerability gap continues to widen.



The packet forwarding (or network) layer is an “enabler” to secu-rity 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 awarenessAs we 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 integrated NGFW and SBC solution provides coverage across all enterprise security domains, as shown in Table 5-1.

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

FIGURE 5-2: A multi-layered security model for the network.



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.

TABLE 5-1 NGFW and SBC Integrated Security SolutionSecurity Domain Solution Description

Malware and Spyware SBCs share decrypt keys with NGFWs to leverage full malware/spyware capabilities of NGFWs in encrypted sessions.

SBCs provide 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 share 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.



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 configured to allow a small volume of calls to certain restricted countries.

6. As the toll fraud continues, the policy engine threshold 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.

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.

FIGURE 5-3: RTC security example — IP address spoofing.



SDN to augment multi-layer securityAnother 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” routers that are under SDN control. The SDN controller defines application flows such as per flow service level agreements (SLAs) and guaran-teed bandwidth. In the multi-layered security model, a security perimeter is created at the farthest egress/ingress point of the network. The higher level security delivery logic layer program-matically 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.

In other words, the network is now metering based on the service delivery logic programmatically telling the SDN controller what policies to implement on every RTC flow. Access controls or net-work 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 analytics 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)

FIGURE 5-4: SDN augments multi-layer security to raise the security trust level of RTC 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 service (DDoS) attack using a session initiation protocol (SIP) registra-tion 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.

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 perim-eter 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.

FIGURE 5-5: Hosted network/cloud — SBC integration with SDN-enabled network control.

CHAPTER 6 Ten Ways SBCs Secure RTC 41


Chapter 6

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

Ten Ways SBCs Secure RTC

Session border controllers (SBCs) play a critical role in secur-ing enterprise real-time communications (RTC). In this chapter, we outline ten key security capabilities of SBCs.

B2BUA/Network Topology HidingThe 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 ses-sion 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 communica-tions (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 streams that tra-verse 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 com-pliance 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 network. 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.

CHAPTER 6 Ten Ways SBCs Secure RTC 43


Encryption (Signaling)SIP signaling messages are plain text and relatively easy to inter-cept. SBCs use transport layer security (TLS) and IPsec to encrypt signaling traffic. TLS supports peer authentication, confidentiality, and message integrity. IPsec supports cryptographic protection for non-media IP packets using the management or packet interfaces.

Toll Fraud ProtectionToll fraud losses total more than $46 billion annually and exceed the rate of revenue growth for the telecommunications industry. Toll fraud schemes, such as dial-through fraud (DTF), enable a cybercriminal to make “free” international calls (or sell inter-national access to other cybercriminals) or auto-dial premium numbers to run up fraudulent charges against the victim orga-nization. SBCs can be configured to disable secondary dial tone sources in order to prevent toll fraud.

Malformed Packet ProtectionAn attacker may attempt to send malformed packets to cause an RTC application or service to crash, or exploit a vulnerability 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 ControlsCall 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 net-work, 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 threshold is reached, the SBC adjusts the system call and registration 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 utilization 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 net-work 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 than the firewall port time-to-live (TTL) and caching SIP registrations by firewall IP and port assignment.

Endpoint RegistrationThe SIP Signaling Registration facility enables an SBC to relay SIP endpoint registration information between endpoints and the registrar. The registration facility allows different expiration times on the untrusted versus trusted network. This can be used to reduce the registration refresh load on the registrars without sacrificing fast detection of failed endpoints.

Full SIP Session State AwarenessFull SIP session state awareness enables an SBC to initiate, reini-tiate, 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 inferring 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 knowledge to protect downstream UC elements (such as phones, PBX, the UC stack itself, and more) against DoS attacks.

http://dummies.com

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

http://www.wiley.com/go/eula

Documents

Securing Real-Time Communications For Dummies®, 2nd Ribbon ... · Any dissemination, distribution, or unauthorized use is strictly prohibited. be massively scaled with on premises,