Skip Headers

Oracle® Audit Vault Administrator's Guide 10g Release 2 (10.2.2) Part Number B25321-02 |
Home | Book List | Contents | Index | Contact Us

Previous | Next
| View PDF

# 2 Managing Audit Vault Security

Oracle Audit Vault uses the industry leading security capabilities of Oracle Database Vault and Oracle Advanced Security features to protect audit data from the moment it is collected, transmitted, consolidated, and stored in a centralized, protected, audit data repository. This chapter provides an understanding of how to manage Oracle Audit Vault security. Audit Vault administrators should perform Oracle Audit Vault security tasks in this order of importance:

1. Secure management communication between Audit Vault Server and Audit Vault Agent (see Oracle Advanced Security – Secure Management Communication).

2. Encrypt network traffic between Audit Vault Server and Audit Vault Agent (see Oracle Advanced Security – Encrypt Network Traffic).

3. Manage user authentication metadata (see Oracle Advanced Security – Manage User Authentication Metadata).

This chapter also includes the following additional sections as background information to assist Audit Vault administrators in understanding how Oracle Database Vault protects audit data and provides strong access control:

- Oracle Database Vault – Protects Oracle Audit Vault

- Oracle Database Vault – Provides Strong Access Controls

## 2.1 Oracle Advanced Security – Secure Management Communication

Audit Vault administrators can further secure management communication between the Audit Vault Server and the Audit Vault Agent by using the HTTPS protocol to encrypt data (see Figure 1-2). In this case, X.509 certificates are provided by the Audit Vault administrator and are used for authentication. This is part of the postinstallation configuration of Oracle Audit Vault. Secure Sockets Layer (SSL) is configured for the mutual authentication between the Audit Vault management service on the server side and each agent over HTTPS. A Certificate Authority must provide these certificates to the Audit Vault administrator.

See Also:

Oracle Database Security Guide for more information about PKI-based authentication, digital certificates, and secure external password stores and Oracle Database Advanced Security Administrator's Guide for more information about Oracle wallets.

Once Audit Vault Server and Audit Vault Agent communication is secured using HTTPS, the browser must also use HTTPS to access the Audit Vault Console. There is no longer an HTTP protocol available for the browser user, because the browser to Audit Vault Console communication is also made secure.

Setting Up Mutual Authentication Between Audit Vault Server and Its Agents

See Oracle Database Advanced Security Administrator's Guide for information about using Oracle Wallet Manager to obtain X.509 certificates from a Certificate Authority for the Audit Vault Agent and importing them into the wallet. Use the keytool located at `$ORACLE_HOME/jdk/bin/keytool` to generate the key store if this becomes necessary. Once the key store and certificates are in place at the agent side, next set up mutual authentication between Audit Vault Server and its agents. To do this, use the AVCA secure_av command from the system where Oracle Audit Vault Server is installed. This operation secures Oracle Audit Vault Server by enabling mutual authentication with Oracle Audit Vault Agent.

The AVCA secure_av command takes the following arguments:

- `-avkeystore <keystore location>` -- The key store location for Audit Vault

- `-avkeystorepwd <keystore password>` -- The key store password for Audit Vault. The `-avkeystorepwd` argument can be omitted if the corresponding environment variable, `AVCA_AVKEYSTOREPWD` is set to `keystore password`. If the command-line argument `-avkeystorepwd` is specified, then the command-line argument overrides the environment variable.

- `-avtruststore <truststore location>` -- The trust store location for Audit Vault

The following AVCA secure_av command secures Oracle Audit Vault Server by enabling mutual authentication with Oracle Audit Vault Agent. In this example, the environment variable, `AVCA_AVKEYSTOREPWD` is set to `welcome_1` and the -avkeystorepwd argument is omitted from the example.

    avca secure_av -avkeystore /tmp/avkeystore -avtruststore /tmp/avkeystore

From the system where Oracle Audit Vault Agent is installed, the AVCA secure_agent command secures the Oracle Audit Vault Agent by enabling mutual authentication with Oracle Audit Vault Server.

The AVCA secure_agent command takes the following arguments:

