Winter Is Coming: Forget the Firewall and Layer Up

Tuesday, October 25, 2016

Myk Konrad

C834d47d31dd1a1b3371bda639105c59

The chill in the air can only mean one thing: denial-of-service (DoS) attacks are coming. During the holidays, DoS attacks rise as hackers look to wreak havoc on enterprise e-commerce sites and call centers during retail’s busiest season. But the hackers will never breach your firewalls, right? Wrong. They’ll simply go around your firewalls and look for a potentially weaker chink in your network’s armor: your real-time communications (RTC) applications (i.e., Unified Communications (UC) applications and SIP-enabled Private Branch Exchanges (PBXs)).  

Over the years, enterprises have migrated their traditional voice and video networks to a common IP architecture based on Session Initiation Protocol (SIP) communications. SIP simplifies the data center, reduces costs and enables new features for UC. SIP also exposes voice and video endpoints to new IP-based threats, embedded malware and DoS attacks. Firewalls—even advanced next-generation firewalls—are not designed to protect SIP endpoints. Session Border Controllers (SBCs), on the other hand, are designed to do just that.  

It’s a Cold, Cold World Out There

While SIP-based attacks haven’t been around as long as Internet-based hacks, they’ve attracted more attention from criminals because of their rate of success and their profitability. For 2015, the Communications Fraud Control Association (CFCA) estimated global losses for communications fraud at more than $38 billion. To put that into perspective, global credit card fraud is estimated at a little over $16 billion each year.  

In a relatively brief span of time, criminals have compiled an impressive arsenal of communications hacks including:  

DoS Attacks

DoS attacks look to take down a website, server or call center by flooding the target with SIP requests or registrations. They can originate from a mass of compromised endpoints (known as a “botnet”) in the form of a Distributed DoS (DDoS) attack, or be targeted specifically to a telephony endpoint in a Telephony DoS (or TDoS) attack. The number of DoS attacks is doubling each year, with the average attack causing 54 minutes of downtime. DoS attacks are also highly destructive, costing enterprises an average of $40,000 for each hour of downtime—a sobering thought when you consider that one in five DoS attacks will last five days or more.  

Toll Fraud

In the case of toll fraud, criminals hack into an enterprise’s communications system to make long-distance calls (usually international calls), direct calls to their own pay-per-minute numbers or even stage ad hoc long-distance provider services using the enterprise as their communications hub. The cost of toll fraud can quickly escalate, as one small business found when they received a $900,000 phone bill for long-distance calls to Somalia!  

Unauthorized Network Access

As SIP networks and data networks are part of the same network infrastructure, hackers have discovered that they can often enter the network through unsecured SIP channels. Once in the network, they can then steal data, launch malware or simply “hide” in the network until it’s time to strike. Because SIP communications require security “pinholes” to carry on their conversations, they represent a more accessible port of entry for broader network attacks.  

Yes, it’s a dangerous world out there, and it’s only going to get worse as enterprises decentralize their security policies to accommodate Bring Your Own Device (BYOD) policies and personal cloud app choices on enterprise devices. Compounding this exposure is the ease with which hacking services can be obtained. Today, a DoS attack that can cost enterprise thousands of dollars per hour in losses can be purchased online for less than $100 per hour. Hacking as a service has led to the consumerization of cybercrime.  

Without a Multi-Layer Security Approach, You’re Not Covered

SBCs should be your first layer of protection against SIP-based attacks. Unlike a traditional firewall, SBCs go beyond security to act as a Swiss army knife of session management, providing policy enforcement, load balancing, DDoS protection, network/traffic analysis, billing services and protocol/media interworking, in addition to general security features (encryption, blacklisting, etc.). SBCs deliver a rich set of capabilities designed to protect real-time communications, including:

  • Media (Secure RTP) and signaling (IPsec) encryption
  • Malformed packet detection
  • Call admission and overload controls
  • White/gray/blacklisting
  • Back-to-Back User Agent (B2BUA) to hide the network topology
  • Embedded policy servers  

For a strengthened security posture, SBCs should be integrated with other layers of your network’s security to create a consistent defense system against network attacks. Specifically, enterprises need to enforce security consistently at the network, policy and application layers in order to be effective. By controlling the flow of real-time communications at every layer and pushing security policies from the top down through the network, enterprises can ensure that the benefits of SIP security don’t stop where the SBC ends. This multi-layered approach to security becomes especially important as enterprises move to virtualized and cloud-based architectures, where network functions exist as logical rather than physical entities.  

Multi-Layer Security in Action

Let’s look at two examples where a multi-layer security approach can stop fraud in its tracks. In our first example, we look at an external toll fraud attack. This could be an attack with the intent of making free international calls, using the network as the host for a rogue service provider or routing calls to the hacker’s own pay-per-minute number. Any of these incoming calls might look normal to a firewall, but an SBC’s policy engine could flag the calls as suspicious. For example, if a phone is placing a high number of calls to Nigeria, the SBC could then add that endpoint to its blacklist and share the list with the network firewalls so that any calls from that endpoint are now blocked at the furthest edge of your network. SBCs are able to detect suspicious traffic patterns such as a high frequency of calls outside of normal work hours. By creating policies around this information that can be enforced at the network and application layers, enterprises can now block fraudulent traffic along the network perimeter (SBCs, firewalls) and between the individual network routers for better, blanketed security.   

Next, let’s look at DDoS attacks. In the case of a registration flood, there are normal flood patterns (e.g., endpoints coming back online after an outage) and abnormal flood patterns. Distinguishing one from the other is the role of the SBC, but it’s not enough to simply stop a DoS attack at the SBC level—enterprises ideally should be able to stop a DoS attack at the farthest edge of their network. In a multi-layer security framework, the SBC could share its pattern-recognition results with the network-level policy engine (and vice versa) to establish new packet admission rules along the edge of the network. In this way, every RTC traffic flow would be monitored and security policies would be applied consistently throughout the network.  

By thinking of security in terms of layers, enterprises limit their exposure and ensure that hackers get the cold shoulder when they come knocking at the network. With the holidays around the corner, bundling up on security is the best thing you can do to protect your revenue from the cold realities of cybercrime.

Possibly Related Articles:
22039
Cloud Security Network->General Enterprise Security
DoS DDoS DDoS Protection SBC
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.