Parameter

Value

Meaning

DB

Enables database auditing and directs all audit records to the database audit trail (SYS.AUD$),
except for records that are always written to the operating system audit trail
DB,EXTENDED
Does all actions of AUDIT_TRAIL=DB and also populates the SQL bind and SQL text columns
of the SYS.AUD$ table
XML
Enables database auditing and directs all audit records in XML format to an operating system
file
XML,EXTENDED
Does all actions of AUDIT_TRAIL=XML, adding the SQL bind and SQL text columns
OS (recommended) Enables database auditing and directs all audit records to an operating system file

In addition, the following database parameters should be set:

init.ora parameter: AUDIT_FILE_DEST Dynamic parameter specifying the location of the operating system audit
trail. The default location on Unix/Linux is $ORACLE_BASE/admin/$ORACLE_SID/adump. The default on
Windows is the event log. For optimal performance, it should refer to a directory on a disk that is locally attached to
the host running the Oracle instance.
init.ora parameter: AUDIT_SYS_OPERATIONS Enables the auditing of operations issued by user SYS, and
users connecting with SYSDBA, SYSOPER, SYSASM, SYSBACKUP, SYSKM and SYSDG privileges. The audit
trail data is written to the operating system audit trail. This parameter should be set to true.

Using Default Auditing for Security-Relevant SQL

Statements and Privileges
When you use Database Configuration Assistant (DBCA) to create a new database, Oracle
Database configures the database to audit the most commonly used security-relevant SQL
statements and privileges. It also sets the AUDIT_TRAIL initialization parameter to DB. If you decide
to use a different audit trail type (for example, OS if you want to write the audit trail records to
operating system files), then you can do that: Oracle Database continues to audit the privileges that
are audited by default. If you disable auditing by setting the AUDIT_TRAIL parameter to NONE, then
no auditing takes place.
Oracle Database audits the following privileges by default:
ALTER ANY
PROCEDURE

CREATE ANY LIBRARY

DROP ANY TABLE

ALTER ANY
TABLE

CREATE ANY PROCEDURE

DROP PROFILE

ALTER
DATABASE

CREATE ANY TABLE

DROP USER

ALTER PROFILE CREATE EXTERNAL JOB

EXEMPT ACCESS POLICY

ALTER SYSTEM

CREATE PUBLIC DATABASE LINK GRANT ANY OBJECT PRIVILEGE

ALTER USER

CREATE SESSION

GRANT ANY PRIVILEGE

AUDIT SYSTEM

CREATE USER

GRANT ANY ROLE

CREATE ANY
JOB

DROP ANY PROCEDURE

uditing in Oracle
Auditing in Oracle
The auditing mechanism for Oracle is extremely flexible. Oracle stores information that is
relevant to auditing in its data dictionary.
Every time a user attempts anything in the database where audit is enabled the Oracle
kernel checks to see if an audit record should be created or updated (in the case or a
session record) and generates the record in a table owned by the SYS user called AUD$.
This table is, by default, located in the SYSTEM tablespace. This itself can cause problems
with potential denial of service attacks. If the SYSTEM tablespace fills up, the database will
hang.

init parameters

Until Oracle 10g, auditing is disabled by default, but can be enabled by setting the
AUDIT_TRAIL static parameter in the init.ora file.
From Oracle 11g, auditing is enabled for some system level privileges.
SQL> show parameter audit

NAME
---------------------audit_file_dest
audit_sys_operations
audit_syslog_level
audit_trail
transaction_auditing

TYPE
VALUE
------------ ------------string
?/rdbms/audit
boolean
FALSE
string
NONE
string
DB
boolean
TRUE

AUDIT_TRAIL can have the following values.

AUDIT_TRAIL={NONE or FALSE| OS| DB or TRUE| DB_EXTENDED| XML |
XML_EXTENDED}

Prints

Enterprise rent a truck

Catalogs

Setting The
Serial Number
Examples
Values

The following list provides a description of each value:

NONE or FALSE -> Auditing is disabled. Default until Oracle 10g.

DB or TRUE -> Auditing is enabled, with all audit records stored in

the database audit trial (AUD$). Default from Oracle 11g.

DB_EXTENDED > Same as DB, but the SQL_BIND and SQL_TEXT columns are also
populated.

XML-> Auditing is enabled, with all audit records stored as XML format OS files.

