1 Overview of Oracle Audit Vault and Database Firewall

Topics

• Introduction to Database Security

• What Is Oracle Audit Vault and Database Firewall?

• Oracle Audit Vault and Database Firewall Architecture, Components, and Roles

• Oracle Audit Vault and Database Firewall and Oracle Enterprise Manager

• Understanding the Software Appliance Model

• Planning an Oracle Audit Vault and Database Firewall Deployment

1.1 Introduction to Database Security

Topics:

• What Is Auditing?

• What Is Database Activity Monitoring?

• Why Auditing and Monitoring?

1.1.1 What Is Auditing?

Auditing is the main tool in the "trust but verify" approach to security, as well as a tool for forensic analysis, that is, finding who performed certain actions and when they performed these actions.

Maintaining an audit trail of activity is an essential component of any defense-in-depth strategy for securing a system. Even when access controls are properly configured and privilege grants are minimized, two important risks still remain. The first is that users who need significant privileges to perform their jobs may misuse those privileges. The second is that a user may gain unexpected access through access controls or privilege grants that are unintentionally configured to be more generous than necessary. Auditing is the primary tool for detecting the actions that these users perform so that they can be corrected.

Effective auditing requires audit policies that are selective in capturing the important details about significant events while minimizing the noise from routine activity. Some of the most important events to audit in databases are failed logins, events requiring access by privileged users, and data definition (DDL) types of activities such as CREATE, DROP, ALTER, RENAME, or TRUNCATE. Besides databases, other systems such as operating systems, file systems, and directory services, also have audit data that can be collected. Auditing provides a history of who did what and when, and enables organizations to meet stringent controls and reporting requirements.

In addition, many customers must audit systems to comply with SOX, HIPAA, PCI DSS, GLB, FISMA, and other international standards. Internal governance, local security policies, and forensic reporting also drive the need to audit.

Auditing requires secure storage and controlled access for the audit data so that it cannot be manipulated to hide suspicious activities. Auditing also requires convenient ways to search through the collected audit data to find specific information or detect unusual activity.

You may be using Oracle Database's robust auditing features as well as auditing features of other database products. Regardless of whether you are using Oracle Database, auditing and auditing features of other database products are important to make sure that your systems are provisioned with sufficient storage capacity to sustain the amount of audit data collected. Oracle Database's native auditing has low overhead and does not degrade performance when done correctly. When using other database products, refer to their documentation libraries as necessary.

1.1.2 What Is Database Activity Monitoring?

With effective monitoring of SQL input to the database, you can block or raise alerts for attempted policy violations and provide comprehensive reports about database activity for compliance purposes.

Most applications today operate using a single user account for communicating with the database, and many do not validate their input sufficiently. This application architecture, combined with the increasing number of attacks on databases via SQL injection or insiders with access to privileged accounts, has made database activity monitoring an important component of the overall security architecture.

SQL injection is perhaps the most common attack approach to databases. SQL injection exploits flaws in application code—the application that sends SQL statements to a database. Given that much of that application code is written without analyzing possible SQL injection issues, many applications are exposed to vulnerabilities.

Whereas auditing captures events that already happened at the database, the Database Firewall monitors, and optionally blocks, malicious SQL before it reaches the database. Database Firewall not only monitors the connection to the database, but it monitors any connection to the database whether coming from an application server or a user connecting to the database directly. This monitoring reduces both insider threats, as well as the ability of an outsider to launch a successful SQL injection attack.

Database Firewall policies can be used to monitor, alert, block, and/or substitute SQL based on user session information, such as IP address or user name, or based on the SQL grammar itself. In this way, you can use a firewall to both allow approved SQL and disallow specific SQL statements.

1.1.3 Why Auditing and Monitoring?

Auditing and monitoring provides security against data breaches.

In today's global enterprise environments, security must be considered as important as high availability and scalability. Studies indicate that the most prevalent data breaches involve access by privileged users and SQL injection attacks. A DBA, or someone using a DBA user account privileged access rights, can walk out of the office with enormous amounts of sensitive data. Similarly, a remote intruder can gain access to sensitive data, and exploit a SQL injection vulnerability.

The recommended approach to securing data against breaches due to access rights is to "trust but verify." You can trust your privileged users, but you need tools to verify that neither they, nor others who have gained access to their privileges, have accessed data, or violated your security policies. Similarly, applications that access your databases are often vulnerable to SQL injection attacks if they are not programmed with the correct security considerations.