- `-agentname <agent name>` -- The name of the agent (by agent name) must be in secure mode

- `-agentkeystore <keystore location>` -- The key store location for this agent

- `-agentkeystorepwd <keystore password>` -- The key store password for this agent. The `-agentkeystorepwd` argument can be omitted if the corresponding environment variable, `AVCA_AGENTKEYSTOREPWD` is set to `keystore password`. If the command-line argument `-agentkeystorepwd` is specified, then the command-line argument overrides the environment variable.

- `-avdn` `<DN of Audit Vault>` -- The distinguished name (DN) of Audit Vault

- `-agentdn <DN of Agent>` -- The DN of this Audit Vault Agent

The following AVCA secure_agent command secures the Audit Vault Agent by enabling mutual authentication with Audit Vault. In this example, the environment variable, `AVCA_AGENTKEYSTOREPWD` is set to `welcome_1` and the -agentkeystorepwd argument is omitted from the example

    avca secure_agent -agentname TTAGENT12 -agentkeystore /tmp/agentkeystore
    -agentdn "CN=agent1, OU=development, O=oracle, L=redwoodshores, ST=ca, C=us"
    -avdn "CN=av1, OU=development, O=oracle, L=redwoodshores, ST=ca, C=us"

## 2.2 Oracle Advanced Security – Encrypt Network Traffic

Because audit data is sensitive data and moves across the network as it is either collected by collectors from sources or is sent to the Audit Vault Server (see Figure 1-2), it is important to encrypt the network traffic to absolutely guarantee the security of this audit data.

Oracle Advanced Security encryption is used to set the encryption between a server and an agent. In this sense it is the server system on which Audit Vault server is installed and the agent system on which an Audit Vault Agent is installed.

The following sections describe a basic method of verifying that Oracle Advanced Security encryption is working, if it is to be used by your site. The easiest way to tell if Oracle Advanced Security encryption is working is to deliberately set wrong configuration parameters and attempt a connection between the server and agent. Incorrect parameters cause the connection to fail.

After receiving the expected failure message, set the configuration parameters to the correct settings and try the connection again. Oracle Advanced Security encryption is working properly if no further error messages are received.

The following procedures test Oracle Advanced Security encryption by this method. The incorrect parameter settings produce error 12660.

### 2.2.1 Setting Up Oracle Advanced Security Encryption as a Test of Your Site

Perform the following steps to set up Oracle Advanced Security encryption:

1. Set Oracle Advanced Security encryption parameters for the server.

2. Set Oracle Advanced Security encryption parameters for the agent.

#### 2.2.1.1 Step 1: Set Encryption Parameters for the Server

Use the appropriate editor for the server platform to add the following parameters and values to change the `sqlnet.ora` file.

    SQLNET.CRYPTO_CHECKSUM_SERVER = REJECTED
    SQLNET.ENCRYPTION_SERVER = REJECTED
    SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA-1)
    SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)
    SQLNET.CRYPTO_SEED = "abcdefg"

The value shown for `SQLNET.CRYPTO_SEED` is only an example. Set it to the value that you want. See Oracle Database Advanced Security Administrator's Guide for more information.

#### 2.2.1.2 Step 2: Set Encryption Parameters for the Agent

Edit the listener configuration file on the agent system (`sqlnet.ora`) to add the following parameters:

    SQLNET.CRYPTO_CHECKSUM_CLIENT = REQUIRED
    SQLNET.ENCRYPTION_CLIENT = REQUIRED
    SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (SHA-1)
    SLQNET.ENCRYPTION_TYPES_CLIENT = (AES256)
    SQLNET.CRYPTO_SEED = "abcdefg"

The value shown for `SQLNET.CRYPTO_SEED` is only an example. Set it to the same value used on the server system.

### 2.2.2 Testing Oracle Advanced Security Encryption

After completing Steps 1 and 2 of the configuration procedure, you are ready to test the operation of the Oracle Advanced Security encryption.

#### 2.2.2.1 Checklist for Testing Encryption

1. Connect the agent and server.

2. Reset configuration parameters on the server.

#### 2.2.2.2 Step 1: Connect Agent and Server

