In this section:
The Sonus 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 Sonus 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 Sonus SBC Core product documentation.
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.
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.
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:
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.
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.
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:
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.
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: