3 General Security Guidelines

Learn about general security guidelines.

3.1 Installing Oracle Audit Vault and Database Firewall Securely to Protect Your Data

Learn how to securely install Oracle AVDF to protect your data.

3.1.1 Installing Oracle Audit Vault and Database Firewall Securely

Learn to securely install Oracle Audit Vault and Database Firewall.

Oracle Audit Vault Server installs in a secure state by default. Therefore, it is important to be careful if you change any of the default settings because your changes may compromise the security of your setup.

See Also:

Oracle Audit Vault and Database Firewall Installation Guide for details of the installation.

3.1.2 Protecting Your Data

Consider account naming, password use, and other guidelines to better enable Oracle AVDF to protect your data.

Consider following these guidelines to protect your data:

  • Account Names and Passwords: Use secure passwords for the Oracle Audit Vault Server console UI, as well as for the root, support, and sys accounts and keep these passwords safe.

  • Administrator Accounts: Do not share Oracle Audit Vault and Database Firewall Administrator accounts.

  • Strong Password Policies: Create password policies to force users to use strong passwords.

  • Installed Accounts: Oracle Audit Vault and Database Firewall embeds operating system and database accounts. Do not add new accounts of this type. Do not unlock the existing accounts. Doing so may compromise the security of the Oracle Audit Vault and Database Firewall system.

  • Secure Archiving:Oracle Audit Vault and Database Firewall sends archive data over the network. Secure both the archive destination and intermediate network infrastructure.

  • Remote Access: The Settings tab of the services page of Oracle Audit Vault Server console controls access to:
    • web console
    • shell (ssh)
    • SNMP

    Follow these guidelines when granting remote access:

    • Grant access only if you need it for a specific task and then revoke access when that task is completed.

    • Restrict access by IP address. Do this immediately after installing the system.

    • Grant terminal (shell) access only when doing a patch update or when requested to do so by the documentation or by Oracle support.

3.2 General Security Recommendations

Learn about the general security recommendations for Oracle AVDF.

Oracle security recommendations:

  • If you are using the Database Firewall to block unwanted traffic, then ensure that all data flowing from the database clients to the database and back passes through the Oracle Database Firewall. This includes both requests and responses.

  • Use the appropriate security measures for your site to control access to the computer that contains Oracle Audit Vault Server and Database Firewall. Give access only to specific users.

  • Ensure that passwords conform to best practice.

  • Separate the duties of administrators and auditors by assigning these roles to different people.

  • Assign Oracle Audit Vault Server user the appropriate administrator, super administrator, auditor, and super auditor roles.

  • By default, the following accounts that are related to Oracle AVDF are locked: the Oracle OS user account, Oracle Grid accounts, any Oracle Database Vault accounts (for example, users who have been granted the DV_OWNER and DV_ACCTMGR roles). Ensure that these accounts remain locked.

  • Avoid sharing passwords between users and login sessions. Add new Operating System users to distinguish access by different people.

3.3 External Network Dependencies

Ensure the security of your Oracle AVDF configuration by considering important external network dependencies.

When you add an external network service to Audit Vault Server or Database Firewall, you include these services to the trust model of your deployment.

For example, when you add a DNS server to an appliance, you trust the DNS server to provide the correct information about the host names that you look up. If someone compromises the DNS server, then they can control the network endpoints that are accessed by Audit Vault Server or Database Firewall using the host name.

There are analogous trust relationships in other services too, for example, NFS or NTP.

For this reason, add network services to Audit Vault Server or Database Firewall only when the following are adequately secure:

  • the service
  • the host server
  • the intermediate network

3.4 Considerations for Deploying Network-Based Solutions

Learn about what to consider when deploying network-based solutions.

3.4.1 Managing Database Firewall Network Encryption

Learn about handling Database Firewall network encryption.

You deploy Database Firewall between the database tier and application tier. Database Firewall can decrypt traffic to and from an Oracle Database when you use Oracle Native Network Encryption. For non-Oracle databases, and for Oracle Databases that use TLS network encryption, if SQL traffic between the database tier and application tier is encrypted, then Database Firewall cannot interpret or enforce protection policies on this SQL traffic.