Attempt a connection between the server and agent systems. You should receive the following error message:

    ORA-12660: Encryption or crypto-checksumming parameters incompatible

#### 2.2.2.3 Step 2: Reset Configuration Parameters on Server

Change the Oracle Advanced Security encryption parameters on the server to:

    SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
    SQLNET.ENCRYPTION_SERVER = REQUIRED

Attempt the connection between the agent and server again. If no error message is returned and the connection completes, then encryption is working properly.

## 2.3 Oracle Advanced Security – Manage User Authentication Metadata

As part of the Oracle Audit Vault Server and the Oracle Audit Vault Agent installation, two wallets are created. One wallet resides on the Audit Vault Server and this one contains the `AV_ADMIN` user's credentials and is used by the Audit Vault Console to communicate to the Audit Vault database. This Audit Vault Console provides the management service that initiates the communication with agents using HTTP. Audit Vault Configuration Assistant (AVCA) modifies the Database Control console `server.xml` file and other related files to enable Audit Vault management through the Oracle Enterprise Manager Database Control console. The wallet is located in the `$ORACLE_HOME/network/admin/avwallet` directory.

The other wallet resides on the Audit Vault Agent and contains the `AV_AGENT` credentials and is used by the agent to get configuration data from the database. It is located in the `$ORACLE_HOME/network/admin/avwallet` directory. The agent-side wallet also contains the credentials used by the collectors to communicate to the source Oracle database. These credentials are used by the three ORCLDB collectors to connect to the source and to:

- Get audit records using the DBAUD collector

- Start and stop the REDO collector

- Get metadata for all the ORCLDB collectors

- Get audit settings as part of Audit Settings management

The Oracle wallet is a password-protected container that stores credentials, such as certificates, authentication credentials, and private keys, all of which are used by SSL for strong authentication. Oracle wallets are managed through Oracle Wallet Manager. Oracle Wallet Manager can perform tasks such as wallet creation, certificate request generation, and certificate import into the wallet.

This section describes managing metadata for Audit Vault administrators that includes:

- Creating Wallet Metadata

- Creating Certificate Metadata

### 2.3.1 Creating Wallet Metadata

A wallet holds credentials created using the AVCA create_credential command.

Provide the following information to create a wallet:

- `-wrl <wallet location>` – Wallet location

- `-wpwd <wallet password>` – Wallet password, needed to open the wallet. The `-wpwd` argument can be omitted if the corresponding environment variable, `AVCA_WPWD` is set to `wallet password`. If the command-line argument `-wpwd` is specified, then the command-line argument overrides the environment variable.

Use the AVCA create_wallet command to create a wallet. However, before you run this command, create an environment variable named `AVCA_WPWD` set to `welcome1`, the wallet password. Then run the command. For example:

    avca create_wallet -wrl $T_WORK/tt_1

See the AVCA create_wallet command for more reference information.

### 2.3.2 Creating Certificate Metadata

Oracle Audit Vault uses third-party network authentication services, PKI-based authentication, to authenticate its user clients. Authentication systems based on public key infrastructure (PKI) issue digital certificates to user clients, which use them to authenticate directly to servers in the enterprise without directly involving an authentication server. These user certificates, along with the private key of the user and the set of trust points of a user (trusted certificate authorities), are stored in Oracle wallets.

As part of the Oracle Audit Vault Server and Oracle Audit Vault Agent installation, Audit Vault creates the wallet and stores the certificates that are needed for users. The AVCA create_credential command is useful if a new certificate for an existing user must be created. For example, use the AVCA create_credential command to create a new certificate if someone changes the source user password on the source, thus eventually breaking the connection between the collector and the source.

Provide the following information to create a credential to be stored in the wallet:

- `-wrl <wallet location>` – Wallet location

- `-wpwd <wallet_password>` – Wallet password, needed to open the wallet. The `-wpwd` argument can be omitted if the corresponding environment variable, `AVCA_WPWD` is set to `wallet password`. If the command-line argument `-wpwd` is specified, then the command-line argument overrides the environment variable.

- `-dbalias <db alias>` – Database alias