The Oracle solution to these problems is Oracle Audit Vault and Database Firewall. Oracle Audit Vault and Database Firewall can collect audit data from many different types of systems that produce audit trails. It also can monitor network activity to databases, analyze all SQL statements, and take appropriate action before this SQL reaches your database. This capability is called monitoring and blocking mode.

Oracle Audit Vault and Database Firewall provides support for Oracle Database, third-party databases, and operating systems. It provides the ability to capture and analyze audit data from Oracle Database, other databases, and operating system logs.

1.2 What Is Oracle Audit Vault and Database Firewall?

Topics:

• Introduction to Oracle Audit Vault and Database Firewall

• Audit Data Consolidation Functions

• Oracle Database Firewall Functions

• How Oracle Audit Vault and Database Firewall Fits into the Oracle Security Architecture

1.2.1 Introduction to Oracle Audit Vault and Database Firewall

Oracle Audit Vault and Database Firewall provides a comprehensive way to deal with a large amount of audit data, the risk from SQL injection, application bypass attacks over the network, and problems of unauthorized access.

Deploying Oracle Database or third-party databases can produce a large amount of audit data to consolidate. In addition to audit data from databases, operating systems, file systems and other such systems produce audit trails that can be used to analyze events relevant to security.

Standard security practices require that you transmit and manage audit data on a remote centralized location, where it is secure from tampering by the individuals whose activities you want to audit.

With large amount of audit data, it is important to have a mechanism to efficiently monitor the ongoing stream of data, to find the specific events with security implications, and to identify problems that need immediate attention.

In addition to managing a stream of audit data from heterogeneous systems, it is important to protect against SQL injection attacks, and to monitor traffic going into the database.

A Comprehensive Solution

Oracle Audit Vault and Database Firewall:

• Collects audit data from Oracle Database and third-party databases
• Supports audit collection from operating systems, file systems, and directory services
• Is delivered as a software appliance
• Secures targets from SQL attacks
• Is easy to provision, and to use with predefined policies and reports
• Is easy to consolidate, and has a unified approach
• Collects audit data from database trails and firewalls

Oracle Audit Vault and Database Firewall solves these problems by collecting and consolidating audit data, monitoring network traffic, blocking and substituting of SQL, logging, policy management, raising alerts, and providing comprehensive reports for forensic and compliance purposes.

Oracle Audit Vault and Database Firewall has three components:

• Audit Vault Server, which stores audit data from various types of sources, enables you to manage Oracle Database audit policies, and manages Database Firewall policies to protect secured targets. A secured target refers to the audited or protected systems with their databases, operating systems, and file systems.
• Audit Vault Agent, which retrieves audit trails from the secured targets and sends audit data to Audit Vault Server. An audit trail is a set of audit records collected from a sequence of activities or events on a specified target. There can be more than one audit trail for a target depending on the activities being captured.
• A database firewall

Figure 1-1 Audit Vault and Database Firewall Architecture

Description of "Figure 1-1 Audit Vault and Database Firewall Architecture"

You can choose to deploy Audit Vault Server with either the Audit Vault Agent component, or with the database firewall component, or with both components. You can use Oracle Audit Vault and Database Firewall to protect both Oracle Database, and third-party databases, and to protect both databases and non-databases such as operating systems, file systems, and directory services.

1.2.2 Audit Data Consolidation Functions

Using Oracle Audit Vault Server and Audit Vault Agents, you can consolidate audit data from multiple sources, manage Oracle Database audit policies, and monitor user entitlements.

For example:

• Consolidate audit data from multiple sources:

  • Database audit trails including Oracle Database, Microsoft SQL Server, SAP Sybase, IBM DB2 for LUW, and MySQL. These audit trails can be audit tables, audit files, or Oracle Database REDO records.

  • Stored procedure auditing (SPA), which enables you to audit changes to stored procedures on monitored databases

  • User role auditing (URA), which enables you to audit and approve changes to user roles in the databases on a specified database server

  • Operating system audit trails (Linux, IBM AIX, Oracle Solaris, Microsoft Windows)

  • Directory services, such as Microsoft Active Directory

  • File systems such as Oracle ACFS

  • Custom audit data in either database tables or XML files