XML_EXTENDED > Same as XML, but the SQL_BIND and SQL_TEXT columns are
also populated.

OS -> Auditing is enabled, with all audit records directed to the operating system's
file specified by AUDIT_FILE_DEST.
Note: In Oracle 10g Release 1, DB_EXTENDED was used in place of "DB,EXTENDED". The
XML options were brought inOracle 10g Release 2.
The AUDIT_FILE_DEST parameter specifies the OS directory used for the audit trail when
the OS, XML and XML_EXTENDED options are used. It is also the location for all mandatory
auditing specified by the AUDIT_SYS_OPERATIONS parameter.
The AUDIT_SYS_OPERATIONS static parameter enables or disables the auditing of
operations issued by users connecting with SYSDBA or SYSOPER privileges, including the
SYS user. All audit records are written to the OS audit trail.
Run the $ORACLE_HOME/rdbms/admin/cataudit.sql script while connected as SYS (no need
to run this, if you ran catalog.sql at the time of database creation).

Start Auditing
Syntax of audit command:
audit {statement_option|privilege_option} [by user] [by {session|access}]
[whenever {successful|not successful}]

Business internet connection

English dictionary online

Trial

Prints

Enterprise rent a truck

Catalogs
Only the statement_option or privilege_option part is mandatory. The other clauses are
optional and enabling them allows audit be more specific.
There are three levels that can be audited:
Statement level
Auditing will be done at statement level.

Statements that can be audited are found in STMT_AUDIT_OPTION_MAP.

SQL> audit table by scott;
Audit records can be found in DBA_STMT_AUDIT_OPTS.
SQL> select * from DBA_STMT_AUDIT_OPTS;
Object level
Auditing will be done at object level.
These objects can be audited: tables, views, sequences, packages, stored procedures and
stored functions.
SQL> audit insert, update, delete on scott.emp by hr;
Audit records can be found in DBA_OBJ_AUDIT_OPTS.
SQL> select * from DBA_OBJ_AUDIT_OPTS;
Privilege level
Auditing will be done at privilege level.
All system privileges that are found in SYSTEM_PRIVILEGE_MAP can be audited.
SQL> audit create tablespace, alter tablespace by all;
Specify ALL PRIVILEGES to audit all system privileges.
Audit records can be found in DBA_PRIV_AUDIT_OPTS.
SQL> select * from DBA_PRIV_AUDIT_OPTS;

Audit options

BY SESSION
Specify BY SESSION if you want Oracle to write a single record for all SQL statements of the
same type issued and operations of the same type executed on the same schema objects in
the same session.
Oracle database can write to an operating system audit file but cannot read it to detect
whether an entry has already been written for a particular operation. Therefore, if you are
using an operating system file for the audit trail (that is, the
AUDIT_TRAIL initialization parameter is set to OS), then the database may write multiple
records to the audit trail file even if you specify BY SESSION.
SQL> audit create, alter, drop on currency by xe by session;
SQL> audit alter materialized view by session;
BY ACCESS
Specify BY ACCESS if you want Oracle database to write one record for each audited
statement and operation.
If you specify statement options or system privileges that audit data definition language
(DDL) statements, then thedatabase automatically audits by access regardless of whether
you specify the BY SESSION clause or BY ACCESS clause.
For statement options and system privileges that audit SQL statements other than DDL, you
can specify either BY SESSION or BY ACCESS. BY SESSION is the default.
SQL> audit update on health by access;
SQL> audit alter sequence by tester by access;
WHENEVER [NOT] SUCCESSFUL

Specify WHENEVER SUCCESSFUL to audit only SQL statements and operations that succeed.
Specify WHENEVER NOT SUCCESSFUL to audit only SQL statements and operations that fail
or result in errors.
If you omit this clause, then Oracle Database performs the audit regardless of success or
failure.
SQL> audit insert, update, delete on hr.emp by hr by session whenever not successful;
SQL> audit materialized view by pingme by access whenever successful;

Examples

Auditing for every SQL statement related to roles (create, alter, drop or set a role).
SQL> AUDIT ROLE;
Auditing for every statement that reads files from database directory
SQL> AUDIT READ ON DIRECTORY ext_dir;
Auditing for every statement that performs any operation on the sequence
SQL> AUDIT ALL ON hr.emp_seq;
select userid, returncode from sys.aud$;

select userid, returncode from sys.aud$;

