Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Secure Real Time Communications

622 views

Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Secure Real Time Communications

  1. 1. These materials are © 2016 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
  2. 2. These materials are © 2016 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. SecuringReal‐Time Communications by Lawrence C. Miller and Walter Kenrich Sonus Special Edition
  3. 3. These materials are © 2016 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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
  4. 4. These materials are © 2016 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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
  5. 5. 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
  6. 6. These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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)
  7. 7. Securing Real-Time Communications For Dummies, Sonus Special Edition 2 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. ✓✓ 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.
  8. 8. Introduction 3 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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!
  9. 9. Securing Real-Time Communications For Dummies, Sonus Special Edition 4 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
  10. 10. These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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
  11. 11. Securing Real-Time Communications For Dummies, Sonus Special Edition 6 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  12. 12. Chapter 1: Recognizing Current Trends in Real‐Time Communications 7 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. ✓✓ 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
  13. 13. Securing Real-Time Communications For Dummies, Sonus Special Edition 8 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  14. 14. These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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
  15. 15. Securing Real-Time Communications For Dummies, Sonus Special Edition 10 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  16. 16. Chapter 2: Understanding the Threat Landscape in RTC 11 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  17. 17. Securing Real-Time Communications For Dummies, Sonus Special Edition 12 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. (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.
  18. 18. Chapter 2: Understanding the Threat Landscape in RTC 13 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  19. 19. Securing Real-Time Communications For Dummies, Sonus Special Edition 14 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  20. 20. Chapter 2: Understanding the Threat Landscape in RTC 15 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  21. 21. Securing Real-Time Communications For Dummies, Sonus Special Edition 16 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  22. 22. Chapter 2: Understanding the Threat Landscape in RTC 17 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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
  23. 23. Securing Real-Time Communications For Dummies, Sonus Special Edition 18 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  24. 24. Chapter 2: Understanding the Threat Landscape in RTC 19 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  25. 25. Securing Real-Time Communications For Dummies, Sonus Special Edition 20 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
  26. 26. These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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
  27. 27. Securing Real-Time Communications For Dummies, Sonus Special Edition 22 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  28. 28. Chapter 3: Securing Real‐Time Communications 23 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  29. 29. Securing Real-Time Communications For Dummies, Sonus Special Edition 24 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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
  30. 30. Chapter 3: Securing Real‐Time Communications 25 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  31. 31. Securing Real-Time Communications For Dummies, Sonus Special Edition 26 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. ✓✓ 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.
  32. 32. These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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
  33. 33. Securing Real-Time Communications For Dummies, Sonus Special Edition 28 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  34. 34. Chapter 4: Understanding Why a Firewall Can’t Secure RTC 29 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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)
  35. 35. Securing Real-Time Communications For Dummies, Sonus Special Edition 30 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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)
  36. 36. Chapter 4: Understanding Why a Firewall Can’t Secure RTC 31 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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).
  37. 37. Securing Real-Time Communications For Dummies, Sonus Special Edition 32 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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
  38. 38. These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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
  39. 39. Securing Real-Time Communications For Dummies, Sonus Special Edition 34 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  40. 40. Chapter 5: Looking to the Future in Securing RTC 35 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  41. 41. Securing Real-Time Communications For Dummies, Sonus Special Edition 36 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  42. 42. Chapter 5: Looking to the Future in Securing RTC 37 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  43. 43. Securing Real-Time Communications For Dummies, Sonus Special Edition 38 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  44. 44. Chapter 5: Looking to the Future in Securing RTC 39 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  45. 45. Securing Real-Time Communications For Dummies, Sonus Special Edition 40 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  46. 46. These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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
  47. 47. Securing Real-Time Communications For Dummies, Sonus Special Edition 42 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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,
  48. 48. Chapter 6: Ten Ways SBCs Secure RTC 43 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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
  49. 49. Securing Real-Time Communications For Dummies, Sonus Special Edition 44 These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited. 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.
  50. 50. These materials are © 2016 John Wiley Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
  51. 51. WILEY END USER LICENSE AGREEMENT Go to www.wiley.com/go/eula to access Wiley’s ebook EULA.

×