Physical security

It is important to provide physical security to Equinix Meet-Me Room locations and Cisco Dedicated Instance Data Center facilities. When physical security is compromised, simple attacks such as service disruption by shutting down power to a customer’s switches can be initiated. With physical access, attackers could get access to server devices, reset passwords, and gain access to switches. Physical access also facilitates more sophisticated attacks such as man-in-the-middle attacks, which is why the second security layer, the network security, is critical.

Self-Encrypting drives are used in Dedicated Instance Data Centers that host UC applications.

For more information about general security practices, refer to the documentation at the following location: https://www.cisco.com/c/en/us/solutions/enterprise/design-zone-security/index.html.

Network security

Partners need to ensure that all the network elements are secured in Dedicated Instance infrastructure (which connects via Equinix). It is partner’s responsibility to ensure security best practices such as:

• Separate VLAN for voice and data

• Enable Port Security which limits the number of MAC addresses allowed per port, against CAM table flooding

• IP Source Guard against spoofed IP addresses

• Dynamic ARP Inspection (DAI) examines address resolution protocol (ARP) and gratuitous ARP (GARP) for violations (against ARP spoofing)

• 802.1x limits network access to authenticate devices on assigned VLANs (phones do support 802.1x)

• Configuration of quality of service (QoS) for appropriate marking of voice packets

• Firewall ports configurations for blocking out any other traffic

Endpoints security

Cisco endpoints support default security features such as signed firmware, secure boot (selected models), manufacturer installed certificate (MIC), and signed configuration files, which provide a certain level of security for endpoints.

In addition, a partner or customer can enable additional security, such as:

• Encrypt IP phone services (via HTTPS) for services such as Extension Mobility

• Issue locally significant certificates (LSCs) from the certificate authority proxy function (CAPF) or a public certificate authority (CA)

• Encrypt configuration files

• Encrypt media and signaling

• Disable these settings if they are not used: PC port, PC Voice VLAN Access, Gratuitous ARP, Web Access, Settings button, SSH, console

Implementing security mechanisms in the Dedicated Instance prevents identity theft of the phones and the Unified CM server, data tampering, and call-signaling / media-stream tampering.

Dedicated Instance over the network:

• Establishes and maintains authenticated communication streams

• Digitally signs files before transferring the file to the phone

• Encrypts media streams and call signaling between Cisco Unified IP phones

Security by default provides the following automatic security features for Cisco Unified IP phones:

• Signing of the phone configuration files

• Support for phone configuration file encryption

• HTTPS with Tomcat and other Web services (MIDlets)

For Unified CM Release 8.0 later, these security features are provided by default without running the Certificate Trust List (CTL) client.

Because there are large number of phones in a network and IP phones have limited memory, Cisco Unified CM acts as a remote trust store through the Trust Verification Service (TVS) so that a certificate trust store does not have to be placed on each phone. The Cisco IP phones contact TVS server for verification because they cannot verify a signature or certificate through CTL or ITL files. Having a central trust store is easier to manage than having the trust store on each Cisco Unified IP phone.

TVS enables Cisco Unified IP phones to authenticate application servers, such as EM services, directory, and MIDlet, during HTTPS establishment.

The Initial Trust List (ITL) file is used for the initial security, so that the endpoints can trust Cisco Unified CM. ITL does not need any security features to be enabled explicitly. The ITL file is automatically created when the cluster is installed. The Unified CM Trivial File Transfer Protocol (TFTP) server’s private key is used to sign the ITL file.

When the Cisco Unified CM cluster or server is in non-secure mode, the ITL file is downloaded on every supported Cisco IP phone. A partner can view the contents of an ITL file using the CLI command, admin:show itl.

Cisco IP phones need the ITL file to perform the following tasks:

• Communicate securely to CAPF, a prerequisite to supporting the configuration file encryption

• Authenticate the configuration file signature

• Authenticate application servers, such as EM services, directory, and MIDlet during HTTPS establishment using TVS

Device, file, and signaling authentication rely on the creation of the Certificate Trust List (CTL) file, which is created when the partner or customer installs and configures the Cisco Certificate Trust List Client.

The CTL file contains entries for the following servers or security tokens:

• System Administrator Security Token (SAST)

• Cisco CallManager and Cisco TFTP services that are running on the same server

• Certificate Authority Proxy Function (CAPF)

• TFTP server(s)

• ASA firewall