• Manage Oracle Database audit policies

• Monitor Oracle Database user entitlements or activities

1.2.3 Oracle Database Firewall Functions

Oracle Database Firewall specifically protects databases from SQL attacks over the network, and monitors database activity on the network with alerts and warnings.

Using the combination of Oracle Audit Vault Server and Oracle Database Firewall, you can monitor SQL transactions to your databases. You can then decide whether a SQL statement should be permitted, blocked, or substituted before it reaches the database server.

Oracle Database Firewall sends database activity events to Oracle Audit Vault Server, which then provides specialized database firewall reports. Oracle Audit Vault Server consolidates both database firewall event logs, as well as audit events from other sources where you may have also deployed Audit Vault Agents to collect audit data.

1.2.4 How Oracle Audit Vault and Database Firewall Fits into the Oracle Security Architecture

Oracle Audit Vault and Database Firewall is the key component of the Oracle security architecture.

Oracle's security architecture provides both preventative and detective pillars of protection against threats. Oracle Audit Vault and Database Firewall is the key component of the detection pillar.

The following products form the prevention pillar:

• Oracle Advanced Security - This feature includes:

  • Transparent Data Encryption (TDE) - Automatically encrypts data before it is written on disk, and decrypts it when reading from the disk.

  • Oracle Data Redaction - Controls the display of sensitive data within applications.

• Oracle Key Vault - Securely manages database encryption keys.

• Oracle Database Vault - Controls access by privileged users.

• Oracle Data Masking and Subsetting - Masks sensitive data before exporting it from the database.

• Oracle Label Security - Simplifies the process of assigning labels to data and users and enforcing access control based on those labels

1.3 Oracle Audit Vault and Database Firewall Architecture, Components, and Roles

This section contains:

• Oracle Audit Vault and Database Firewall Terminology

• Oracle Audit Vault and Database Firewall Components

• Roles and User Accounts in Oracle Audit Vault and Database Firewall

• Integrating Other Systems with Oracle AVDF

1.3.1 Oracle Audit Vault and Database Firewall Terminology

Use this Oracle Audit Vault and Database Firewall terminology when describing the system and its functions.

The following terms describe the Oracle Audit Vault and Database Firewall system and its functions:

• Secured Targets: the systems that you want to monitor and protect

  A secured target is any supported database or non-database system that you monitor with Oracle Audit Vault and Database Firewall. A secured target can be an Oracle Database, or a third party product. Secured targets can be monitored by the Oracle Audit Vault and Database Firewall Audit Vault Agent component, the database Firewall component (if the secured target is a database), or both components. All secured targets are registered in Audit Vault Server.

  Oracle Audit Vault and Database Firewall supports various secured target types out-of-the-box. These include various databases, operating systems, file systems, and directory services. To capture audit trails from more secured target types, you can also create custom collection plug-ins for Oracle Audit Vault and Database Firewall by using the Oracle Audit Vault and Database Firewall software development kit (SDK).

• Audit Trails: how you specify the location of the audit data to collect.

  An audit trail specifies the location and type of repository where the audit data is collected. To collect audit data from a secured target, you add one or more audit trails in Oracle Audit Vault and Database Firewall for each secured target from which you want to collect the data. Defining the audit trail in Oracle Audit Vault and Database Firewall specifies the type of audit trail you are collecting, and the location of the audit data on the secured target. For example, a database can have multiple audit trails, with a different audit trail for each location where audit data is written. You can specify audit trails for a table or a transaction log. Other systems have specific locations where audit data is written. For example, in a Linux operating system, the audit trail is located in the audit.log file.

• Collection Plug-ins: Agent components that collect audit data from specific secured target types.

  The Audit Vault Agent component contains a set of collection plug-ins. There is one collection plug-in for each type of secured target that is supported out of the box. For example, there is a plug-in for Oracle Database, another plug-in for the Linux operating system, and so on. Each plug-in collects data from a specific type of audit trail, and maps the specific events from that audit trail to the audit record format in Oracle Audit Vault and Database Firewall.

  You can also develop custom collection plug-ins to collect audit data from other audit trails that are not supported out of the box.

• Hosts: the systems where you install the Audit Vault Agent component to collect audit data

  If you want to collect audit data from a secured target, then you deploy Audit Vault Agent on a host computer (usually the same computer where the secured target is located). Before you deploy the agent on this host, you specify how to connect to it by registering the host in Audit Vault Server.