SELECT * FROM ALL_DEF_AUDIT_OPTS;
ELECT * FROM DBA_STMT_AUDIT_OPTS;
SELECT * FROM dba_audit_mgmt_config_params;
SELECT * FROM DBA_PRIV_AUDIT_OPTS;
SELECT * FROM DBA_OBJ_AUDIT_OPTS
WHERE OWNER = 'JEFF' AND OBJECT_NAME LIKE 'EMP%';
select statementid,entryid,username,action_name,returncode,owner,
obj_name,substr(priv_used,1,8) priv, SES_ACTIONS
from dba_audit_trail
order by sessionid,entryid;
SELECT *
FROM
dba_audit_mgmt_config_params
WHERE parameter_name LIKE 'AUDIT FILE MAX%';
COLUMN username FORMAT A8
COLUMN obj_name FORMAT A10

COLUMN action_name FORMAT A12

COLUMN sql_text FORMAT A37
SELECT username,obj_name,action_name, sql_text
FROM
dba_audit_trail
WHERE username = 'SCOTT'
ORDER BY timestamp;
select

input_type,
status,
to_char(end_time,'yyyy-mm-dd hh24:mi')
output_bytes_display
from v$rman_backup_job_details
order by session_key desc;

end_time,

SELECT USERNAME, SQL_TEXT, TIMESTAMP

FROM DBA_AUDIT_TRAIL
WHERE SQL_TEXT LIKE 'SELECT %';

View Audit Trail

The audit trail is stored in the base table SYS.AUD$.

It's contents can be viewed in the following views:
DBA_AUDIT_TRAIL
DBA_OBJ_AUDIT_OPTS
DBA_PRIV_AUDIT_OPTS
DBA_STMT_AUDIT_OPTS
DBA_AUDIT_EXISTS
DBA_AUDIT_OBJECT
DBA_AUDIT_SESSION
DBA_AUDIT_STATEMENT
AUDIT_ACTIONS
DBA_AUDIT_POLICIES
DBA_AUDIT_POLICY_COLUMNS
DBA_COMMON_AUDIT_TRAIL
DBA_FGA_AUDIT_TRAIL (FGA_LOG$)
DBA_REPAUDIT_ATTRIBUTE
DBA_REPAUDIT_COLUMN
The audit trail contains lots of data, but the following are most likely to be of interest:
Username - Oracle Username.
Terminal - Machine that the user performed the action from.
Timestamp - When the action occurred.

Object Owner - The owner of the object that was interacted with.
Object Name - name of the object that was interacted with.
Action Name - The action that occurred against the object (INSERT, UPDATE, DELETE,
SELECT, EXECUTE)
Fine Grained Auditing (FGA), introduced in Oracle9i, allowed recording of row-level changes
along with SCN numbers to reconstruct the old data, but they work for select statements
only, not for DML such as update, insert, and delete.
From Oracle 10g, FGA supports DML statements in addition to selects.
Several fields have been added to both the standard and fine-grained audit trails:

EXTENDED_TIMESTAMP - A more precise value than the existing TIMESTAMP column.

PROXY_SESSIONID - Proxy session serial number when an enterprise user is logging

in via the proxy method.

GLOBAL_UID - Global Universal Identifier for an enterprise user.

INSTANCE_NUMBER - The INSTANCE_NUMBER value from the actioning instance.

OS_PROCESS - Operating system process id for the oracle process.

TRANSACTIONID - Transaction identifier for the audited transaction. This column can
be used to join to the XID column on the FLASHBACK_TRANSACTION_QUERY view.

SCN - System change number of the query. This column can be used in flashback
queries.

SQL_BIND - The values of any bind variables if any.

SQL_TEXT - The SQL statement that initiated the audit action.

The SQL_BIND and SQL_TEXT columns are only populated when the
AUDIT_TRAIL=DB_EXTENDED or AUDIT_TRAIL=XML_EXTENDED initialization parameter is
set.

Maintenance

The audit trail must be deleted/archived on a regular basis to prevent the SYS.AUD$ table
growing to an unacceptable size.
Only users who have been granted specific access to SYS.AUD$ can access the table to
select, alter or delete from it. This is usually just the user SYS or any user who has
permissions. There are two specific roles that allow access to SYS.AUD$ for select and
delete, these are DELETE_CATALOG_ROLE and SELECT_CATALOG_ROLE. These roles should
not be granted to general users.
Auditing modifications of the data in the audit trail itself can be achieved as follows
SQL> AUDIT INSERT, UPDATE, DELETE ON sys.aud$ BY ACCESS;
To delete all audit records from the audit trail:
SQL> DELETE FROM sys.aud$;
From Oracle 11g R2, we can change audit table's (SYS.AUD$ and SYS.FGA_LOG$)
tablespace and we can periodically delete the audit trail records using DBMS_AUDIT_MGMT
package.