The CTL file contains a server certificate, public key, serial number, signature, issuer name, subject name, server function, DNS name, and IP address for each server.

Phone security with CTL provides the following functions:

• Authentication of TFTP downloaded files (configuration, locale, ringlist, and so on) using a signing key

• Encryption of TFTP configuration files using a signing key

• Encrypted call signaling for IP phones

• Encrypted call audio (media) for IP phones

Dedicated Instance provides endpoint registration and call processing. The signaling between Cisco Unified CM and endpoints is based on Secure Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP) and can be encrypted using Transport Layer Security (TLS). The media from/to the endpoints is based on Real-time Transport Protocol (RTP) and can also be encrypted using Secure RTP (SRTP).

Enabling mixed mode on Unified CM enables encryption of the signaling and media traffic from and to the Cisco endpoints.

Secure UC applications

Mixed mode is enabled by default in Dedicated Instance.

Enabling mixed mode in Dedicated Instance enables the ability to perform encryption of the signaling and media traffic from and to the Cisco endpoints.

In Cisco Unified CM release 12.5(1), a new option to enable encryption of signaling and media based on SIP OAuth instead of mixed mode / CTL was added for Jabber and Webex clients. Therefore, in Unified CM release 12.5(1), SIP OAuth and SRTP can be used to enable encryption for signaling and media for Jabber or Webex clients. Enabling mixed mode continues to be required for Cisco IP phones and other Cisco endpoints at this time. There is a plan to add support for SIP OAuth in 7800/8800 endpoints in a future release.

Cisco Unity Connection connects to Unified CM through the TLS port. When the device security mode is non-secure, Cisco Unity Connection connects to Unified CM through the SCCP port.

To configure security for Unified CM voice-messaging ports and Cisco Unity devices that are running SCCP or Cisco Unity Connection devices that are running SCCP, a partner can choose a secure device security mode for the port. If you choose an authenticated voicemail port, a TLS connection opens, which authenticates the devices by using a mutual certificate exchange (each device accepts the certificate of the other device). If you choose an encrypted voicemail port, the system first authenticates the devices and then sends encrypted voice streams between the devices.

For more information on Security Voice messaging ports, refer to: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/12_5_1_SU1/cucm_b_security-guide-125SU1/cucm_b_security-guide-for-cisco-unified125SU1_chapter_010001.html

Securing communications between Cisco Unified CM and CUBE

For secure communications between Cisco Unified CM and CUBE, partners/customers need to use either self-signed certificate or CA-signed certificates.

For self-signed certificates:

1. CUBE and Cisco Unified CM generate self-signed certificates

2. CUBE exports certificate to Cisco Unified CM

3. Cisco Unified CM exports certificate to CUBE

For CA-signed certificates:

1. Client generates a key-pair and sends a Certificate Signing Request (CSR) to the Certificate Authority (CA)

2. The CA signs it with its private key, creating an Identity Certificate

3. Client installs the list of trusted CA Root and Intermediary Certificates and the Identity Certificate

Protocol summary

The following table shows the protocols and associated services used in the Unified CM solution.

For more information on MRA configuration, see: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X12-5/exwy_b_mra-expressway-deployment-guide/exwy_b_mra-expressway-deployment-guide_chapter_011.html

Securing Jabber and Webex with SIP OAuth

Jabber and Webex clients are authenticated through an OAuth token instead of a locally significant certificate (LSC), which doesn’t require certificate authority proxy function (CAPF) enablement (for MRA as well). SIP OAuth working with or without mixed mode was introduced in Cisco Unified CM 12.5(1), Jabber 12.5, and Expressway X12.5.

In Cisco Unified CM 12.5, we have a new option in Phone Security Profile that enables encryption without LSC/CAPF, using single Transport Layer Security (TLS) + OAuth token in SIP REGISTER. Expressway-C nodes use the Administrative XML Web Service (AXL) API to inform Cisco Unified CM of the SN/SAN in their certificate. Cisco Unified CM uses this information to validate the Exp-C cert when establishing a mutual TLS connection.

SIP OAuth enables media and signaling encryption without an endpoint certificate (LSC).

Cisco Jabber uses Ephemeral ports and secure ports 6971 and 6972 ports via HTTPS connection to the TFTP server to download the configuration files. Port 6970 is a non-secure port for download via HTTP.

More details about SIP OAuth configuration: SIP OAuth Mode.