Learn about Oracle Audit Vault and Database Firewall software (Oracle AVDF), and about collection plug-ins.
Learn about Oracle Audit Vault and Database Firewall components, and what each component does.
Oracle Audit Vault and Database Firewall is a software system that collects, consolidates, protects, and analyzes audit data from multiple, distributed, heterogeneous systems. It is comprised of these components:
Oracle Audit Vault Server: A server that contains an embedded Oracle Database and other software components that manage the activities of Oracle Audit Vault and Database Firewall.
Oracle Audit Vault Agent: A Java component that runs on a remote host and manages the collection of audit information based on commands from the Audit Vault server. The agent interfaces with the collection plug-ins under its control to gather audit records and sends it to the Audit Vault Server.
Oracle Database Firewall: The Database Firewall is a dedicated server that runs the Database Firewall software. Each Database Firewall monitors SQL traffic on the network from database clients to secured target databases. The Database Firewall then sends the SQL data to the Audit Vault Server to be analyzed in reports.
Oracle Audit Vault and Database Firewall ships with several prepackaged collection plug-ins, which are software programs that know how to access and interpret audit data from secured target systems of various types. Collection plug-ins collect audit data from an audit trail generated by a secured target system and store it in an Audit Vault Server repository. Each collection plug-in is specific to a particular type of trail from a particular type of secured target. These collection plug-ins collect data from databases such as Oracle, SQL Server, Sybase ASE, and DB2.
Parent topic: Introduction to Oracle Audit Vault and Database Firewall
Audit Collection Plug-ins retrieve audit data in the form of audit trails, which are sequences of audit records. Audit trails are generated by different secured target types such as database tables or XML audit records.
A secured target can write one or more audit trails; each audit trail is stored in a separate location, and can have its own format.
To elaborate a little on these terms:
Secured Target
A secured target is a software or hardware system performing a specific function. As part of performing that function, the secured target system generates an audit trail. A secured target is an instance of a secured target type and has specific properties such as connection credentials and trail types.
Secured Target Type
A secured target type represents a collection of a particular type of secured target that generates the same type of audit data. Oracle Database, for example, is a secured target type which can have many instances. However, all Oracle Databases generate the same audit data and record the same fields.
Audit Trail
An Audit Trail identifies a location and format where audit data resides. Each audit trail is generated by one and only one secured target. Examples of audit trails are:
For secured targets that write data into files, the trail is the directory path plus the file mask.
For secured targets that write audit data into a database table, the name of the table is the trail for that secured target. SYS.AUD$
is an example of a database table audit trail in an Oracle database.
Parent topic: What Is Oracle Audit Vault and Database Firewall?
To retrieve audit data stored in audit trails, you can build custom audit collection plug-ins.
A collection plug-in provides functionality similar to the prepackaged collection plug-ins shipped with Oracle Audit Vault and Database Firewall, by retrieving audit data stored in audit trails.
Oracle Audit Vault and Database Firewall allows developers and third-party vendors to build custom collection plug-ins. These custom plug-ins are:
New to Oracle Audit Vault and Database Firewall.
Capable of collecting audit data from a new secured target type.
You can write collection plug-ins that collect audit trails stored in database tables and XML files, or that are are accessible in another way.
You can support secured targets, such as relational databases, operating systems, mid-tier systems, or enterprise applications.
To obtain more individualized audit data, you can create custom collection plug-ins, and deploy them into existing Oracle Audit Vault and Database Firewall installations.
Related Topics
Parent topic: Introduction to Oracle Audit Vault and Database Firewall
You can create two types of collection plug-ins. The actual type you need to create depends on the properties of the audit trail being collected.
A collection plug-in uses an XML file, called a mapper file, which you create, to describe the audit data being collected. Audit Vault Server uses this file to access and interpret the audit records being collected. You do not need to write code for this type of plug-in.
There is also Java-based type of collection plug-in, which uses a Java API. You can design one or use one that is prepackaged with Audit Vault and Database Firewall.
Parent topic: What Are Audit Collection Plug-ins?
This section describes the two types of collection plug-ins and explains the properties that are required to use each type.
You can easily define a mapper file (template) and a collection plug-in if the audit trails you wish to collect are stored in either of the following:
Database Tables: Stored in database tables that conform to specific constraints
XML Files: Stored in XML files based on the Audit Vault XML Audit File format
You write Java-based collection plug-ins in Java code when the audit trail you need to collect is not in a format that a Collection plug-in can easily read.
Using the Java API provided, you can write code to collect these more complex audit trails and send them to the Audit Vault Server repository.
Parent topic: Types of Audit Collection Plug-ins
Learn about Oracle Audit Vault and Database Firewall server events, server fields, and audit records.
Monitoring the activity, the stream of events, that occur in a secured target system is the essence of Oracle Audit Vault and Database Firewall. These events are described by fields. A collection of fields describing a single event that occurred on the secured target system is an audit record.
The following applies for Oracle Audit Vault and Database Firewall:
Each secured target logs events as audit events that occur on that secured target. Audit records capture information about audit events.
Audit records typically have a secured target type event name that describes what happened to what type of object. They also contain the target of the action that happened. In addition, they must contain a time when the action occurred, the subject, or actor, who caused the action to happen, and may also contain additional data.
Audit Vault Server organizes the fields of an audit record into these groups: core fields, extension fields, large fields, and marker fields.
Parent topic: Introduction to Oracle Audit Vault and Database Firewall
Core fields are the fundamental fields that describe an event, and most audit records contain some or all of these fields. However, not all core fields are required in every audit record.
Starting with Oracle Audit Vault and Database Firewall release 12.1.1, the core fields which describe the actions occurred are:
CommandClass
field: The action that caused the audit record to be generated.
UserName
and OsUserName
fields: The subject or user who performed the action.
EventTime
field: When, what time, the action occurred.
ClientHostName
, ClientIp
, and other related fields: Where, the location, of the action.
Target
Type
, Target
Owner
, and Target
Object
fields: The object type, object owner, or target of the action.
See Also:
Core Fields for a complete list of core fields.
Parent topic: Oracle Audit Vault Events and Fields
The CommandClass
and Target
Type
fields have well-known values, which cover a set of general-purpose events that occur in secured targets belonging to various domains, such as databases or operating systems.
Examples of CommandClass
es are Logon
, Select
, Update
, and Shutdown
.
These are listed in Audit Vault Server Fields, Actions and Target Types.
Parent topic: Core Fields
In addition to core fields, Audit Vault Server understands these categories:
Large fields are fields that contain arbitrarily large amount of data.
See Also:
Parent topic: Other Audit Vault Fields
The Extension field provides a way to make available secured target fields that do not have a semantically equivalent Audit Vault field and do not map to Core or Large fields.
The developer determines the format used to store the fields.
See Also:
Parent topic: Other Audit Vault Fields
The Marker field is a unique identifier of a record in a trail. It is constructed out of one or more fields in an audit record.
See Also:
Parent topic: Other Audit Vault Fields
As a plug-in developer, you must map the various events that occur within secured targets, and their fields, to the various fields allowed by Audit Vault.
If a field in the audit record maps to one of the named fields (core, large, or marker fields) in Audit Vault, you should map it as such.
If a field in the audit record does not map to one of the named fields, you can map it to an extension field of your choosing.
For the Action
and TargetType
Audit Vault Server fields, see the list of field values. If your audit record maps to one of these values semantically, we strongly encourage you to use that value. You are, however, free to use values not listed in the appendix.
You are strongly encouraged to follow these basic guidelines when you store values in Audit Vault.
Do not store IDs that reference objects in the secured target database. Audit Vault does not have access to these objects, and the stored values will be meaningless. Store literal names of objects instead, so they can be understood by the auditors,
Follow defined Audit Vault conventions. For example, all the ACTION
fields and TARGET TYPE
fields in Audit Vault have uppercase values. Please follow this convention, unless this is not applicable to your secured target type, and would cause the data stored in Audit Vault to be interpreted incorrectly.
Map to the values if possible. For example, if TABLE
exists in the list as a Target
Type
, do not add an audit record with the Target
Type
of DATABASE
TABLE
.
Finally, if a field in the audit record of a secured target merits becoming a core field, please contact Oracle so that it can be added to the model appropriately.
See Also:
Parent topic: Oracle Audit Vault Events and Fields
Learn how the Oracle Audit Vault collection process works.
Parent topic: Introduction to Oracle Audit Vault and Database Firewall
You, the developer, create a collection plug-in and provide it to the user.
The user deploys the plug-in into the Audit Vault Server. The act of deploying a plug-in into the server creates a new version of the Audit Vault Agent. This new agent contains collector code from the collection plug-in.
The user then deploys the new Agent onto the host where it needs to run.
From then on, the user can start collecting audit trails supported by the collector code.
User starts collecting audit trails supported by the collector code.
The next section describes what happens inside the collection plug-in after the user starts collection.
Parent topic: The Collection Process
After you develop a collection plug-in for Oracle Audit Vault and Database Firewall, the collection plug-in follow this flow as it collects audit trails.
A collection plug-in accesses an audit trail, and extracts an audit record and its related fields from the audit trail. Next, it maps the audit record to an Oracle Audit Vault event, and all the fields to Oracle Audit Vault fields. The collection plug-in then passes the Oracle Audit Vault event and fields to the Audit Vault Agent, which sends the information to the Oracle Audit Vault Server.
Flow of Collection
Asks the collector for any additional audit records in the audit trail.
The collector transforms (by mapping) any further audit records into the form of audit records as specified in the mapper file, and hands them to the Collection Framework through the Collection API.
The Agent sends the checkpoint information and other metric data received from the collection plug-in to the Audit Vault Server. The Audit Vault Server stores this information in a checkpoint table.
STOP
command from the Oracle Audit Vault Server, it notifies the collector to stop sending records. It then exits the collection thread, and shuts itself down.Parent topic: The Collection Process
To use Oracle Audit Vault, review basic Oracle Audit Valut basic concepts.
Parent topic: The Collection Process
The agent starts threads of collection. Within each thread, the Audit Vault Collection Framework executes code provided by the collection plug-in. The collection Framework is the run-time infrastructure that exposes the collection API which the collection plug-in interfaces with. The collection plug-in also uses utility APIS (not shown) if it needs to.
Parent topic: Collection Concepts
During the collection phase, the collection plug-in accesses the audit trail to extract new records. The exact mechanism of how audit trails are accessed depend on the audit trail. Once a secured target audit record is retrieved from the trail, the collection plug-in must be able to transform (map) it into an audit record hat can be sent to the Audit Vault Server.
The collection plug-in must also acquire information about the character set of the secured target records, the encoding used, and issues related to the time stamps, in order to make these things coordinate with Audit Vault Server requirements.
See Also:
Parent topic: Collection Concepts
The mappings required depend on the secured target records.
These types of mapping are required:
Event Mapping: Maps a secured target-specific event to an Audit Vault Event.
Field Mapping: Maps the various field of the secured target records to Audit Vault Fields.
Value Mapping: Maps various field values collected into a set of normalized values for each field (for example, 0
and 1
may be mapped to FALSE
and TRUE
for a specific field).
Complex Mapping: Complex mappings are used when there are no simple mappings from one secured target field to an Audit Vault Field, or one secured target audit event to one Audit Vault Event.
Complex mappings may require additional data from the secured target or additional programming code in the collection plug-in.
Parent topic: Collection Concepts
A Checkpoint, or a checkpoint of a trail, is the point up to which audit records were committed to the Oracle Audit Vault Server.
The collection plug-in sets a checkpoint periodically so that it can resume from the last checkpoint when restarted.
Parent topic: Collection Concepts
Learn how Oracle Audit Vault manages recovery of audit records through checkpoints and recovery mechanisms.
You are provided a once and only once guarantee with Oracle Audit Vault that each audit record is archived in the Oracle Audit Vault Server once, and only once. For this purpose, Oracle Audit Vault implements a checkpoint and recovery mechanism.
In the recovery phase of data collection, a collection plug-in has stopped and restarted, resuming collection. The collection plug-in resumes collection from the checkpoint at which it previously stopped
If the collection plug-in has not collected any records from the audit trail, then the checkpoint occurs before the first record. If the collection plug-in has started collecting records and then stopped, then the checkpoint occurs immediately after the last record that it collected.
Resuming collection immediately after the checkpoint ensures that the collection plug-in does not miss any records. To avoid collecting duplicate records during recovery, the collection plug-in checks the Marker field of each record.
The collection plug-in should not collect and pass on to the agent any records that occurred before the last checkpoint. However, the agent automatically filters out records committed after the last checkpoint, and recollected when the collection plug-in restarts. Collection plug-ins built using this SDK write the EventTimeUTC
field into a file with the extension .atc
. A script can subsequently read this file, and delete audit records as appropriate.
Related Topics
Parent topic: Collection Concepts
Audit Trail clean-up is a feature that some secured targets provide to clean up audit records once they've been archived. If this type of feature exists in the secured target, an Audit Vault collection plug-in can integrate with it, to tell the secured target to what extent the audit trail has been archived. This enables the secured target to clean up the audit trail (remove the original audit data) to that point, knowing this will not result in loss of data. The collection plug-in gives the clean-up utility information about the checkpoint, the point up to which data has been collected.
The collection plug-in can notify the clean-up feature of the secured target system by invoking the appropriate interface of the feature. For instance, the system may read a timestamp from a file in the file system and clean up the audit trail up to that timestamp. If that is the case, the plug-in can write that file periodically.
For example, Oracle Database secured targets provides this type of utility in the DMBS_AUDIT_MGMT
package, and the Oracle Database prepackaged collection plug-ins integrate with it.
Parent topic: Collection Concepts
The general procedure for writing collection plug-ins is:
Parent topic: Introduction to Oracle Audit Vault and Database Firewall