1 ASAP Security Overview

This chapter provides an overview of Oracle Communications ASAP 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, how often they should be accessed, and who should monitor those components.

  • Install software securely. For example, use firewalls, secure protocols (such as TLS), and secure passwords. See "Performing a Secure ASAP Installation" for more information.

  • Learn about and use ASAP security features. See "Implementing ASAP 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 "Critical Patch Updates and Security Alerts" on the Oracle Web site:

    http://www.oracle.com/technetwork/topics/security/alerts-086861.html

Understanding the ASAP Environment

When planning your ASAP implementation, consider the following:

  • Which resources must be protected? For example:

    • You must protect customer data.

    • You must protect internal data, such as proprietary source code.

    • You must protect system components from being disabled by external attacks or intentional system overloads.

  • Who are you protecting data from?

    For example, if your business has service subscribers, you must protect their data from other subscribers, but someone in your organization might have 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 could manage your system components without needing to access the system data.

  • What happens 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 helps you protect it properly

Overview of ASAP Security

Figure 1-1 shows all the various components that can comprise ASAP, including the components to which it connects.

Figure 1-1 ASAP Components

ASAP component diagram.

ASAP security is designed for three essential functions: managing ASAP WebLogic-based users, securing data, and protecting diagnostics files. ASAP provides these security functions in the following locations:

  • ASAP WebLogic server security: An ASAP WebLogic server instance contains default users, groups, and roles that support the various WebLogic-based ASAP functionality, like the order control application (OCA) client, the Service activation configuration tool (SACT), the service activation deployment tool (SADT) and the Java service request processor (JSRP).

  • ASAP server and database credential security: The ASAP environment contains a credential store factory (CSF) wallet that stores the ASAP schema user names and passwords, and the ASAP WebLogic server user name and password. These credentials are called class A secure data. Each ASAP server can use this wallet to obtain these credentials. The CSF wallet provides both secure storage and encryption for these credentials.

  • Network Element (NE) credential security for Network Element Processor (NEP) to NE communication: The ASAP Control database stores credentials required for NEPs to access NEs. These credentials are called class B secure data. You can use the ASAP security tool to add, change, or delete credential information, and also to enable encryption.

  • ASAP system configuration parameters: Some ASAP system configuration parameters can have a significant impact on security. Parameters settings, such as diagnostic levels and server security attributes should be configured to ensure data security.

Recommended Deployment Topologies

This section describes recommended deployment topologies for ASAP.

Single-Computer Installation Topology

Figure 1-2 shows a single-computer installation topology.

Figure 1-2 Single-Computer Deployment

Description of Figure 1-2 follows
Description of "Figure 1-2 Single-Computer Deployment"

In this topology, all the application components and data are kept on a single system, 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 system and all 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-computer installation topology is best suited for test and lab environments:

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

Tiered Deployment

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

Figure 1-3 Tiered Deployment

Description of Figure 1-3 follows
Description of "Figure 1-3 Tiered Deployment"

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 provide intrusion containment. Although there are a greater number of components to secure, and more ports have to be opened to allow secure communication between the tiers, the attack surface is spread out.

ASAP Port Requirements

Table 1-1 lists and describes ASAP ports.

Table 1-1 ASAP Ports

Port Description

SARM server

The SARM server port for sending and receiving.

Control server

The Control server port for sending and receiving.

NEP server

JNEP listener

The NEP server port for sending and receiving.

The JNEP listener port for sending and receiving.

Admin server

The Admin server port for sending and receiving.

Daemon server

The Daemon server port for sending and receiving.

OCA server

The OCA server port for sending and receiving.

JSRP sending WO

JSRP receiving WO

The JSRP port for sending work orders.

The JSRP port for receiving work orders.

Database connection

The port in the Oracle database connection string. There may be multiple ports if an Oracle Real Application Clusters (RAC) database is used.

WebLogic connection

The port for the ASAP WebLogic server and optional managed server. In addition, if the ASAP WebLogic server is installed on a different machine, you must also open the ports to the Oracle database from there.

Telnet for remote servers

If ASAP is deployed on multiple servers in a distributed configuration, the telnet port for rsh connectivity must be open.

Operating System Security

See the following documents:

  • Guide to the Secure Configuration of Red Hat Enterprise Linux 6

  • Hardening Tips for the Red Hat Enterprise Linux 6

Oracle Database Security

For more information about securing an Oracle Database, see Oracle Database Security Guide and Oracle Database Advanced Security Administrator's Guide.

WebLogic Server Security

For information about securing an ASAP WebLogic server, see Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server.

LDAP Security

Oracle recommends that you use Oracle Internet Directory for identity management (for example, users, roles, certificates). You can also use an external LDAP, which you must integrate with ASAP through the ASAP WebLogic server.

For information about setting up Oracle Internet Directory, see Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

For information about setting up an external LDAP, see the LDAP application documentation. For information about security realms and setting up ASAP with an external LDAP, see ASAP System Administrator's Guide.

Oracle Security Documentation

ASAP uses other Oracle products, such as Oracle Database and Oracle WebLogic server. See the following documents, as they apply to ASAP:

  • Oracle Database Security Guide

  • Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server

  • Oracle Fusion Middleware Securing Resources Using Roles and Policies for Oracle WebLogic Server

  • Oracle Application Server Security Guide

  • Oracle Application Server Administrator's Guide