Overview

1 Overview

This chapter provides an overview of Oracle Communications Order and Service Management (OSM) security.

Basic Security Considerations

The following principles are fundamental to using any application securely:

Keep software up to date. This includes the latest product release and any patches that apply to it.
Limit privileges as much as possible. Users should be given only the access necessary to perform their work. User privileges should be reviewed 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 (such as Transport Layer Security (TLS) and Secure Sockets Layer (SSL)), and secure passwords. See "Performing a Secure OSM Installation" for more information.
Learn about and use the OSM security features. See "Implementing OSM Security" for more information.
Use secure development practices. For example, take advantage of existing database security functionality instead of creating your own application security. See "Security Considerations for Developers" 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

Overview of OSM Security

OSM security is designed to protect application users, modules, solution data, order data, logs, and interfaces.

OSM application security: Users of the application are authenticated using the Oracle WebLogic Server authentication framework.
OSM solution data security: Solution data, such as deployed cartridges, is stored in the Oracle Database, which requires database credentials to access.
OSM order data security: Application access to solution and order data is authorized and validated by the OSM role-based authorization model. Order data is stored in the Oracle Database, which requires database credentials to access.
OSM interface security: Users of the application are authorized at the interface level (for example, web client, web service, or deployment) using the WebLogic Server security roles. Interfaces security is further configured using interface-specific means; the OSM Web Service is secured by a WebLogic Server security policy, for example. Credentials for accessing external systems are stored securely.
Application log security: Application log content is configured by users of the WebLogic Server Administrators group. The application distribution, settings and properties, and logs are protected by the user authorization and authentication procedures of the host operating system. Only the user who starts OSM has access to the files, based on file permissions.

Note:

The OSM server should be installed on a Windows-based computer only for development, demonstration, and (non-performance) test systems. Do not use a Windows-based system for production or performance test systems.
Database security: The OSM database credentials are stored securely inside the Java Database Connectivity (JDBC) data source in the WebLogic server.

Understanding the OSM Environment

When planning your OSM implementation, consider the following:

Which resources need to be protected?
- You need to protect customer data.
- You need to protect internal data.
- You need to 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 your subscribers' 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, it is possible that a system administrator can manage your system components without needing to access the system data.
What will happen if protections on strategic resources fail?

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 will help you protect it properly.

Recommended Deployment Topologies

This section describes recommended deployment configurations for OSM.

Figure 1-1 shows a single-computer installation topology: the simplest OSM deployment architecture.

Figure 1-1 Single-Server Deployment Topology

Description of "Figure 1-1 Single-Server Deployment Topology"

In this topology, all the application components and data are kept on a single server, protected from external attacks by a firewall. The firewall can be configured to block known illegal traffic types. There are fewer resources to secure because all the components are on a single server and all of the communication is local. Fewer ports have to be opened through the firewall.

Conversely, there are fewer points of attack, and if security is compromised, an attacker would have access to the entire system and data.

A single-server installation topology is best suited for test and lab environments.

A single-server deployment is cost effective for small organizations but does not provide high availability because all components are stored on a single server.

Figure 1-2 shows a tiered installation deployment: a scalable OSM deployment offering greater security and high availability.

Figure 1-2 Tiered Deployment Topology

Description of "Figure 1-2 Tiered Deployment Topology"

In this topology, the application tier is isolated by firewalls from both the Internet and the intranet. The database and servers are protected from potential attacks by two layers of firewall. Both firewalls can be configured to block known illegal traffic types. The two layers of firewall also provide intrusion containment. Although there are more components to secure, and more ports must be opened to allow secure communication between the tiers, the attack surface is spread out.

Operating System Security

This section describes operating system security topics that are specific to OSM. See the documentation for your operating system for general information.

Operating System Releases and Patch Levels

For information about the supported operating system releases and patch levels, see the system requirements in OSM Installation Guide. OSM depends on Oracle Database and WebLogic Server. For all operating systems, check the Oracle Database and WebLogic Server documentation for any additional operating system patches required to support those applications.

Restricting Permissions for OSM Directories

Oracle recommends keeping the permissions as restrictive as possible for your business needs. When installing on UNIX or Linux, consider using umask 066 to deny read and write permission to all users except the user that installed the software. OSM creates files in the directories listed in Table 1-1. Examine these directories to ensure they have the appropriate permissions.

Table 1-1 OSM Directories

