This chapter describes the Oracle Communications Evolved Communications Application Server (OCECAS) security features.
The following principles are fundamental to using any application securely:
Keep software up to date. This step includes the latest product release and any patches that apply to it.
Limit privileges as much as possible. Only give user accounts the access necessary to perform their work. Review user privileges periodically to determine relevance to current work requirements.
Monitor system activity. Establish who should access which system components, and how often, and monitor those components.
Install software securely. For example, use firewalls, secure protocols using TLS (SSL) and secure passwords.
Learn about and use the OCECAS security. See "Implementing OCECAS Security" for more information.
Keep up to date on security information. Oracle regularly issues security-related patch updates and security alerts. You must install all security patches as soon as possible. See the ”Critical Patch Updates and Security Alerts” website:
http://www.oracle.com/technetwork/topics/security/alerts-086861.html
OCECAS relies on, and benefits from the security features of the underlying WebLogic Server platform, including security realms, security monitoring features, and so on.
This guide describes the OCECAS security features. For WebLogic Server information, including information about implementing application security, see the Oracle WebLogic Server 12c documentation.
OCECAS includes these components that you install separately. Each has its own security considerations:
Session Design Center runs in the OCECAS management environment. You use it to create and deploy the VoLTE multimedia services that your subscribers use. Session design Center requires the WebLogic server and an Oracle database, and it has these security considerations:
The WebLogic server may use a local security realm, or integrate with an external security provider such as LDAP or Oracle Identity Manager. Configure the WebLogic server running the management application securely.
Make sure the WebLogic Administration is only accessible to administrators; do not give any other user accounts access to it. On production environments, shut down the Administration Console when not in use.
The Oracle Database must be secured to allow access by OCECAS only. Ensure that administrators are the only user accounts with access to it.
Secure the interfaces provided to other servers, such as REST, JDBC, and Messaging.
Event Data Records (EDRs) are collated on the Session Design Center server from the management environment and the UDR server. Restrict access to the EDRs to protect privacy.
The session control features provide SIP Application Server functionality to operators. The session control features are based on WebLogic Server. Your deployment may also require a NoSQL database.
Ensure that OCECAS is only accessible by administrators. Make sure that no other user accounts have access to it. Once you configure a production environment, shut down the Administration Console.
Secure WebLogic server components that provide connections to the management server.
Whenever possible, secure communication channels between OCECAS and the IMS, HSS, OCF, and other network nodes using transport layer security (TLS).
A UDR provides a repository for subscriber data, and can be installed on separate physical hardware, or on the same hardware as the OCECAS environments.
Configure the server running the UDR application for secure access.
Ensure that the administration console is only accessible to administrators, and shut it down on production environments.
When planning your OCECAS implementation, consider the following:
Which resources need to be protected?
Protect customer data, such as IP addresses.
Protect internal data, such as EDRs.
Protect system components from being disabled by external attacks or intentional system overloads.
Who are you protecting data from?
For example, you need to protect subscriber data from other subscribers, but someone in your organization might need to access that data to manage it. You can analyze your workflows to determine who needs access to the data. For example, a system administrator may be able to manage your system components without needing to access the system data.
What happens if protections on a strategic resource fails?
In some cases, a fault in your security scheme is nothing more than an inconvenience. In other cases, a fault might cause great damage to you or your customers. Understanding the security ramifications of each resource helps you protect it properly.