DO NOT SHARE THESE DOCS WITH CUSTOMERS!

This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.

In this section:

Product Overview

The Ribbon Session Border Controller (SBC) Core platform is a security appliance that provides functionality to help protect a network. The SBC is often deployed with one or more interfaces facing an untrusted network. This documentation addresses securing the Ribbon SBC from attack. While it is possible for an uncompromised SBC with inappropriate provisioning to allow attacks on the network, a more insidious threat is the possibility of a compromised SBC allowing an attacker to re-provision the SBC and thereby opening attack windows on the network the SBC is protecting. This material focuses mostly on protecting the SBC itself with the understanding that the goal of such an attack is often to manipulate provisioning so as to attack other network elements.

Securing the customer's network is accomplished through appropriate provisioning of the SBC and its wide range of security mechanisms and capabilities, such as encryption, traffic policing, topology hiding, access control and many other additional security features. Details on each of these functional components are captured throughout the Ribbon SBC Core product documentation.

Securing the SBC

The SBC is engineered according to widely-recognized security principles:

 

Defense in depth—The SBC uses a layered system of redundant and diverse defenses, so that there are secondary defenses available in case the primary ones fail.

General and adaptable defenses—The SBC uses defenses that are as broad as possible, to minimize the possibility of circumvention.

Minimized system—No unnecessary packages or network services are present.

Least-privilege model—Software processes, operator accounts, etc. are all given the minimum access and privileges needed to accomplish their jobs.

Detection and response—The SBC does extensive audit and event logging. It detects and reports on potential attacks and anomalies so that automatic and manual responses can be brought to bear.

Hardened code—The code is carefully developed, and is inspected through both manual review and automated code scanning for defects that might create security vulnerabilities.

Robust cryptographic protection for external interfaces—Supports standards-based encryption protocols such as IPsec, TLS, and SRTP.

 

Each of these implementation choices helps to make the SBC more secure; however no system is perfectly secure. This best practices guide describes configuration and operational choices that can help to further reduce the risk of successful attacks, and to ensure that attacks (both successful and unsuccessful) are unlikely to go unnoticed.

Threat Model

The role of the SBC in securing the network relies on both properly provisioning the system and proper behavior in response to this provisioning. Beyond simply providing the promised security services, there is also an implicit requirement that the SBC not become a 'bad actor' (For example, by originating DOS attacks on other parts of the network). Certain aspects of the SBC functionality demand that the SBC work with Personal information or data that is confidential for other reasons (such as support of Lawful Intercept). As a result, the SBC is also subject to information disclosure threats.

Elevation of Privilege

This threat type refers to attacks on the system where authorized users are able to accomplish activities they are not authorized to perform (including attackers who are not authorized to perform any task); it also includes attacks by individuals performing operations that they are not authorized to perform. While Elevation of Privilege is focused on activities originating from administrative accounts (CLI/EMA logins), it also addresses illicit access to other accounts on the system. The following table provides a summary of the privileges of concern:

Elevation of Privilege Types

PrivilegeDetails 
BMC AccessThe BMC is present on all SBC hardware appliances. The BMC provides access to the underlying Linux console and also forces reboots of the system, potentially providing access to the boot configuration.
Hypervisor ConsoleMany virtual or cloud SBC deployments provide a hypervisor console which exposes many of the same security risks as the appliance BMC; however, Hypervisor consoles are not described explicitly in the remainder of this document since they are outside of the product scope of the Ribbon SBC.
Account Access

The SBC includes the following account types:

  • Linux access accounts – The SBC is provisioned with a variety of different Linux accounts with different permissions this includes the traditional Linux root account which provides effectively unlimited access to the platform.
  • Internal accounts – The SBC implements a set of internal accounts.
  • Platform Manager account – The Platform manager is a web-interface that is available without the full application up and running.
  • Administrative accounts – These are accounts primarily for the primary EMA and CLI interfaces. They are used to provision the services provided by the SBC and to manage the SBC. There are several different types of accounts with different privileges.

Refer to Managing SBC Core Users and Accounts for additional account details.

End-UsersEnd-users (and other network end-points) who may have call or other types of sessions on the system.

The threat model is concerned with illicit access to any of these accounts; the risk is higher at the top of this list since privilege at these levels is more easily exploited to provide privileges lower in the list.

 

Information Disclosure

Personal information on the SBC is stored in an unencrypted fashion. An important element of this information is the Call Detail Record (CDR) contents. This unencrypted information is readily available from the administrative interface and Linux accounts. This information would also become available via the internal database access account should that account become accessible. Consequently, it is important to manage information disclosure by managing elevation of privilege. It is also important to ensure that only individuals who actually need administrative access are provided with administrative accounts. 

Access to Lawful Intercept information is controlled using special administrative accounts.

 

Non-Repudiation

The SBC logs administrative activities in independent log files which are subject to attack at the Linux account level because they are stored in unprotected text format. The following methods are available to move these log files off of the device, thus largely mitigating direct non-repudiation attacks:

  • Remote syslog
  • SFTP

Denial of Service

Denial of service attacks are possible on the service (SIP and media) interfaces and the platform itself via an elevation of privilege attack. For example, an attacker with access to the BMC can simply request the device to power down.

Ribbon Security Principles

The SBC threat model leads to a focus on elevation of privilege attacks.The SBC implements a defense-in-depth architecture to defend itself from these attacks, and includes the following elements:

  • Deployment model – accessibility of Administrative and BMC interfaces on the network
  • Operational processes – management of accounts, passwords, log files, etc. (Refer to Managing SBC Core Users and Accounts)
  • Platform Configuration
  • Built-in capabilities, system attributes, and development processes including use of encrypted management interfaces, minimization of SUID usage, static and dynamic security scans, and third party penetration testing