Disabling Auditing
The NOAUDIT statement turns off the various audit options of Oracle. Use it to reset
statement, privilege and object audit options. A NOAUDIT statement that sets statement

and privilege audit options can include the BY USER option to specify a list of users to limit
the scope of the statement and privilege audit options.

SQL>
SQL>
SQL>
SQL>
SQL>
SQL>
SQL>
SQL>

NOAUDIT;
NOAUDIT session;
NOAUDIT session BY scott, hr;
NOAUDIT DELETE ON emp;
NOAUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE;
NOAUDIT ALL;
NOAUDIT ALL PRIVILEGES;
NOAUDIT ALL ON DEFAULT;

1. Log in as SYS with SYSDBA privileges

Sqlplus / as sysdba
2. Check the current settings
SQL> show parameter audit
NAME
TYPE
VALUE
---------------------- ----------- -----------------------------audit_file_dest
string
/opt/app/oracle/admin/db11/adump
audit_sys_operations boolean
FALSE
audit_syslog_level
string
audit_trail
string
DB
3. Set the type of auditing you want by setting the audit_trail parameter
SQL> alter system set audit_trail=OS scope=spfile;
System altered.
4. Set the auditing destination
SQL> alter system set audit_file_dest='/opt/app/oracle/admin/db11/adump' scope=spfile;
System altered.
5. Restart the Oracle instance

Also note that there are two additional parameters audit_sys_operations and
audit_syslog_level that you should consider setting if you are concerned about the SYS
account activity.
1. audit_sys_operations - this initialization parameter tells Oracle to turn on auditing of the
SYS connections, and users connecting with the SYSDBA or SYSOPER privilege. It has either
a TRUE or FALSE value
2. audit_syslog_level this initialization parameter enables SYS and standard OS auditing
records to be written to the system using the SYSLOG utility
Now that weve enables operating system auditing, it is always nice to see exactly what
weve accomplished. While this is not an exhaustive example, it does touch the surface of
what we are trying to accomplish here. Suppose now that we have an un-authorized access
attempt (failed login) to our database through the use of the SCOTT/TIGER account.
1. Being good DBAs weve locked this account and any attempts will be now be met with
the account is locked message:
[oracle@ludwig adump]$ sqlplus scott/tiger
SQL*Plus: Release 11.1.0.6.0 - Production on Thu Dec 10 06:51:43 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
ERROR:
ORA-28000: the account is locked
2. And now, because of auditing, this attempt will not go unnoticed and will be reported in
the audit_file_dest location:
[oracle@ludwig ~]$ cd $ORACLE_HOME/adump
[oracle@ludwig adump]$ more ora_3817.aud
Audit file /opt/app/oracle/admin/db11/adump/ora_3817.aud
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /opt/app/oracle/product/11.1.0/db_1
System name: Linux
Node name:
ludwig
Release:
2.6.18-8.el5
Version:
#1 SMP Thu Mar 15 19:57:35 EDT 2007
Machine:
i686
Instance name: db11
Redo thread mounted by this instance: 1
Oracle process number: 18
Unix process pid: 3817, image: oracle@ludwig (TNS V1-V3)
Thu Dec 10 06:48:46 2009
SESSIONID: "280057" ENTRYID: "1" STATEMENT: "1" USERID: "SCOTT" USERHOST:
"ludwig" TERMINAL: "pts/1" ACTION: "100"
RETURNCODE: "28000" COMMENT$TEXT: "Authenticated by: DATABASE" OS$USERID:
"oracle"
Now that you have the settings changed, you can start monitoring the activity on the SYS
account. Remember standard auditing can monitor and record various user database actions

such as SQL statements, privileges, schemas, objects, and network and multitier activity.
Now is the time to dig in, see how far standard auditing can take you to gain compliancy
and then fill in the gaps. The issue becomes whether you can provide auditors everything
they need to pass your audit. If you can monitor all database traffic and take appropriate
action then you will pass, otherwise you are in for a lot of work. But more on that latter.