You can use SSL or TLS termination solutions to terminate the SQL traffic just before it reaches Database Firewall.

3.4.2 Managing Database Firewall Server Side SQL and Context Configurations

Learn how to manage Database Firewall SQL and context configurations.

Database Firewall policy enforcement relies on capturing and understanding SQL traffic between the database client and server. Because Database Firewall only analyzes network traffic between the application tier and the database server, the firewall cannot examine SQL that is directly sent from the database server. Some of the types of SQL statements that Database Firewall cannot examine are system provided and user defined SQL that you run from stored procedures and callouts. The firewall also cannot examine SQL that you run from background jobs, such as those that created by the DBMS_JOB or DBMS_SCHEDULER PL/SQL packages in Oracle databases, or SQL that is indirectly run from DDLs or other SQL statements. You can use the Oracle AVDF auditing features to capture these types of SQL statements.

Database Firewall builds its execution context entirely from the information that it captures from the network traffic. However, enforcement may depend on context information on the server. Any lack of context affects the resolution of identifiers that you use in database objects.

3.4.3 How Oracle AVDF Works with Various Database Access Paths

Learn how Oracle AVDF works with database access paths.

Oracle AVDF works with the following types of database access paths:

  • Non SQL protocol access: Database platforms support different network protocols beyond the database SQL based protocols. For example, Oracle Database supports HTTP, FTP, Advanced Queuing, Direct Path, and NFS access to the data in the database. The Database Firewall provides policy enforcement only for SQL based access to the database. The protocols that Database Firewall understands are Oracle TTC/Net and Tabular Data Stream (TDS) for Microsoft SQL Server, Sybase ASE, and IBM Distributed Relational Database Architecture (DRDA).

  • IPv6 Connections: Oracle AVDF does not support IPv6 deployments. Database Firewall automatically blocks all traffic coming from IPv6 connections.

  • Non TCP based Connections: Database Firewall only supports TCP based network connections to database servers. It cannot monitor connections that are made to database servers using non TCP protocols such as Systems Network Architecture (SNA), Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX).

3.4.4 Database Firewall Configuration for Oracle Database Target Configured in Shared Server Mode

Learn about managing Database Firewall shared server configuration.

Shared server architectures enable databases to permit user processes to share server processes. A dispatcher process directs multiple incoming network session requests to a common queue, and then redirects these session requests to the next available process of the shared server. By default, Oracle Database creates one dispatcher service for the TCP protocol. In the init.ora file, this setting is controlled by the DISPATCHERS parameter, as follows:

dispatchers="(PROTOCOL=tcp)"

In the default configuration, a dynamic port listens to the incoming connection using the TCP protocol. With a shared server configuration, many user processes connect to a dispatcher on this dynamic port. If the Database Firewall is not configured to monitor the connections on this port, then the policy cannot be enforced on these connections. To facilitate the Database Firewall connection configuration, you should explicitly include the port number in the DISPATCHERS parameter. For example:

dispatchers="(PROTOCOL=tcp)(PORT=nnnn)"

Choose a value for nnnn, and configure the Database Firewall to protect that address, alongside the usual listener address.

See Also:

3.4.5 Additional Client and Listener Behavior Considerations

Learn about additional issues to be aware of with clients and shared listeners.

  • Client-side context: You can configure Oracle Database Firewall policies to use client-side context information such as client program name, client operating system username, and so on. After the client transmits this information to the database, Oracle Database Firewall captures it from the network. Oracle Database Firewall does not control or enforce the integrity of the client side or network. Consider the integrity of this information before using it to define security policies.

  • Multiple databases and services on a shared listener: Oracle Database Firewall supports policies based on Oracle Database service names. For non-Oracle databases, Oracle Database Firewall enforces policies that are based on the IP address and port number. In a configuration where a single listener endpoint (IP_address:port) is shared among multiple databases, Oracle Database Firewall cannot differentiate traffic that is directed to each individual database.