- `-usr <usr>/<password>` – Target user name and password to be secured and stored in the wallet. The `-usr` argument can be omitted if the corresponding environment variable, `AVCA_USR` is set to `usr/password`. If the command-line argument `-usr` is specified, then the command-line argument overrides the environment variable.

Use the AVCA create_credential command to create a credential. However, before you run this command, create an environment variable named AVCA_WPWD set to welcome1, the wallet password; and an environment variable named AVCA_USR set to scott/tiger. Then run the command. For example:

    avca create_credential -wrl $T_WORK/tt_1 -dbalias inst1

After executing this command, you must modify the `sqlnet.ora` file as described in the AVCA create_credential command usage notes in Appendix A, and if needed, set the `$TNS_ADMIN` environment variable.

## 2.4 Oracle Database Vault – Protects Oracle Audit Vault

Oracle Database Vault provides realms, separation of duty, command rules and factors as features that are applicable to reducing the overall risk associated with specific provisions of regulations worldwide. These regulations have common themes that include internal controls, separation of duty, and strong access controls on access to sensitive information. Technical solutions are required to mitigate the risks associated with items such as unauthorized modification of data and unauthorized access.

Oracle Database Vault realms prevent database administrators (DBAs), application owners, and other privileged users from viewing application data using their powerful privileges. Database Vault realms put in place preventive controls, helping reduce the potential impact when a data breach does occur, enabling the DBA to perform his or her job more effectively. Oracle Database Vault realms can be used to protect an entire application or a specific set of tables within an application, providing highly flexible and adaptable security enforcement. Oracle Audit Vault audit data is protected in this way.

Oracle Database Vault prevents highly privileged users (DBAs) from accessing audit data. It enforces a separation of duty by not allowing the same user granted two or more administrator roles to perform different responsibilities in the same session and optimally to have different administrator users be granted respective roles to perform these responsibilities in separate sessions.

Oracle Database Vault provides two roles, `DV_ACCTMGR` to manage database user accounts and `DV_OWNER` to manage database roles and configuration. The security administrator granted `DV_ACCTMGR` role can create, alter, and drop users and this user creates all Audit Vault administrator users. The security administrator granted `DV_OWNER` role can grant Oracle Database Vault roles. The Audit Vault administrator user granted the `AV_ADMIN` role grants all Audit Vault roles. Thus, two different highly privileged users are required one to create Audit Vault users and the other to grant these users Audit Vault roles. In this way, Oracle Database Vault and Oracle Audit Vault protect audit data from access, enforce protection of database structures from unauthorized change, and set a variety of access controls to implement dynamic and flexible security requirements. See Section 2.5 for more information about these Database Vault security administrator accounts, Audit Vault administrator accounts, and the core database user accounts.

Using Oracle Database Vault, highly privileged database users can be prevented from accessing application data. In addition, access to applications, databases, and data can be tightly controlled based on such variables as time of day, IP address or subnet.

## 2.5 Oracle Database Vault – Provides Strong Access Controls

Audit Vault is a secure data warehouse that consolidates audit data across an enterprise. The data is only visible to Audit Vault auditors once it is moved into the Audit Vault data warehouse. No user can access the audit data before it is moved to the Audit Vault data warehouse nor after it is purged from there. Even a `SYS` user cannot access this secure audit data. The default privilege that a `SYS` user will have is the ability to lock and unlock the Audit Vault schema. This extremely tight security is necessary to prevent audit trail data, which is extensive, detailed, and sensitive information, from being compromised. Oracle Database Vault features guarantee this level of security.

Audit Vault predefined administrator roles include:

- `AV_ADMIN` – Accesses Oracle Audit Vault services to administer, configure, and manage a running Oracle Audit Vault system. A user granted this role configures and manages audit sources, agents, collectors, the setup of the source with the agent, and the warehouse. Only the user granted the `AV_ADMIN` role can grant the appropriate role (`AV_ADMIN`, `AV_AUDITOR`, `AV_AGENT`, and `AV_SOURCE`) through SQL*Plus.