• Enforcement Points: How you set up a Database Firewall to protect a database

  If you are deploying one or more instances of the database firewall component to protect databases, then you configure one database firewall monitoring point (or enforcement point) for each database. Configuring an enforcement point in Oracle Audit Vault and Database Firewall lets you select the specific instance of a database firewall used for monitoring, identify the database being monitored, and identify the network traffic sources to that database. In the enforcement point configuration, you also specify whether you want the database firewall only to monitor and raise alerts on the SQL traffic to the database, or also to block SQL traffic that is out of policy.

1.3.2 Oracle Audit Vault and Database Firewall Components

This section contains:

• Introduction to Oracle Audit Vault and Database Firewall Components

• About Oracle Audit Vault Server

• About Audit Vault Agent

• About Oracle Database Firewall

• Oracle Audit Vault and Database Firewall Components Working Together

• Oracle Audit Vault and Database Firewall Network Topology

1.3.2.1 Introduction to Oracle Audit Vault and Database Firewall Components

The components of Oracle Audit Vault and Database Firewall are Oracle Audit Vault Server, Audit Vault Agent, and Database Firewall.

Oracle Audit Vault Server is required and at least one of the other two components. You have the flexibility to deploy Oracle Audit Vault Server with either the Audit Vault Agent component, with the database firewall component, or with both. The Audit Vault Agent component enables you to consolidate and manage audit data from heterogeneous sources. The database firewall component secures your databases from SQL attacks over the network. Depending on your needs, you can decide which of the components to deploy.

1.3.2.2 About Oracle Audit Vault Server

Oracle Audit Vault Server stores audit data from various types of sources (secured targets), and the event data from the firewall of Oracle Audit Vault and Database Firewall.

Event data refers to the data gathered when an Oracle Audit Vault and Database Firewall policy is applied on an incoming SQL statement. Specifically, an incoming SQL statement and session data are compared to those defined in the policy. An action is then performed, such as logging, blocking, or substituting data. Oracle Audit Vault Server enables you to manage Oracle Database audit policies, and manages firewall policies of Oracle Audit Vault and Database Firewall to protect databases. Oracle Audit Vault Server is a dedicated server that also contains the tools necessary to configure Audit Vault Agent and the firewall of Oracle Audit Vault and Database Firewall.

Oracle Audit Vault Server has a central repository of audit and event data (from both Audit Vault Agents and firewalls). This repository is contained in an embedded Oracle Database, which includes features such as compression, partitioning, encryption, and privileged user controls.

The Oracle Audit Vault Server Web interface provides administrators with the tools to perform the following tasks:

• Creating the essential definitions necessary to monitor secured targets and configure the system
• Configuring Audit Vault Agent host connections
• Configuring (that is, adding, editing, and deleting) secured targets, audit trails, and enforcement points
• Setting up data retention (archive) policies and archive locations
• Configuring external storage
• Setting up connections to external systems, for example, for email notifications and syslog destinations
• Configuring high availability
• Controlling access by administrators and auditors

Some highlights of the Oracle Audit Vault Server Web console are illustrated in the following figures.

Figure 1-2 Audit Vault Server Dashboard

Description of "Figure 1-2 Audit Vault Server Dashboard"

Figure 1-3 Audit Vault Server - Secured Targets

Description of "Figure 1-3 Audit Vault Server - Secured Targets"

Figure 1-4 Audit Vault Server - Database Firewalls

Description of "Figure 1-4 Audit Vault Server - Database Firewalls"

1.3.2.3 About Oracle Audit Vault Information Lifecycle Management

The Information Lifecycle Management (ILM) component of the Oracle Audit Vault and Database Firewall handles audit data retention management.

The discovery task involves identifying hosts, deploying, and adding them as secured targets. Discovery manages audit data collected from all the secured targets.

Compliance Management involves evaluating compliance of targets and systems for security and storage. It performs many other tasks that maintain stability of the system.

Compliance Management enforces retention policy and expired event data. Retention policy management involves all of the tablespaces that are managed by the appliance. A new tablespace is created when a record from a target with the policy arrives into Oracle Audit Vault Server.

