|Oracle® Communications Network Integrity Security Guide
|PDF · Mobi · ePub|
This chapter provides an overview of Oracle Communications Network Integrity security.
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 SSL), and secure passwords. See "Performing a Secure Network Integrity Installation" for more information.
Learn about and use Network Integrity security features. See "Implementing Network Integrity 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:
When planning your Network Integrity 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
Figure 1-1 shows all the various components that can comprise Network Integrity, including the components to which it connects. Each installed or integrated component requires special steps and configurations to ensure system security.
Figure 1-2 shows a single-computer installation topology: the simplest Network Integrity deployment architecture.
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.
Figure 1-3 shows a tiered installation deployment: a scalable Network Integrity deployment offering greater security and high availability.
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.
This section lists Network Integrity-specific OS security configurations. This section applies to all supported OSs.
Network Integrity communicates through the firewall with various components on specific ports. Ensure that the OS IPtables for the firewalls are configured to manage traffic on the following ports:
Port 22 (optional, both directions): Used by the File Transfer and Parsing cartridge for SSH communication. Close this port if you are not using the File Transfer and Parsing cartridge.
WebLogic Server SSL listen ports (both directions): Used by Administration and Managed servers for listening for traffic.
CORBA Name Server port or SSL port (optional, both directions): Used by the CORBA cartridge and Optical TMF814 CORBA cartridge to retrieve device data from element and network management systems. Close this port if you are not using the CORBA and Optical TMF814 CORBA cartridges.
Port 992 (optional, both directions): Used by the TL1 cartridge for SSH communication. Close this port if you are not using the TL1 cartridge.
SNMP port (optional, both directions): Used for scanning SNMP devices. By default, the SNMP port is port 161. Close this port if you are not using an SNMP cartridge.
Oracle Database listener ports: Used by the Oracle Database for listening for traffic.
Close all unused ports, especially non-SSL ports. Opt for SSL-enabled ports, instead of non-SSL ports, for all communications (for example: HTTPS, IIOPS, t3s).
For more information about securing your OS, see your OS documentation.
This section lists the Network Integrity-specific security configurations for the Oracle Database:
For more information about securing Oracle Database, see Oracle Database Security Guide and Oracle Database Advanced Security Administrator's Guide.
Network Integrity encrypts sensitive information and stores the encrypted data in the database. The Network Integrity encryption mechanism uses the advanced encryption standard (AES) algorithm.
The following data is encrypted:
All data written to the database
It is also possible (but not recommended) to encrypt the Network Integrity tablespace and schema, at the expense of system performance. Encrypting the schema and tablespace is not necessary, because the database is sufficiently secure without the encryption.
If you must encrypt the tablespace and schema, use Oracle Database Transparent Data Encryption (TDE), because it supports AES.
You must configure TDE on the tablespace before creating the Network Integrity schema. See Oracle Database Advanced Security Administrator's Guide for more information.
Encrypting network data is a critical security measure that ensures that data travelling over the network is difficult to intercept and access.
Secure network connections to the Oracle Database using the Oracle Advanced Security feature. You can configure the Oracle Database with either Network Data Encryption and SSL authentication, as both ensure that the data is secure while travelling over the network.
The Oracle Advanced Security feature also provides security against the following types of attacks:
Data modification attack, where an unauthorized party intercepts data in transit over the network, alters it, and transmits the altered data to the database.
Replay attack, where an unauthorized party repeatedly transmits entire sets of valid data.
Use the Oracle Advanced Security feature to enable SSL authentication, using a digital certificate, on data that travels over the network to the database. See Oracle Database Advanced Security Administrator's Guide for more information.
Using SSL authentication allows Network Integrity to communicate with servers over an encrypted connection and to communicate with the database over an encrypted connection.
SSL authentication supports the following authentication modes:
Only the server authenticates itself to the client.
Both client and server authenticate themselves to each other.
Neither the client nor the server authenticate with each other (SSL encryption feature by itself).
For information about securing WebLogic Server, see Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server.
Authorization is the process where the interactions between users and WebLogic Server resources are controlled, based on user identity or other information. In WebLogic Server, an Authorization provider is used to limit the interactions between users and WebLogic resources to ensure integrity, confidentiality, and availability.
For more information about changing WebLogic Server passwords, see Network Integrity System Administrator's Guide.
A WebLogic Server resource is a structured object used to represent an underlying WebLogic Server entity, which can be protected from unauthorized access using security roles and security policies.
WebLogic resources are hierarchical. Therefore, the level at which you define these security roles and security policies is up to you. For example, you can define security roles and security policies on entire enterprise applications; an Enterprise Java Bean JAR containing multiple EJBs; a particular Enterprise Java Bean (EJB) within that JAR; or a single method within that EJB.
Security policies replace access control lists and answer the question “Who has access to a WebLogic server resource?” A security policy is created when you define an association between a WebLogic resource and one or more users, groups, or security roles. You can optionally define date and time constraints for a security policy. A WebLogic resource has no protection until you assign it a security policy.
Security policies are stored in an authorization provider's database. By default, the XACML Authorization provider is configured in a domain, and security policies are stored in the embedded LDAP server.
To use a user or group to create a security policy, the user or group must be defined in the security provider database for the authentication provider that is configured in the default security realm. To use a security role to create a security policy, the security role must be defined in the security provider database for the Role Mapping provider that is configured in the default security realm. By default, the authentication and XACML Role Mapping providers are configured in the database in the embedded LDAP server. Also by default, security policies are defined in WebLogic Server resources. These security policies are based on security roles and default global groups. You also have the option of basing a security policy on a user.
SSL enables secure communication between applications connected through the Web. WebLogic Server fully supports SSL communication. By default, WebLogic Server is configured for one-way SSL authentication. Using the Administration Console, you can configure WebLogic Server for two-way SSL authentication.
To use one-way SSL from a client to a server, enable the SSL port on the server, configure identity for the server and trust for the client.
To use two-way SSL between a client and a server, enable two-way SSL on the server, configure trust for the server, and identity for the server.
In either case, the trusted CA certificates must include the trusted CA certificate that issued the peer's identity certificate. This certificate does not necessarily have to be the root CA certificate.
To acquire a digital certificate for your server, generate a public key, private key, and a Certificate Signature Request (CSR), which contains your public key. Send the CSR request to a certificate authority and follow their procedures for obtaining a signed digital certificate.
After you have your private keys, digital certificates, and any additional trusted CA certificates that you may need, you must store them so that WebLogic Server can use them to verify identity. Store private keys and certificates in keystores.
For more information on security fundamentals, see the Oracle Fusion Middleware documentation:
Caution:Network Integrity uses HTTPS to connect to the UI, by default. You must enable both SSL and TLS for your browser to connect to the Network Integrity UI.
Network Integrity uses a demonstration CA certificate provided by the WebLogic Server. As a result, when you connect to the Network Integrity UI for the first time, the browser displays a warning page with a message indicating that the security certificate presented is not issued by a trusted certificate authority.
This is expected behavior. Accept this untrusted certificate and continue to connect to the Network Integrity UI.
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 Network Integrity through the WebLogic Application 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 Network Integrity with the external LDAP, see Network Integrity System Administrator's Guide.
Oracle recommends that you not use FINE or lower logging levels for Network Integrity. By default, WebLogic Server uses a higher log level for Network Integrity. An explicit administrative action is required to change the log level. See Network Integrity System Administrator's Guide for more information.
When the log levels are set to FINE or lower, the log levels can contain raw exceptions and stack traces that could be exploited to compromise the security of your Network Integrity system.
Network Integrity uses other Oracle products, such as Oracle Database and Oracle WebLogic Server. See the following documents, as they apply to Network Integrity:
Oracle Database Security Guide
Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server
Oracle Application Server Security Guide
Oracle Application Server Administrator's Guide