1. Installation and Maintenance Guide
  2. Security Shield Deployment Overview

2 Security Shield Deployment Overview

The Oracle Communications Security Shield (Security Shield) consists of several components that interact with one other to provide the service. Major components include the Oracle Communications Session Border Controller (OCSBC), (Security Shield) services, and the Cloud Communication Service (CCS). The Security Shield service resides in the Oracle Cloud, while the OCSBC and the CCS reside on premises. You must download and install the CCS software and Security Shield SPL plug-in, as well as configure the OCSBC for Security Shield operations. See the Security Shield User's Guide to learn about the components and their respective operations.

Topics:

Version Requirements for External Components

If you use any of the following components that are external to the Oracle Cloud, the Oracle® Communications Security Shield Cloud Service (Security Shield) requires the following versions at the minimum.

Data Collection and Enforcement Points

Session Border Controller
  • Use Oracle Communications Session Border Controller release S-Cz8.4.0 p10 or higher.

    Note:

    If you require performance higher than 50 calls per second, Oracle recommends that you use version S-Cz9.0 or higher with the latest patch.
  • SPL package—Customers currently using Security Shield must upgrade their Session Border Controllers to the latest released SPL, but only after upgrading their tenant to the latest Security Shield release. Get the latest version available for download from Oracle Software Delivery Cloud or My Oracle Support. Install the SPL on the external-facing realm.
  • SPL Engine—C3.1.14 or higher
  • Virtualization—Run as a Virtual Network Function (VNF).
  • See the Oracle Communications Session Border Controller Platform and Installation Guide for information about platform support.
Session Router
  • Use S-Cz 9.0.0 or higher.
  • 4 vCPU cores, 32 GB RAM-Hardware, 8GB RAM-Virtual Machines, 20GB HDD, and 8 vNICs
  • Install the Security Shield SPL on the external facing realm.
  • Session Router runs in the session stateful configuration mode, only. Security Shield does not support other configurations and modes.
  • SPL Engine—C3.1.14 or higher
  • Virtualization—Run as a Virtual Network Function (VNF).
  • See the Oracle Session Border Controller ACLI Configuration Guide, Oracle Communications Session Router, and Session Router Data Sheet documentation.

Service Authentication and Connectivity

Oracle Cloud Communication Service
  • CCS—Use the latest version available for download from Oracle Software Delivery Cloud or My Oracle Support.
  • Hardware—Oracle X8-2 or equivalent
  • CPUs—1
  • Memory—250MB
  • Disk—100MB
  • Throughput—1GBps NIC capacity
  • Docker—Use version 18.09.1 or higher with the daemon running as a service
  • Oracle Linux—Use version 7.6 or higher, or equivalent with compatible Red Hat Compatible Kernel (same version).
Podman
  • Version 4.4.1 or higher

Browser Support

Oracle recommends that you use the latest versions of Google Chrome, Mozilla Firefox, and Microsoft Edge as of the date of this release, for the best user experience.

Oracle does not support Internet Explorer 11.

Note:

After upgrading the software, clear the browser cache before using the Web GUI.

Cloud Communications Service Deployment, Management, and Work Flow

When you deploy the Cloud Communications Service (CCS), you must run the supplied scripts to install, configure, activate, deactivate, and uninstall the service. Oracle provides a unique set of scripts for CCS, and packs them all in the archive.tgz file that you download from either Oracle Software Delivery Cloud or My Oracle Support. The download creates the following directory tree on the host.

Directory tree: 

./ccs-<version>.<build>/install.pl
./ccs-<version>.<build>/ccs
./ccs-<version>.<build>/ccs/.build (hidden)
./ccs-<version>.<build>/ccs/.version (hidden)
./ccs-<version>.<build>/ccs/api
./ccs-<version>.<build>/ccs/api/KeyRsp.v1.json
./ccs-<version>.<build>/ccs/api/RegReq.v1.json
./ccs-<version>.<build>/ccs/api/RegRspv1.json
./ccs-<version>.<build>/ccs/api/TokenRsp.v1.json
./ccs-<version>.<build>/ccs/cfg
./ccs-<version>.<build>/ccs/cfg.v1.json
./ccs-<version>.<build>/ccs/img
./ccs-<version>.<build>/ccs/img/ccs-<version>.<build>.tar
./ccs-<version>.<build>/ccs/log
./ccs-<version>.<build>/ccs/perl
./ccs-<version>.<build>/ccs/perl/activate.pl
./ccs-<version>.<build>/ccs/perl/config.pl
./ccs-<version>.<build>/ccs/perl/deactivate.pl
./ccs-<version>.<build>/ccs/perl/uninstall.pl
./ccs-<version>.<build>/ccs/ssl
./ccs-<version>.<build>/ccs/ssl/ca
./ccs-<version>.<build>/ccs/ssl/ca/c_rehash
./ccs-<version>.<build>/ccs/ssl/ca/DigiCertGlobalRootCA.cer
./ccs-<version>.<build>/ccs/ssl/ca/DigiCertSHA256GlobalCaG2.cer
./ccs-<version>.<build>/ccs/ssl/ca/DigiCertSHA256GlobalRootG2.cer
./ccs-<version>.<build>/ccs/ssl/ca/DigiCertSHA2SecureServerCA.cer
The initial installation process for the CCS includes running the scripts in the following order:
  1. Install
  2. Configure
  3. Activate
After the initial installation you can use the various scripts to manage the CCS, as follows:
  • Reconfigure and reactivate the installed version of the CCS, for example, if you want to change the host, configuration, or certificates.
  • Deactivate and reactivate the existing configuration.
  • Uninstall the CCS.
  • Upgrade and downgrade the CCS version.