The audit data collected from secured targets is moved into new tablespaces based on the retention policy defined for a specific secured target. The new tablespace name is based on the retention policy. After the online retention period expires, the data is offline. The data remains in the system, and you can archive it. The data is offline, and kept local in the system until you manually archive it, either to a network file storage (NFS) or to NFS or a secure copy (SCP) location. Before triggering an archive job, you must define one or more archive locations.

You can schedule an archive job, and view the status. The tablespaces that contain audit data are automatically deleted after their retention period expires. The retention period is determined from the retention policy for a specific secured target. There is no manual intervention required.

After the tablespaces are moved to an archived location, you must not move them, or delete them manually. Any manual intervention hampers the back-end metadata, and leaves it in an inconsistent state. An inconsistent state can result in an unstable Oracle Audit Vault Server. If you want to run reports, or use tables for any other activity in the database, you can restore the tablespaces.

The appliance (Oracle Audit Vault and Database Firewall) manages expired event data. Management involves all the tasks from creating, archiving, and deleting the tablespaces, based on the retention policy defined. However, you must manually archive the data.

The ILM component has a built in health check package. To check the current status of the component, execute the following command:

SQL> exec avsys.ilmcheck.run('check_all')

A log file with a name ilmcheck.log is generated under the file path $ORACLE_HOME/av/log.

To check more options with this health check component, run the following command:

SQL> set serveroutput on; exec avsys.ilmcheck.run('help');

1.3.2.4 About Audit Vault Agent

Audit Vault Agent retrieves audit trails from various types of secured targets and sends the audit data to Oracle Audit Vault Server.

Secured targets can be either an Oracle Database, or other databases, operating systems, file systems, directory services, or custom audit data in either database tables or XML files.

Audit Vault Agent is deployed on a host. Usually the host is the same host running the audit data source (secured target), such as a database, or an operating system. However, you can also deploy the agent on a remote host. Hosts are registered in the Oracle Audit Vault Server. Each audit data source has an associated secured target, and one or more audit trails defined in Oracle Audit Vault Server for the secured target.

1.3.2.5 About Oracle Database Firewall

The Oracle Database Firewall component of Oracle Audit Vault and Database Firewall monitors databases, access activity events, and acts as a first line of defense on the network.

You can deploy Oracle Database Firewall using two different methods:

1. Monitoring only
2. Monitoring and blocking

Oracle Database Firewall monitors databases, and provides a complete event repository of significant database access activity events, as defined by an Oracle Audit Vault and Database Firewall policy. Oracle Database Firewall also acts as a first line of defense on the network by enforcing expected database access behavior, thereby helping to prevent SQL injection, application bypass, and other malicious activity from reaching the database.

Oracle Database Firewall uses a highly accurate SQL grammar-based engine to monitor all SQL traffic, and to block unauthorized SQL traffic. By parsing the SQL, Oracle Audit Vault and Database Firewall can recognize the multiple number of ways to express the different equivalent SQL statements, so that you can properly decide whether to allow these statements. In contrast, naive filtering that is based on regular expressions usually recognizes only a subset of equivalent statements.

Unlike solutions that leverage regular expressions, Oracle Database Firewall parses the SQL itself to achieve the level of accuracy required for enterprise database monitoring. Oracle Database Firewall collects SQL requests from the network. SQL statements are then associated with as much session information as possible (for example, database user name, client program name, or client IP address). This information is then combined with further analysis of SQL statements, including SQL category, such as SELECT statements, Oracle Definition Language (DDL) and Data Manipulation Language (DML) writes, Tool Command Language (TCL), and so on.

Oracle Database Firewall analyzes the SQL statements in accordance with the firewall policy. Oracle Database Firewall groups SQL statements into clusters, which are SQL statements with the same grammatical structure. This enables the distillation of hundreds of millions of SQL statements down to just a few hundred. Oracle Audit Vault and Database Firewall lets you define firewall policies that include both allowed SQL (allowlist), and disallowed SQL (blocklist). In this way, Oracle Database Firewall distinguishes normal transactions from abnormal transactions.

To ensure flexibility in the choice of the network point at which the traffic is monitored, Oracle Database Firewall also supports a monitor-only agent that is local to the database server. Host Monitor, which is part of the Audit Vault Agent, captures SQL traffic reaching the database server, and securely forwards it to Oracle Database Firewall. You can use Host Monitor to remotely monitor database servers running on Linux, Oracle Solaris, and Microsoft Windows platforms. To use Oracle Database Firewall Host Monitor, deploy the Audit Vault Agent. Note that Host Monitor does not perform the blocking.