3.5 Security Considerations for Special Configurations

Learn about security considerations for special configurations.

3.5.1 Custom Collector Development

Learn about custom collector development.

Note the following if you develop custom collectors:

  • Prevent resource leaks. Ensure that JDBC resources are closed appropriately. These resources include the connections, result sets, and statements.
  • Prevent data loss. Ensure that your audit data is purged from the target system only after it has been successfully collected by the custom collector.
  • Avoid frequent queries to the target system.
  • Ensure that the custom collector does not consume a lot of system resources such as CPU and memory on the target host.
  • Avoid logging audit data because the audit records contain sensitive information.
  • Grant only the required privileges on the target system to users who have access to the Agent.
  • Ensure that only necessary files are added to custom collector .jar file.
  • Ensure that your custom collector code collects the audit data from your target system securely.

    Note:

    The collection framework ensures that audit data is transferred from the collector to Oracle Audit Vault Server securely.

3.6 About Setting Transport Layer Security Levels

Learn about setting Transport Layer Security (TLS) levels in Oracle AVDF.

This topic describes the different levels of connection encryption deployed on Oracle Audit Vault and Database Firewall appliances. Oracle AVDF uses TLS for inter component communication.

You can change the TLS levels and cipher suites for the following:

  • Connection between Audit Vault Server and the Agent or Host Monitor

  • Connection between Host Monitor and Database Firewall

  • Connection between Audit Vault Server and Database Firewall

  • Audit Vault Server console and the end user browsers

Note:

Connection Encryption Strength Used On Oracle AVDF Appliances

TLS Level TLS Version Description

Level-4

(Default on new installation)

TLSv1.2

This level is the strongest, restricting TLS to version 1.2 for inter communication between all the components in Oracle Audit Vault and Database Firewall.

Note:

It is recommended to use Level-4 for all services unless the supported service explicitly requires a lower level of TLS.

Level-3

TLSv1.2

This level supports everything that Level-4 does.