- `AV_AUDITOR` – Accesses Audit Vault reporting and analysis services to monitor components, detect security risks, create and evaluate alert scenarios, create detail and summary reports of events across systems, and manage the reports. A user granted this role manages central audit settings and alerts. This user also uses the data warehouse services to further analyze the audit data to assist in looking for trends, intrusions, anomalies, and other items of interest. A user is created and granted this role during the Audit Vault Server installation.

- `AV_AGENT` – Manages agents and collectors by starting, stopping, and resetting them. A user is created and granted this role prior to an agent installation. A user is created and granted this role prior to an agent installation. The Audit Vault Agent software uses this role at run time to query Oracle Audit Vault for configuration information.

- `AV_SOURCE` – Manages the setup of sources for audit data collection. A user is created prior to source and collector configuration and granted this role upon adding a source to Audit Vault using the AVORCLDB add_source command. The collector software uses this role at run time to send audit data to Audit Vault.

- `AV_ARCHIVER` – Archives and deletes audit data from Audit Vault and cleans up old unused metadata and alerts that have already been processed. A user granted this role can archive raw audit data.

- `DV_OWNER` – Manages Oracle Database Vault roles and configuration.

- `DV_ACCTMGR` – Manages database user accounts. Only the user granted this role can create Audit Vault administrator users.

Table 2-1 shows the roles and privileges an administrative user is granted when that user is granted one of the high level Audit Vault or Database Vault roles. Typically, one user is granted an `AV_ADMIN` role and one user is optionally granted an `AV_AUDITOR` role as part of installing the Audit Vault Server. The user granted the `AV_ADMIN` role can be granted the `AV_AUDITOR` role if that user is not created during the Audit Vault Server installation. Because Oracle Audit Vault is protected by Oracle Database Vault, only the user granted the `DV_ACCTMGR` role can create, alter, and drop users.

Table 2-1 Roles and Privileges Granted to Administrators Granted a Specific Audit Vault or Database Vault Role

Role Granted to User | Roles Granted | Privileges Granted
--- | --- | ---
AV_ADMIN | DV_PUBLIC AV_ADMIN SELECT_CATALOG_ROLE HS_ADMIN_ROLE AQ_ADMINISTRATOR_ROLE AQ_ADMINISTRATOR_ROLE AV_AUDITOR AV_AGENT | CREATE SESSION CREATE ANY VIEW GRANT ANY ROLE MANAGE ANY QUEUE ENQUEUE ANY QUEUE DEQUEUE ANY QUEUE CREATE EVALUATION CONTEXT CREATE RULE SET CREATE RULE
AV_AUDITOR | DV_PUBLIC, AV_AUDITOR SELECT_CATALOG_ROLE HS_ADMIN_ROLE | CREATE SESSION
AV_AGENT | DV_PUBLIC AV_AGENT | CREATE SESSION CREATE ANY VIEW
AV_SOURCE | DV_PUBLIC RESOURCE AV_SOURCE AV_USER_ROLE | CREATE SESSION RESTRICTED SESSION UNLIMITED TABLESPACE CREATE TABLE CREATE CLUSTER CREATE SEQUENCE CREATE DATABASE LINK CREATE PROCEDURE CREATE TRIGGER CREATE TYPE CREATE OPERATOR CREATE INDEXTYPE MANAGE ANY QUEUE ENQUEUE ANY QUEUE DEQUEUE ANY QUEUE CREATE EVALUATION CONTEXT CREATE RULE SET CREATE ANY RULE SET ALTER ANY RULE SET EXECUTE ANY RULE SET CREATE RULE CREATE ANY RULE ALTER ANY RULE EXECUTE ANY RULE
DV_ACCTMGR | DV_PUBLIC CONNECT DV_ACCTMGR | CREATE SESSION CREATE USER ALTER USER DROP USER CREATE PROFILE ALTER PROFILE DROP PROFILE
DV_OWNER | DV_PUBLIC CONNECT DV_OWNER DV_ADMIN DV_SECANALYST | CREATE SESSION GRANT ANY ROLE ALTER ANY TRIGGER ADMINISTER DATABASE TRIGGER