1.3.2.6 Oracle Audit Vault and Database Firewall Components Working Together

Oracle Audit Vault and Database Firewall components work together to protect a secured target, and collect the appropriate audit trail from that secured target.

The Oracle Audit Vault and Database Firewall architecture provides a high-level overview of how the Oracle Audit Vault and Database Firewall components work together. Though this diagram shows both a database firewall and Audit Vault Agents, you can deploy Oracle Audit Vault Server with both components, or only the Audit Vault Agent component, or only the database firewall component.

Oracle Audit Vault and Database Firewall components work together in this way:

• An Audit Vault Server is deployed for every Oracle Audit Vault and Database Firewall installation. You can configure multiple secured targets. such as a heterogeneous set of databases, operating systems, file systems, or custom audit logs. For each secured target, you must deploy the Audit Vault Agent component. If the secured target is a database, then the database firewall can also be placed in the network, and configured to protect that secured target. If you want to collect audit data from the secured target, then you must deploy the Audit Vault Agent on the host.
• If the Audit Vault Agent is deployed, Oracle Audit Vault and Database Firewall is configured to collect the appropriate audit trail from the secured target. If the Database Firewall is deployed to protect a database, a firewall policy is applied for that database secured target by configuring an enforcement point. An enforcement point is a connection point between a secured target and the Database Firewall. Enforcement point can be used for monitoring the database activity and take action on the incoming SQL in some configuration types.
• The Audit Vault Agent component retrieves the audit data from secured targets and sends this data to Audit Vault Server.
• The database firewall component monitors SQL traffic to database secured targets, creates traffic logs, and takes actions according to a firewall policy. You can design the firewall policy to monitor and raise warnings only, or to block SQL traffic, and optionally substitute harmless statements in place of the blocked ones. The database firewall sends traffic logs to the Audit Vault Server component.
• Audit Vault Server stores the Oracle Audit Vault and Database Firewall configuration data, the collected audit data, and Database Firewall event data in its internal repository. An auditor can then generate and customize reports, as well as configure email notifications and system audit log (syslog) messages on Audit Vault Server.

1.3.2.7 Oracle Audit Vault and Database Firewall Network Topology

The Oracle Audit Vault and Database Firewall network topology differs depending on the size of your deployment, your high availability configuration, and optional integration with other systems.

The following illustration is a simplified illustration of Audit Vault Server with both database firewall and Audit Vault Agent components deployed. There are several ways to deploy the database firewall component on the network.

Figure 1-5 Illustration of Oracle Audit Vault and Database Firewall on the Network (Simplified)

Description of "Figure 1-5 Illustration of Oracle Audit Vault and Database Firewall on the Network (Simplified)"

In this illustration, to obtain high availability, two Audit Vault Servers and two database firewalls are deployed. You can pair database firewalls, pair Audit Vault Servers, or pair both database firewalls and Audit Vault Servers.

1.3.3 Roles and User Accounts in Oracle Audit Vault and Database Firewall

Oracle Audit Vault and Database Firewall offers multiple roles as part of the separation of duties.

The following table shows the user accounts in Oracle Audit Vault and Database Firewall.

Table 1-1 Oracle Audit Vault and Database Firewall User Accounts

Account	Description
Super Administrator	Super administrators configure and maintain the Oracle Audit Vault and Database Firewall system, including Audit Vault Server settings such as network settings, high availability, data retention policies, etc. The super administrator can create other administrators or super administrators, and has access to all secured targets. The super administrator can also grant access to specific secured targets to other administrators.
Administrator	The administrator can perform a subset of the system configuration tasks that a super administrator can, such as registering hosts and secured targets, running archive jobs, etc. Administrators can also manage secured targets for which they have been granted access by a super administrator. An administrator cannot create another administrator. This can be performed by a super administrator only.
Database Firewall Administrator	The Database Firewall Administrator user can access the administrative interface on the Database Firewall Appliance. This user can configure the Database Firewall component's system and network settings, traffic sources, and view diagnostics information.
Super Auditor	The Super Auditor user can create firewall policies, provision audit policies for Oracle Database secured targets, and specify settings for secured targets. For example, the Super Auditor user can create a policy that determines whether to enable stored procedure auditing. Super Auditor users also generate reports, and create alerts and notifications. Super Auditor users can access all secured targets, create auditor or super auditor users, and grant access to specific secured targets to those users.
Auditor	Auditor users can perform all the functions of Super Auditor users, but only for the secured targets to which they have access.
root	Operating system Super User (root) account. Only use this account as instructed in the documentation, or under the guidance of Oracle Support. This account is typically used for upgrades and patching.
Support	The Support user account should only be used under the guidance of Oracle Support. This account is typically used to log in, using SSH.