The following illustration shows the possible work flows for running the scripts:

This illustration shows the possible work flows for installing and managing the CCS and the PDE. It shows the initial flow of Install, Config, and Activate, after which you can deactivate or uninstall. It shows that after deactivating, you can go back to configure and then re-activate. You can also deactivate and then activate without re-configuring.

For instructions for running the scripts, see the Security Shield Installation and Maintenance Guide.

CCS Configuration Behind NAT or a Firewall

Oracle recommends that you configure the Cloud Communication Service (CCS) to operate behind Network Address Translation (NAT) or a firewall.

This illustration shows the recommended placement of the Cloud Communication Service in your network between the Session Border Controller and your Network Address Translation or Firewall..

Oracle designed the Oracle® Communications Security Shield Cloud Service (Security Shield) to contact the CCS using the value for the "Server-FQDN" configuration field in the CCS. The CCS supplies the "Server-FQDN" value when it registers with Security Shield. For example: 

“Server-FQDN” : “ccs.useast.example.com”

You can set the "Server-FQDN" value as an FQDN or a static IP address that maps to the public interface of the NAT or firewall. Security Shield always uses port 443 for these connections, which requires any device placed between the CCS and Security Shield to dedicate port 443 to the CCS for all possible IP addresses resolved for the FQDN.

Security Shield Phone Number Format Requirements

Oracle® Communications Security Shield Cloud Service (Security Shield) requires the following conventions for phone numbers for inbound and outbound calls.

Note:

If your Session Border Controller does not use phone numbers in the E.164 format, Oracle may need to work with you before deploying Security Shield to determine how to normalize your phone numbers to work effectively with Security Shield.
  • Phone Number Format
    The general number format convention is country code followed by the subscriber phone number <country code><subscriber phone number>. The subscriber phone number may include an area code and is typically seven to eleven digits long, depending on the national number conventions. Enter Phone numbers in the following ten-digit format where N is any digit from 2-9 (first digit of the area code and the local exchange) and X is any digit from 0-9: NXX-NXX-XXXX .

    Note:

    The preceding example contains hyphens only to aid in understanding. Do not insert hyphens when entering the number in the "Number" field in the "Add Outbound Number" configuration.
  • Country Code
    The country code can be up to three digits long. For international formatting, you may format the number with a + character (+<country code><subscriber phone number>, for example, +15551234567) or without the + character. For outbound calls to international destinations you can use either the + character or the international dialing prefix for your country. Check with your SIP trunk provider for the number format convention it supports. When formatting phone numbers for the Trusted Enterprise Calls subscription, which is valid only in North America, use one of the following methods to add the country code.
    • Manual—Add the +1 or 1 prefix to the number, for example +1NXXNXXXXXX or 1NXXNXXXXXX.
    • Default to the United States and Canada—Skip adding +1 or 1 to the number. Go to the Settings page and click Autonomous Threat Protection. Select "United States and Canada" for the "Service Domain Home Country." Security Shield will consider all phone numbers without a country code as "United States and Canada."
  • You can use wild cards at the end of the phone number to indicate a range, except for Trusted Enterprise Calls. For example: To specify a seven digit phone number that begins with 91920, enter 91920xx.
  • If you choose to configure the Presentation Number, you must use only the number format convention supported by the SIP trunk provider. When you use multiple SIP trunk providers, you must use a Presentation Number format that each SIP Trunk provider can support. For example, in the United States you use [country code][area code][local phone number] or the more commonly used [area code][local phone number]. In the European Union and United Kingdom you use [+][country code][area code][local phone number].

Number Cleansing

Use the following information to help you prepare phone numbers for Security Shield processing.
  • Try to map to a country code to set the country.
  • Remove any leading zeros from the phone number without the country code that may occur from configuration issues with trunk code or international dialing prefixes that are not removed.
  • Map the next digits (prefix after the country code, after removing any leading zeros) to a carrier.
  • Determine if the number length matches with the number plan (length for the prefix range.

When you receive calling number information (SIP INVITE, FROM, or PAI fields) containing a short phone number, incorrect format, or alphanumeric text such as "Restricted or "Anonymous", the reputation score may by negatively affected and can cause false positives for Reputation Score (High risk categories) and Threat Detection (Call Type). Oracle recommends that you use Security Shield Number Normalization, Non-Conforming E.641 Numbers guidelines, and Access Control Lists to avoid processing numbers with incorrect formats or alphanumeric text.

Session Router Support for Security Shield

The Oracle® Communications Security Shield Cloud Service (Security Shield) supports the Oracle Communications Session Router. The Session Router works in environments that use Oracle Session Border Controllers to integrate with Security Shield as well as environments that do not use Oracle Communications Session Border Controllers to integrate with Security Shield.

The Oracle Communications Session Router (OCSR) resides in the signaling core and directs traffic to and from other SIP signaling elements in the network, including Call Session Control Function servers.

Requirements

  • Use S-Cz9.0.0 or higher.
  • Install the Security Shield SPL on the external facing realm.
  • Session Router runs in the session stateful configuration mode, only. Security Shield does not support other configurations and modes.

Deployment Considerations

Oracle supports the following models for deploying the Session Router.
  • You can deploy the Session Router between the existing border element and SIP Trunk. You must enable the Security Shield SPL Plug-in on the external facing realm, which may require you to reconfigure the SIP Trunk end-point.
  • You can deploy the Session Router inside the enterprise network. You must use two distinct realms on the Session Router if you send both inbound and outbound traffic from the same border element. You must configure Security Shield on the realm that will receive traffic from the SIP Trunk. The other realm must receive traffic from inside the Enterprise network. On the Session Router, traffic is routed between these two realms.