Name	Description
OSM home	The directory in which you installed OSM and all its subdirectories may be modified by OSM. This directory contains the SDK (if installed), utility (if installed), and product cartridge directories, as well as various installation-related files.
Domain home	The directory containing the WebLogic Server domain for OSM. The default location is Fusion_Middleware_installation_directory/user_projects/domains/domain_name, but it is frequently set to something else during installation.
VFS home	The directory in which OSM stores various solution files. The default location is /tmp/vfs_cache. If it is not using the default location, you will see the location in the value of the -Djava.io.tmpdir=new_path argument to the OSM WebLogic Server startup scripts (where new_path is the parent directory of vfs_cache).

Port Security

OSM communicates over a limited number of ports. Depending on your solution requirements, additional ports may be required, especially if OSM is deployed to a WebLogic Server cluster.

Close all unused ports, especially non-SSL ports. Opt for SSL-enabled ports for all communications (for example: HTTPS or t3s) when possible.

The types of ports OSM uses are listed in Table 1-2.

Table 1-2 OSM Ports

Port	Port Description
Listen port for the administration server	The default value is 7001, but a different value can be set during domain creation.
SSL listen port for the administration server	The default value is 7002, but a different value can be set during domain creation.
WebLogic Server administration port (SSL-only)	The default value is 9001 if the administration port is enabled. By default, this port is disabled, but Oracle recommends enabling the port.
Coherence cluster port	The default value is 17001, but a different value can be set during OSM installation.
Database listener port	The default is 1521, but a different value can be set during database creation.

Oracle Database Security

This section describes database security topics specific to OSM. For more information about securing Oracle Database, see Oracle Database Security Guide and Oracle Database Advanced Security Guide. Some OSM database changes in this section must be made by an Oracle database administrator (DBA).

Oracle Database Administrator Roles and Permissions

The following roles and permissions are required for the account used by the DBA:

Required permissions
- Connect to a resource with admin option
- Execute on dbms_lock with grant option
- Execute on dbms_redefinition with grant option
- Select on dba_jobs with grant option
- Execute on exp_full_database and imp_full_database with admin option
- Create table with admin option
- Create materialized view with admin option
- Query rewrite with admin option
- Select on v_$parameter with grant option
Required roles
- sysdba role

Transparent Data Encryption

You can encrypt the OSM tablespace and schema, at the expense of system performance, using Oracle Database Transparent Data Encryption (TDE). Encrypting the schema and tablespace enforces data-at-rest encryption in the database layer and therefore prevents would-be attackers from bypassing the database and reading sensitive information from storage.

If you choose to encrypt the tablespace and schema, you must configure TDE on the tablespace before creating the OSM schema. See Oracle Database Advanced Security Guide for more information.

Dependent Schemas

Before creating the WebLogic Server domain, you must create certain database schemas using the Oracle Fusion Middleware Repository Creation Utility (RCU). For information about RCU, see Oracle Fusion Middleware Creating Schemas with the Repository Creation Utility. For information about the RCU schemas required for creating an OSM WebLogic Server domain, see the information about installing and configuring WebLogic Server in OSM Installation Guide.

WebLogic Server Security

This section contains WebLogic Server security information relevant to OSM. For additional information about WebLogic Server security, see Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server and Oracle Fusion Middleware Administering Security for Oracle WebLogic Server.

When planning your WebLogic Server domain installation, keep the following recommendations in mind:

Secure the WebLogic Server host: WebLogic Server domain and server configuration files should be accessible only by the operating system users who configure or run WebLogic Server. No other operating system user (apart from the system administrators) should have read, write, or execute access to WebLogic Server product files or your domain files.
Set file access permissions for data stored in the persistent store: Set operating system file access permissions to restrict access to data stored in the persistent store. When using the synchronous write policy of Direct-Write-With-Cache, limit access to the cache directory, especially if there are customized user access limitations on the primary directory. For more information about the WebLogic Server services and subsystems that can create connections to the persistent store, see the information about using the persistent store in Administering Server Environments for Oracle WebLogic Server. The default persistent store maintains its data in the domain_home/servers/server_name/data/store/default directory, where domain_home is the home directory for the OSM domain, and server_name is the name of the relevant WebLogic server.
Do not run WebLogic Server in development mode in a production environment: Production mode sets the server to run with settings that are more secure and appropriate for a production environment. For more information about development mode and production mode, see the information about domain modes in Understanding Domain Configuration for Oracle WebLogic Server.
Use appropriate encryption: WebLogic Server includes a set of demonstration private keys, digital certificates, and trusted certificate authorities that are for development only; do not use the demonstration identity and trust in a production environment. See the topic on configuring keystores in the Oracle WebLogic Server Administration Console Online Help and the information about configuring SSL in Administering Security for Oracle WebLogic Server for more information about encryption.

To prevent sensitive data from being compromised, secure data transfers by using HTTPS.