Note:

• To provide greater security, the Oracle Audit Vault and Database Firewall Administrator and Auditor roles have different user interfaces, and different user accounts. This separation of roles ensures that there is a separation of duties between these two roles.
• In addition to the Oracle Audit Vault and Database Firewall administrative role user accounts, set up user accounts on your secured targets as necessary for Oracle Audit Vault and Database Firewall to access these targets for collecting audit data. Oracle Audit Vault and Database Firewall provides scripts to set up these user accounts on database secured targets, as well as guidance for other types of secured targets.

1.3.4 Integrating Other Systems with Oracle AVDF

Topics:

• Integrating Oracle AVDF with F5 BIG-IP ASM

• Integrating Syslog With a SIEM System

1.3.4.1 Integrating Oracle AVDF with F5 BIG-IP ASM

Oracle Audit Vault and Database Firewall (Oracle AVDF) supports integrating BIG-IP Application Security Manager (ASM).

Note:

• This functionality is only supported on F5 BIG-IP ASM version 10.2.1.

• F5 BIG-IP ASM integration is deprecated in release 12.2.0.7.0, and can be desupported in a future release.

BIG-IP Application Security Manager (ASM), from F5 Networks, Inc., is a web application firewall (WAF) that provides protection against web-based attacks. BIG-IP ASM is deployed between web clients and the web application server. It analyzes each HTTP and HTTPS request, and blocks potential attacks before they reach the Web application server. Refer to the following figure for details:

Figure 1-6 Oracle AVDF with F5 BIG-IP ASM Data Flow Unit

Description of "Figure 1-6 Oracle AVDF with F5 BIG-IP ASM Data Flow Unit"

Oracle Database Firewall is deployed between the web application server and the database. It provides protection against attacks originating from inside or outside the network. It works by analyzing the intent of the SQL statements sent to the database.

A deployment that includes both BIG-IP ASM and Oracle Database Firewall provides the functionality of both products, and enables the two systems to work in partnership.

A key benefit of the integration is that it allows BIG-IP ASM to pass to Oracle Database Firewall additional information about the SQL statements sent to the database, including the web user name, and the IP address of the web user who originated them. This information is not usually available from the SQL statements generated by the web application server.

1.3.4.2 Integrating Syslog With a SIEM System

Learn how to integrate Oracle Audit Vault and Database Firewall System Logging Protocol logs (syslog) with a Security Information and Event Management (SIEM) system.

You can configure syslog message destinations in Oracle Audit Vault Server. If you use a SIEM system, then you can configure it to receive the required information from syslog. The syslog messages that you can integrate with a SEIM system are:

• Alert - alert messages raised by Oracle Database Firewall policies, and user-configured alerts

• System - syslog messages from subcomponents of the Oracle Audit Vault Server and Oracle Database Firewall

• Info - specific change logging from Oracle Database Firewall

• Debug - a category that should only be used under the direction of Oracle Support

Oracle Audit Vault and Database Firewall has an integration with HP ArcSight SIEM. You can configure this integration in Oracle Audit Vault Server to send these types of syslog messages for Oracle Database Firewall events directly to HP ArcSight.

Note:

Micro Focus ArcSight SIEM (previously known as HP ArcSight SIEM) is deprecated in 12.2.0.8.0, and is desupported in 12.2.0.9.0. Use the syslog integration feature instead.

1.4 Understanding the Software Appliance Model

With the software appliance model, your hardware is dedicated to Oracle Audit Vault Server or to the Oracle Audit Vault and Database Firewall software firewall (the Database Firewall).

