PP-Module for Enterprise Session Controllers

Version: 2.0
2025-03-28
National Information Assurance Partnership

Revision History

Contents

1 Introduction

1.1 PP Overview

The scope of this PP-Module is to describe the security functionality of an Enterprise Session Controller (ESC) in terms of [CC] and to define functional and assurance requirements for such products. This PP-Module is intended for use with the following Base-PPs:

• collaborative Protection Profile for Network Devices (NDcPP), Version 3.0e

This Base-PP is valid because a device that implements an ESC is a specific type of network device, and there is nothing about the implementation of an ESC that would prevent any of the security capabilities defined by the Base-PP from being satisfied. This PP-Module does not mandate a particular architecture; the TOE may be either standalone or distributed as permitted by the Base-PP.

1.3 Compliant Targets of Evaluation

The Target of Evaluation (TOE) that is defined by the combination of the NDcPP and this PP-Module is a network device, either a physical or virtual appliance with a non-modifiable operating system

An ESC is a privately-owned telecommunication switch where its primary function is to set up, process, and terminate voice and video calls over an enterprise-wide Internet Protocol (IP) network. ESC operation is analogous to the tasks of 1930’s telephone switchboard-operators, which is to patch (connect) together callers to callees. But today’s ESC executes switchboard operations automatically, while providing simultaneous connectivity to hundreds of callers virtually instantaneously. In addition to establishing, processing, and managing thousands of connected calls, most ESCs support auxiliary services such as VVoIP Conferencing, Voicemail, Chat, Telepresence, Encrypted Communications, and Protocol Translation for end-to-end connectivity of diverse endpoints.

ESCs are commonly known as Call Servers, Communications Servers, and Call-Processing Systems, and they vary in complexities and capabilities. The typical ESC can manage thousands of calls between diverse client devices such as VoIP-handsets, Softphones, Desktop Telepresence Systems, Room-size Video Telepresence Systems, and Mobile Devices. ESCs are normally installed within a SCIF or other entry-controlled environment, especially systems that can register numerous VVoIP endpoints. To protect the ESC, a Session Border Controller (SBC) is installed on the outer edge of the VVoIP network to help protect the ESC from external network attacks. Also note that a fairly robust ESC system includes many major components such as its own database, operating system (O/S), conferencing system, dial plan, network manager, call-signaling protocols (e.g. H.323, Session Initiation Protocol (SIP), SS7), and its own ‘Operations, Administration, and Management (OA&M)’ application system.

If any one of these major components is successfully attacked, then one can expect the entire ESC system to be negatively impacted. The intention of this PP-Module is to provide a list of security requirements needed by an ESC for protection of its functionality and protection of the VVoIP communications it is responsible for facilitating.

1.4 TOE Boundary

An ESC is a logical component of a physical hardware appliance that is responsible for establishing connectivity between VVoIP endpoints. The ESC is an advanced version of a legacy IP-PBX system. As a specific type of network device, an ESC TOE will be evaluated against both the NDcPP and this PP-Module. All functionality described by the SFRs are within the TOE boundary, as is the ability for the TSF to establish secure remote connections with trusted entities in the OE.

Figure 1 below shows a typical VVoIP infrastructure in which an ESC is deployed.

Figure 1: Representative ESC Deployment

As can be seen from this figure, the ESC’s purpose is to provide an interface between VVoIP networks in order to connect calls. The ESC depends on or communicates with a number of services that are located within the internal network such as voicemail, conferencing, Network Time Protocol (NTP), Domain Name System, and software updates that are downloaded from VVoIP endpoint manufacturers and stored on the ESC for distribution to the clients.

Certain storage capabilities may be implemented exclusively within the TOE or within both the TOE and its OE (such as the TOE maintaining an internal audit log that is also written to an external audit server).

For connecting networks, the ESC relies on edge routing to handle lower-level communications between the networks and on a SBC to filter out potentially malicious activity.

The ESC itself, which can be administered locally or remotely, consists of several different logical components, as shown in Figure 2 below.

Figure 2: ESC Components

As can be seen from the figure above, the ESC provides the following logical capabilities:

• OA&M – Responsible for providing a management interface to the ESC’s configuration.
• Call Processing – Responsible for setting up and tearing down calls between VVoIP endpoints using one or more call control protocols.
• Call Detail Records – Responsible for storage of call activity for auditing purposes.
• Voice/Video Media Conferencing, Controls, and Storage – responsible for establishing multi-way conference calls and storage of call recordings.

1.5 Use Cases

Requirements in this PP-Module are designed to address the security problem in the following use cases. Use cases are not mutually exclusive; a TOE may implement more than one of these use cases. The description of these use cases provide instructions for how the TOE and its OE should be made to support the functionality required by this PP-Module.