Note:

  • If any Audit Vault Agent has to be deployed on IBM AIX, then set the TLS level to Level-3 or below (refer to row # 5 in the table below).
  • Level-3 uses TLS 1.2 or TLS 1.1 for Audit Vault Agent to Audit Vault Server communication. It is the same for Host Monitor Agent to Database Firewall communication.

Level-2

TLSv1.2
TLSv1.1

This level adds support for legacy and deprecated ciphers.

Note:

The upgrade process does not automatically set to Level-4 to maintain connectivity while upgrading a multi appliance deployment. Upon completion of the upgrade, set to Level-4 unless interoperability with legacy systems is required.

Level-1

(Custom)

TLSv1.2

This is a customizable cipher set that is configured with Level-4 strength by default.

How To Change TLS Levels and Other Tasks

Row No. Task Command Detailed Information

1

To check the existing TLS levels for Audit Vault Server and Database Firewall.

grep CIPHER_LEVEL /usr/local/dbfw/etc/dbfw.conf

Log in as support user and run this command. Use this command to check the actual configuration of the Audit Vault Server and Database Firewall.

2

To set the TLS level and to find more options.

/usr/local/dbfw/bin/priv/configure-networking --help

Log in as root user and run this command. By default, on a new installation the TLS level is set to Level-4.

On upgrade it is set to Level-2 by default. This is appropriate to most of the situations.

It is possible to change the level set. Use this command to find the options available.

3

To set TLS level for the Audit Vault Sever console.

/usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level [LEVEL]

Log in as root user and run this command. This command sets the TLS level for web browser connections to the AVS GUI. The levels can be set to 1, 2, 3, or 4.

4

To set TLS level for communication between Audit Vault Server and Database Firewall.

/usr/local/dbfw/bin/priv/configure-networking --internal-tls-cipher-level [LEVEL]

Log in as root user and run this command. This command sets the desired TLS level and restarts the internal services. The levels can be set to 1, 2, 3, or 4.

5

To set the TLS level for Audit Vault Agent to Audit Vault Server, and Host Monitor to Database Firewall communication.

/usr/local/dbfw/bin/priv/configure-networking --agent-tls-cipher-level [LEVEL]

Log in as root user and run this command. This command sets the TLS level for communication between the Audit Vault Agent to Audit Vault Server, and Host Monitor to Database Firewall. The levels can be set to 1, 2, 3, or 4.

Note:

Perform the following steps to upgrade all Agents to the specified TLS levels after executing the configure-networking command:

1. Log in to the Audit Vault Server console as root user.

2. Change the directory by using the command:

cd /usr/local/dbfw/bin/priv

3. Execute the script using the command:

./send_agent_update_signal.sh

This command must not be executed more than once in a period of one hour.

6

To apply customized cipher set.

/usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level 1 --internal-tls-cipher-level 1 --agent-tls-cipher-level 1

By default, on a new installation the product is set to Level-4. On upgrade it is set to Level-2. This is appropriate to most of the situations. It is possible to customize. There are prompts and warning messages during the upgrade process which indicate that the cipher levels are not set to maximum security. The cipher levels are not automatically changed during upgrade.

Use this command to apply the custom defined level from the file created. These commands set the TLS level for web browser connections and restart the internal services and Audit Vault Server.

Note:

Before executing this command verify the error output in the system log file available at /var/log/messages to confirm that there are no errors in the file.

7

To edit the custom level configuration file.

/usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group.xml

/usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_agent.xml

/usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_ssl_services.xml

Log in as root user to run this command. The customizable set of cipher suites is defined in this file. By default, on a new installation the product is set to Level4. This file can be modified to further restrict the cipher suite and include ciphers available on the product.

8

To display the complete list of available cipher suites.

openssl ciphers -v

Log in as support user to run this command. Use this command to display the current set of available cipher suites.

When To Change TLS Levels

Oracle recommends leaving the internal TLS level at Level-4. Here is some more information on when to change the TLS levels:

Component Situation

Internal communication

Oracle recommends to set at Level–4 for increased security.

Audit Vault Server console (GUI)

To support old browsers, set the TLS level to match the browser.

Audit Vault Agent / Host Monitor / Audit Vault Server

Oracle recommends to set at Level–4 for increased security.

Audit Vault Agent deployed with IBM AIX

On a fresh installation, it is set to Level–4. Change the TLS level to Level-3 if any of the Audit Vault Agents are deployed on IBM AIX.

Setting Custom Cipher Sets

Log in as root user to run this procedure for setting the custom cipher set. Do this by creating a custom file that defines the TLS levels and later applying the file.

  1. The customizable set of TLS levels are defined in the following files:
    • /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group.xml

    • /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_agent.xml

    • /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_ssl_services.xml

  2. The tls_configuration_custom_group.xml file can be modified as desired to include available ciphers on the product.
  3. Execute the following command to display the complete list of available ciphers:
    openssl ciphers –v
  4. Open the tls_configuration_custom_group.xml file and verify the format of the file. The format must be similar to the following:
    <?xml version="1.0" encoding='UTF-8' standalone='yes'?>
    <tls_configuration_groups xmlns='http://www.oracle.com/avdf'>
    <tls_configuration level="1">
    <ssl_protocols>
    <ssl_protocol>...</ssl_protocol>
    </ssl_protocols>
    <ssl_cipher_suite>
    <ssl_cipher>...</ssl_cipher>
    </ssl_cipher_suite>
    </tls_configuration>
    </tls_configuration_groups>
  5. In the customizable tls_configuration_custom_group.xml file, only the following tags can be added or removed as required:
    <ssl_protocol>...</ssl_protocol>
  6. Multiple tags can be applied in a sequence as follows:
    <ssl_cipher>...</ssl_cipher>
  7. The values must be any of the following Apache protocol values:
    1. TLSv1.2
    2. TLSv1.1
    3. TLSv1 (Deprecated)
  8. Execute the following command to apply the custom set.
    /usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level 1 --internal-tls-cipher-level 1 --agent-tls-cipher-level 1