Both Oracle Audit Vault Server and the Database Firewall are software appliances. Unlike a hardware appliance, a software appliance uses your own industry-standard hardware. The software appliance includes the operating system, repository, and application. This system is preconfigured for you, and hardened to meet the requirements of Oracle Audit Vault and Database Firewall. Therefore, you do not need to change these settings, because the entire appliance is highly tuned. With this software appliance model, your hardware is dedicated to Oracle Audit Vault Server or to the Database Firewall software, both of which include an Oracle Linux operating system, Oracle Database, and the Oracle Audit Vault and Database Firewall software.

In addition to the benefits that Oracle Audit Vault and Database Firewall software provides, the appliance model provides these additional benefits:

• Time (cost) saving on the configuration of components, the appliance comes with an operating system, database, and middleware pre-configured for optimal operation of Oracle Audit Vault and Database Firewall application software
• Implicit upgrading and patching. With the appliance deployment, there is no need for separate patching of the operating system, database or application. All component updates are delivered as bundle patches that are installed in a single, simple procedure.
• Improved reliability and support responsiveness due to restricting scenarios to particular combination of the operating system, database, and application.

In contrast to a hardware appliance model, the software appliance model provides the flexibility to choose hardware sizing to accommodate your needs.

This software model also provides easy patching and upgrading, which includes all components. Therefore, you do not need to install or patch components such as the operating system or repository separately.

You must not make any changes to the Linux operating system, or Oracle Audit Vault Server repository through the command line on these servers, unless you are following official Oracle documentation, or are under guidance from Oracle Support.

See Also:

Oracle Audit Vault and Database Firewall Installation Guide for information on specific hardware required.

1.5 Oracle Audit Vault and Database Firewall and Oracle Enterprise Manager

You can monitor the components of Oracle Audit Vault and Database Firewall using a plug-in to Enterprise Manager.

If you have Oracle Enterprise Manager Cloud Control 12c Release 2 (12.1.0.3.0) or higher, you can install the Oracle Audit Vault and Database Firewall plug-in to the Enterprise Manager (EM) to monitor Oracle Audit Vault and Database Firewall through the EM. This plug-in provides an interface within Enterprise Manager Cloud Control for administrators to manage and monitor Oracle Audit Vault and Database Firewall components.

Figure 1-7 Oracle Audit Vault and Database Firewall Plug-in for Oracle Enterprise Manager Cloud Control

Description of "Figure 1-7 Oracle Audit Vault and Database Firewall Plug-in for Oracle Enterprise Manager Cloud Control"

The Oracle Audit Vault and Database Firewall plug-in gives you a summary view, and lets you monitor:

• Audit Vault Agents

• Database Firewalls

• Targets

• Audit trails

• Enforcement points

• High availability information

• Auditor activity notifications

• Incidents and problems

1.6 Planning an Oracle Audit Vault and Database Firewall Deployment

To deploy Oracle Audit Vault and Database Firewall, you must prepare the server, plan the Oracle Audit Vault Server deployment, and plan the Oracle Database Firewall deployment.

Planning your Oracle Audit Vault and Database Firewall deployment includes planning Oracle Audit Vault Server deployment and deciding whether you will deploy the Audit Vault Agent, Oracle Database Firewall, or both. In addition, depending on which components you are deploying, you must gather some key information.

1.7 Support Policy When Third Party Software is Installed on Oracle AVDF

Oracle Audit Vault and Database Firewall (Oracle AVDF) is shipped as an appliance, and no third-party software should be installed on the Audit Vault Server. Oracle does not test or certify any third party software on Oracle AVDF. If third party software is installed, and results in problems with the Audit Vault Server and/or Database Firewall, then Oracle may not be able to help you recover the system. In cases where we believe the third party software has contributed to an issue, we may ask you to reproduce the issue on an Oracle AVDF system that does not include the third-party software.

During patching or upgrade of Oracle AVDF, you may find that the presence of third party software contributes to difficulties in completing the operation. You may also find that the process of patching/upgrading Oracle AVDF causes third party software to malfunction or cease to work altogether. Oracle AVDF upgrades also update the underlying operating system and may remove any custom libraries added by third party software.

Audit data is particularly sensitive, and loss of an audit data may result in inability to support compliance reporting and forensic investigations. In the event that you choose to install third party software on Oracle AVDF, then Oracle recommends you take additional appropriate precautions such as more frequent backups that may reduce the damage in the event the third-party software causes system instability or corruption.