This PP-Module defines four potential use cases for the ESC TOE:

[USE CASE 1] Dedicated Appliance

The ESC is sold and packaged as a standalone network appliance that does not have a direct interface to the underlying platform operating system, customized application, or commercial off-the-shelf database.

[USE CASE 2] Call Processing (Connect VVoIP Calls Together)

The ESC serves as a call control system that employs multiple technologies for processing and managing voice/video calls between end-point devices. The ESC receives a call-request message from the source IP-phone (endpoint-A) and then locates and connects the call-originator to the destination device (endpoint-B). The ESC is used as a centralized system to process, manage, and connect calls between registered IP-phones. It should be noted that H.323 and SIP are the ESC’s most commonly used call-processing (i.e. call control) protocols. Both H.323 and SIP are used to set up, process, and terminate voice/video calls between endpoints. Supplemental call control protocols such as Media Gateway Control Protocol (MGCP) and SS7 do not limit ESC capabilities, but instead enhances its functionality. Both H.323 and SIP provide an ESC with the capabilities required for execution of all use cases. Both H.323 and SIP provide the ESC with call control capabilities, support trunking between the ESC and Service Providers, support trunking between an array of ESCs, and can use encryption schemes that secure the ESC’s call control functions.

[USE CASE 3] Trunk Calls to/from Telecommunications Service Provider

The ESC may support the ability to bundle numerous calls that originate from locally-registered VVoIP devices onto an ESC’s communication trunk for connectivity through a telecommunications service provider (e.g. Verizon) to remote endpoints. In this case, the ESC supports the aggregation of traffic for all registered IP devices for the purpose of passing local calls over a single trunk to an external service provider. This allows for a simplified network deployment where a single connection from the ESC to the service provider can support a large number of devices, rather than requiring each individual device to connect to the service provider separately.

[USE CASE 4] Trunk Calls in/out to Remote ESCs

Similar to trunking calls to telecommunications service providers, the ESC can trunk a large volume of calls to other remote ESCs. An example of this deployment is a meshed configuration of trunk-connected ESCs that are deployed to support a metropolitan-sized enterprise-wide VVoIP call processing network. This particular type of use case may not require any of the meshed ESCs to be connected to a service provider.

1.6 Package Usage

2 Conformance Claims

Conformance Statement

An ST must claim exact conformance to this PP-Module.

The evaluation methods used for evaluating the TOE are a combination of the workunits defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs and SARs have a sufficient level of supporting evidence in the Security Target and guidance documentation and have been sufficiently tested by the laboratory as part of completing ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation Activities that are used in this same manner.

CC Conformance Claims

This PP-Module is conformant to Part 2 (extended) and Part 3 (conformant) of Common Criteria CC:2022, Revision 1.

PP Claim

This PP-Module does not claim conformance to any Protection Profile.

There are no PPs or PP-Modules that are allowed in a PP-Configuration with this PP-Module.

Package Claim

This PP-Module is not conformant to any Functional or Assurance Packages.

3 Security Problem Definition

The security problem is described in terms of the threats that the TOE is expected to address, assumptions about its operational environment, and any organizational security policies that the TOE is expected to enforce.

The ESC is a network appliance that incorporates multiple components and protocols, and is designed with the purpose of connecting and managing calls that emanate from registered VVoIP endpoints. The ESC is also designed to provide centralized control of an enterprise-wide VVoIP communication network. As the central control system that manages and processes VVoIP calls from as many as 50,000 endpoints per node, it is critically important for the ESC to be protected because it is a single point of failure for tens of thousands of end-users.

As a centralized system the ESC is subject to attacks from the VVoIP endpoints that are registered to the ESC. Any VVoIP endpoint could be a threat to launch a malicious attack against the ESC. Therefore the ESC shall possess the security requirements needed for mitigating such a threat type.

Note that as PP-Module of the NDcPP, all threats, assumptions, and Organizational Security Policies (OSPs) defined there will also apply to an ESC TOE unless otherwise specified.

The Security Functional Requirements (SFRs) defined in this PP-Module will mitigate the threats that are defined in the PP-Module but will also mitigate some NDcPP threats in more comprehensive detail due to the specific capabilities provided by an ESC.

3.1 Threats

T.MALICIOUS_TRAFFIC

A malformed packet is a protocol packet containing modified data not recognizable by the receiving device (e.g. TOE), or contains modified protocol packets intended to crash or cause the TOE to act in ways unintended. An attacker may attempt to use a VVoIP endpoint to send these malformed packets or malicious traffic towards the TOE in an attempt to control or crash the call control system and connected network devices. To mitigate VVoIP endpoint devices from being used to successfully launch malicious traffic, the TOE must provide encryption remedies to prevent modification of protocol packets. The TOE must also provide authentication mechanisms to prevent unauthorized VVoIP endpoints from improperly registering to the ESC for the purpose of launching malicious attacks.