The Audit Vault roles are granted or revoked through the SQL*Plus interface using the SQL GRANT and REVOKE commands in the following way. All granting or revoking of Audit Vault roles or privileges is done through SQL*Plus by the user who has `AV_ADMIN` role granted. To add more users, a user must connect having `DV_ACCTMGR` role to create the users; however, this user cannot also grant these roles to these users. Only the user granted the `AV_ADMIN` role can then grant the appropriate role (`AV_ADMIN`, `AV_AUDITOR`, `AV_AGENT`, or AV_SOURCE), through SQL*Plus.

An Audit Vault administrator with one of these predefined roles granted can assume only one administrative responsibility at a time in a given session. For instance, if the Audit Vault administrator must perform a different task in another role, the same administrator must begin a new session to start that task.

Note:

Users granted more than one Audit Vault role can only log in to the Audit Vault Console as a single role. They must log out and log in to an Audit Vault system again to use a different role. This security measure maintains a separation of duties within an Audit Vault system for each Audit Vault user.

Audit Vault allows incoming connections based on Secure Sockets Layer (SSL) protocol only and its listener can receive only TCP/IP with SSL (HTTPS) connections. Thus, all Audit Vault users are external SSL users. Audit Vault provides a public key infrastructure (PKI) if one is needed; otherwise, customers can use their existing public key interface. If using the Audit Vault public key infrastructure, users are required to regenerate wallets on a regular basis every few months as determined by the account refresh frequency (ARF).

Table 2-2 shows all other database core accounts created in the default Audit Vault installation. The operating system authentication to the database is disabled by default. In addition, connections to the database using the `SYSDBA` privilege (that is, those that use the `AS SYSDBA` clause) are disabled. This is a security feature and is implemented to prevent misuse of the `SYSDBA` privilege. You must connect to the database using the `SYSOPER` privilege (connections that use the `AS SYSOPER` clause) to manage the Audit Vault database; such as, shutting it down and starting it up. See "Postinstallation Tasks" in the Oracle Audit Vault installation guides for more information about unlocking and resetting user passwords and enabling or disabling connections with the SYSDBA Privilege.

Table 2-2 Database Core Accounts Created and Privileges In Use

Account | Privileges | Privilege In Use or Not | Password to Use
--- | --- | --- | ---
SYS SYSTEM SYSMAN DBSNMP | Many | Yes | Same password as user granted AV_ADMIN role for basic installation or password may be set separately in advanced installation. To use, user account must be unlocked and password reset.
/ AS SYS AS | SYSDBA | No, not allowed | To use, user must create password file to enable its use. Password is set when password file is created.
/ AS SYS AS | SYSOPER | Yes, allowed | Same password as user granted AV_ADMIN role.

The following example shows how to add a new Audit Vault administrator auditor account, grant this new user the `AV_AUDITOR` role, then check this user's granted roles and privileges.

    sqlplus /nolog
    SQL> connect avadmindva
    Enter password: <avadmindvapassword>
    Connected.
    SQL> create user avauditor2 identified by Welcome_99;

    User created.

    SQL> connect avadmin
    Enter password: <avadminpassword
    Connected.
    SQL> grant AV_AUDITROR to avauditor2;

    Grant succeeded.

    SQL> connect avauditor2
    Enter password: <avauditor2password>
    Connected.
    SQL> show user
    USER is "AVAUDITOR2"
    SQL> select * from session_roles;

    ROLE
    ------------------------------
    DV_PUBLIC
    AV_AUDITOR
    SELECT_CATALOG_ROLE
    HS_ADMIN_ROLE

    SQL> select * from session_privs;

    PRIVILEGE
    ----------------------------------------
    CREATE SESSION

The following example shows how to connect as the `SYS` user with `SYSOPER` privilege (using the clause `AS SYSOPER`), shut down the Audit Vault database, and then start it up again.

    sqlplus /nolog
    SQL connect sys as sysoper
    Enter password: <sysoperpassword>
    Connected.
    SQL> shutdown immediate
    Database closed.
    Database dismounted.
    Oracle instance shut down.

    SQL> startup
    Oracle instance started.
    Database mounted.
    Database opened.
    SQL> exit