T.NETWORK_DISCLOSURE

An attacker may attempt to “map” IP addresses of VVoIP endpoint/devices and other telecommunications equipment for the purpose of determining the organizational structure of the enterprise, providing reconnaissance for future targeted attacks.

T.UNAUTHORIZED_CLIENT

An attacker may attempt to register an unauthorized VVoIP endpoint to the TOE for the purpose of impersonating a legitimate end user device in order to gain unauthorized connectivity to other clients or active calls.

3.2 Assumptions

This PP defines no Assumptions beyond those defined in the claimed Base-PP(s).

3.3 Organizational Security Policies

P.SECURED_PLATFORM

Administrators in the organization ensure that general purpose computers use secure operating systems and are configured in accordance with applicable security standards.

4 Security Objectives

4.1 Security Objectives for the Operational Environment

The OE of the TOE implements technical and procedural measures to assist the TOE in correctly providing its security functionality (which is defined by the security objectives for the TOE). The security objectives for the OE consist of a set of statements describing the goals that the OE should achieve. This section defines the security objectives that are to be addressed by the IT domain or by non-technical or procedural means. The assumptions identified in Section 3 are incorporated as security objectives for the environment.

This PP-Module also defines the following additional environmental objective:

OE.SECURED_PLATFORM

The operating system of the network device does not provide an interface or other capability that can be used to adversely affect the TOE or its own functionality.

4.2 Security Objectives Rationale

5 Security Requirements

• Refinement operation (denoted by bold text or strikethrough text): Is used to add details to a requirement or to remove part of the requirement that is made irrelevant through the completion of another operation, and thus further restricts a requirement.
• Selection (denoted by italicized text): Is used to select one or more options provided by the [CC] in stating a requirement.
• Assignment operation (denoted by italicized text): Is used to assign a specific value to an unspecified parameter, such as the length of a password. Showing the value in square brackets indicates assignment.
• Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier suggesting the purpose of the operation, e.g. "/EXAMPLE1."

5.1 Collaborative Protection Profile for Network Devices Security Functional Requirements Direction

This section instructs the ST author on what selections must be made to certain SFRs contained in the NDcPP in order to mitigate the threats defined in this PP-Module or to mitigate a threat from the NDcPP in a more specific or restrictive manner than what it specifies.

Full assurance activities are not repeated for the requirements in this section; only the additional testing needed to supplement what has already been captured in the Supporting Documents for the NDcPP is included.

5.1.1 Modified SFRs

5.1.1.1 Security Audit (FAU)

5.1.1.2 Cryptographic Support (FCS)

5.1.1.3 Protection of the TSF (FPT)

5.2 TOE Security Functional Requirements

5.2.1 Auditable Events for Mandatory SFRs

5.2.2 Security Audit (FAU)

5.2.3 User Data Protection (FDP)

5.2.4 Identification and Authentication (FIA)

5.2.5 Security Management (FMT)

5.2.6 Protection of the TSF (FPT)

5.2.7 Trusted Path/Channels (FTP)

5.3 TOE Security Functional Requirements Rationale

The following rationale provides justification for each SFR for the TOE, showing that the SFRs are suitable to address the specified threats:

6 Consistency Rationale

6.1 Collaborative Protection Profile for Network Devices

6.1.1 Consistency of TOE Type

6.1.2 Consistency of Security Problem Definition

6.1.3 Consistency of OE Objectives

The objectives for the TOE’s operational environment are consistent with the NDcPP based on the following rationale:

6.1.4 Consistency of Requirements

Appendix A - Optional SFRs

A.1 Strictly Optional Requirements

This PP-Module does not define any Strictly Optional SFRs or SARs.

A.2 Objective Requirements

This PP-Module does not define any Objective SFRs.

A.3 Implementation-dependent Requirements

A.3.1 Auditable Events for Implementation-Dependent SFRs

A.3.2 Protection of the TSF (FPT)

Appendix B - Selection-based Requirements

B.1 Auditable Events for Selection-based SFRs

B.2 Security Audit (FAU)

Appendix C - Extended Component Definitions

C.1 Extended Components Table

C.2 Extended Component Definitions

Appendix D - Inherently Satisfied Requirements

This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP. However, these requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.2 Dependencies between components.

Appendix E - Entropy Documentation and Assessment

The TOE does not require any additional supplementary information to describe its entropy source(s) beyond the requirements outlined in the Base-PP. As with other Base-PP requirements, the only additional requirement is that the entropy documentation also applies to the specific ESC capabilities of the TOE that require random data, in addition to any functionality required by the Base-PP.

Appendix F - Acronyms

Appendix G - Bibliography