Auditing

n todays high data transaction environments, there is always a requirement to monitor what is going on within a system. You must know more than who is connected from which host. You may need to gather statistics, monitor data access, and feed the results back to physical database design, or even observe suspicious activity. You can seamlessly migrate the accounting principle of recording every financial transaction to produce an audit trail through the database. Every database transaction is literally a transaction of some intangible value. This chapter provides a detailed exploration of Oracle8's auditing concepts and audit implementation techniques.

20
C H A P T E R

In This Chapter
Oracle8 auditing concepts Implementing auditing The Oracle8 audit trail Managing the Oracle8 audit trail Using Triggers to implement auditing

Oracle8 Auditing Concepts

Auditing is useful when appropriate, but, with all the features available with Oracle8, it is easy to get carried away. When considering a database audit, first clarify the reason or reasons for the audit in conjunction with the types of auditing facilitated by the Oracle8 server.

Why audit a database?

Auditing a database involves the recording and analysis of information, based on selected database operations executed by Users. The motives for auditing User activity fall into two main categories: 3 Monitoring errant or unauthorized User activity. Organizational data is the backbone of any company. If you modify this data or drop Tables important to the operation of internal systems, the database provides erroneous results. The database security administrator must provide solutions to such scenarios, and without a database audit trail, the root of such situations could remain a mystery.

504

Chapter 20 3 Auditing

3 Monitoring database statistics. Auditing certain database operations provides an essential understanding of how the database is used. These statistics enable database designers to enhance the databases physical design or even answer some database root causes analysis problems. The amount of information gathered from such monitoring feeds the data/information/knowledge cycle.

Auditing options offered by Oracle8

Oracle8 permits three types of auditing: statement, privilege, and Schema Object. These options provide a flexible approach to implementing any auditing scenario.

Statement auditing
See Reference Section

AUDIT

Statement auditing allows auditing of SQL statements with respect to their statements only. It offers no provision for auditing the statements underlying referenced Schema Objects. The basic syntax for this kind of auditing command follows:
AUDIT option, option, [BY Username ] [BY [ SESSION | ACCESS]] [WHENEVER [NOT] SUCCESSFUL]

Statement auditing falls into two groups of SQL statements: 1. DDL statements, with respect to specific database Schema Object types, not specifically named Objects. For example, the following audit command audits all CREATE TABLE and DROP TABLE statements.
AUDIT TABLE;

2. DML statements, with respect to a particular type of database Object operation, but not specifically an operation on a named Object. For example, the following audit option initiates audit trails for all SELECT FROM TABLE statements, irrespective of the Table on which the SQL statement executes.
AUDIT SELECT TABLE;

Statement auditing can be broad or focused in scope use statement auditing to audit activities of all Users or a selected subset of Users.

Chapter 20 3 Oracle8 Auditing Concepts

505

Privilege auditing
See Reference Section

AUDIT

Privilege auditing audits the use of system privileges such as CREATE TABLE or SELECT ANY TABLE. You can audit the use of any system privilege. The general syntax for this form of auditing follows:
AUDIT [option | ALL ] ON [Username.]Objectname [BY [SESSION|ACCESS]] [WHENEVER [NOT] SUCCESSFUL]

Privilege auditing is more focused than statement auditing because each option audits only specific types of system privilege statements, not a related set of statements. For example, the statement audit option AUDIT TABLE audits the CREATE TABLE, DROP TABLE, and ALTER TABLE SQL statements, while the privilege audit option CREATE TABLE only audits CREATE TABLE SQL statements. The privilege audit option for monitoring the creation of all Tables follows:
AUDIT CREATE ON ALL;
Note

If similar statement and privilege audit options are set for example, the AUDIT TABLE statement audit option and the CREATE TABLE privilege audit option only a single record is generated. You can set privilege auditing to audit system privilege activities of a selected User or all Users of a database.

Schema Object auditing

See Reference Section

AUDIT

Schema Object auditing audits specific DML statements (including queries) and GRANT and REVOKE statements on a specified Schema Object. You can audit SQL statements that reference the following Schema Object types: Tables, views, sequences, stored Procedures, functions, and Packages. Schema Object auditing follows the preceding statement auditing syntax:
AUDIT [option | ALL ] ON [Username.]Objectname [BY [SESSION|ACCESS]] [WHENEVER [NOT] SUCCESSFUL]

Note

The individual components within a Package cannot be audited individually they are part of a single Package Object.

506

Chapter 20 3 Auditing

The following list contains valid DML statements audited by Schema Object auditing.
ALTER COMMENT EXECUTE INDEX LOCK SELECT AUDIT DELETE GRANT INSERT RENAME UPDATE

For example, AUDIT SELECT ON Tablename audits all SQL SELECT statements executed on the specified Table. If Objects are indirectly referenced by Synonyms, clusters, or Indexes, they can be audited by setting Schema Object audit statements on their respective base Tables.
Note

If Schema Object auditing is set on a Table and its view, a SELECT operation on the view generates two audit records. Because it only audits a specific DML statement on a Schema Object, Schema Object auditing is very focused. Schema Object auditing always applies to all Users of the database.

Focusing the auditing Options

Oracle8 enables you to focus statement, privilege, and Schema Object auditing with the following methods: 3 Audit successful SQL statement executions, unsuccessful SQL statement executions, or both. 3 Audit SQL statement executions once per User session or every time the SQL statement is executed. 3 Audit the SQL activities of all Users.

Auditing successful and unsuccessful SQL execution

This type of Constraint focuses the Oracle8 auditing efforts on SQL operations that are successful, unsuccessful, or both. An unsuccessful SQL operation is a valid SQL statement that fails due to a lack of permissions to execute completely or a reference to nonexistent Schema Object. The syntax for implementing this audit focus strategy is one of the two following lines:
WHENEVER SUCCESSFUL WHENEVER NOT SUCCESSFUL

If neither line is mentioned in the audit syntax, both successful and unsuccessful SQL statements executions are audited.

Chapter 20 3 Oracle8 Auditing Concepts

507

Session and access auditing

The BY SESSION and BY ACCESS auditing type Constraints dictate when audit records should be generated. The BY SESSION Constraint setting inserts only one audit record in the audit trail for each audit option execution during the Users session.
Note

A session is the time between a User connection and disconnection with the Oracle8 database. For example, the following auditing command audits SELECT commands for the
BOOKS_LOANED Table: AUDIT SELECT ON BOOKS_LOANED BY SESSION;

User TONY connects to the database and executes five SELECT statements on the BOOKS_LOANED Table. Oracle8 generates only one audit record because you specified the BY SESSION option. The BY ACCESS Constraint setting generates an audit record into the audit trail for each audit option execution. For example, if you set BY ACCESS for the previous example, TONY generates five audit records into the audit trail. You can only set the following audit operations using the BY ACCESS audit option Constraint: 3 All statement audit options that audit DDL operations. 3 All privilege audit options that audit DDL statements. For all other audit options, BY SESSION is the default.

Auditing by User
Statement and privilege auditing options permit auditing on SQL statements issued by a specific or general User in a database. You can use the BY USER auditing Constraint to minimize the number of audit records generated. For example, use the following syntax to enforce the statement auditing option on the SELECT statement by Users TONY and KRISTY:
AUDIT SELECT TABLE by TONY, KRISTY

Schema Object auditing options cannot be constrained to specific Users.

508

Chapter 20 3 Auditing

Implementing Oracle8 Auditing

Now that I have presented the basics of Oracle8 auditing concepts, lets implement auditing in an Oracle8 database.

Enabling Oracle8 auditing

The security administrator must modify the AUDIT_TRAIL initialization parameter in the database parameter file. This modification controls whether Oracle8 generates audit records into the audit trail, regardless of whether statement, privilege, and Schema Object auditing have been defined. By default, auditing is completely disabled and the parameter set to NONE.
Note

The database security administrator can easily modify the AUDIT_TRAIL parameter using the Oracle8 Instance Manager. The following list contains valid AUDIT_TRAIL parameter values: 3 DB: Enables database auditing and directs all audit records to the database audit trail. 3 OS: Enables database auditing by directing audit records to the operating system audit trail. 3 NONE: Disables auditing (default value).

Enabling and disabling auditing options

The statement, privilege, and Schema Object auditing options can be enabled or disabled.

Enabling auditing options

Use the AUDIT command to enable statement, privilege, and Schema Object auditing. To set statement and privilege audit options, you must have the AUDIT SYSTEM system privilege. To set auditing for Schema Object auditing, you must own the Object or have the AUDIT ANY system privilege. You can use the following audit Constraints in conjunction with the AUDIT command to limit the audit scope:
WHENEVER SUCCESSFUL/ WHENEVER NOT SUCCESSFUL BY SESSION/BY ACCESS

When a session is created, it requests any auditing options set from the Data Dictionary. These auditing options exist for the life of the session. Setting or modifying audit options causes all subsequent sessions to use the new options, while existing sessions still continue using the audit options in place at their

Chapter 20 3 Implementing Oracle8 Auditing

509

creation. In contrast, changes to Schema Object audit options are immediately effective for current sessions.
Note

The AUDIT command only activates auditing options it does not enable Oracle8 auditing as a whole. To audit all unsuccessful connections to the database BY SESSION, regardless of User:
AUDIT SESSION WHENEVER NOT SUCCESSFUL;

To audit all unsuccessful connections to the database by a specified User (TONY):

AUDIT SESSION BY TONY WHENEVER NOT SUCCESSFUL;

To audit all unsuccessful INSERT, DELETE, and DROP ANY TABLE system privileges on all Tables BY ACCESS:
AUDIT INSERT TABLE, DELETE TABLE, DROP ANY TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;

To audit all successful DELETE commands on the STUDENTS Table BY ACCESS:

AUDIT DELETE ON STUDENTS BY ACCESS WHENEVER SUCCESSFUL;

Disabling audit options

The NOAUDIT command disables existing enabled auditing options. It can include the BY USER Constraint to disable auditing of certain Users selectively. You can also use the Constraint WHENEVER to limit the disable scope to the Constraint not the entire audit option. Some examples of the NOAUDIT command follow:
NOAUDIT SESSION; NOAUDIT DELETE ANY TABLE; NOAUDIT DELETE ON students WHENEVER NOT SUCCESSFUL;
Note

You can both enable and disable audit options using the SQL*Plus or Oracle SQL Worksheet tools.

510

Chapter 20 3 Auditing

The Oracle8 Audit Trail

Audit records can be stored in either the Oracle8 audit trail or an operating system audit trail. The Oracle8 audit trail is actually the system Table called AUD$ in the SYS Schema of each Oracle8 database Data Dictionary. Several views allow Oracle8 to present this information in different ways. The generation and insertion of an audit trail record is independent of a Users transaction. If a User rolls back his transaction, the audit record is still generated and committed. Audit records are never generated by sessions established as SYS or INTERNAL. Connections of these Users bypass certain internal features of Oracle8 to allow specific administrative operations to occur. The following events are always audited regardless of whether the Oracle8 auditing is enabled in the operating system audit trail: instance startup, instance shutdown, and administrative connections. Each audit trail record can contain different types of information, depending on the DML and DDL SQL operations audited and the auditing Constraints set. The following information is always set: 3 The Users name 3 The session identifier 3 The terminal identifier 3 The name of the Schema Object accessed 3 The operation performed or attempted 3 The completion code of the operation 3 The date and timestamp 3 The system privileges used Either Oracle8 or the operating system (OS) audit trail can store all the database audit records. Lets look at the advantages of using each audit storage mechanism.

Operating system audit trail

The OS audit trails enable you to consolidate auditing information from your environment and other applications, not just from Oracle8. This consolidation provides a bigger picture of the system operations under observation. The following codes are encoded in an operating system audit trail and need to be decoded for interpretation:

Chapter 20 3 The Oracle8 Audit Trail

511

3 Action Code describes the operation performed. The AUDIT_ACTIONS Data Dictionary Table contains a list of codes and their respective descriptions. 3 Privileges Used describes system privileges used to perform an action. The Table SYSTEM_PRIVILEGE_MAP lists all of these codes and their respective descriptions. 3 Completion Code describes the result of an attempted operation. A successful operation returns a value of 0, while unsuccessful operations return the respective Oracle8 error code describing why the operation was unsuccessful.

The database audit trail

With the database audit trail, Oracle8 provides several predefined views that allow Oracle8 to report audit information in many ways. Also, you can use database tools such as Oracle Reports, PowerBuilder, and Delphi to generate custom audit reports.
Note

The database audit trail does not store information about data values that may be involved (such as the OLD and NEW Column values).

Implementing the Oracle8 audit trail views

Oracle8 provides several predefined views to interpret the audited information back to Users in a more meaningful way. To implement these views, connect to the Oracle8 database as a SYS User and run the CATAUDIT.SQL script with the SQL*Plus or the Oracle SQL Worksheet tools. The following predefined views will be created executing the CATAUDIT.SQL script:
STMT_AUDIT_OPTION_MAP AUDIT_ACTIONS ALL_DEF_AUDIT_OPTS DBA_STMT_AUDIT_OPTS USER_OBJ_AUDIT_OPTS DBA_OBJ_AUDIT_OPTS USER_AUDIT_TRAIL DBA_AUDIT_TRAIL USER_AUDIT_SESSION DBA_AUDIT_SESSION USER_AUDIT_STATEMENT DBA_AUDIT_STATEMENT USER_AUDIT_OBJECT DBA_AUDIT_OBJECT DBA_AUDIT_EXISTS USER_AUDIT_SESSION DBA_AUDIT_SESSION USER_TAB_AUDIT_OPTS

512

Chapter 20 3 Auditing

Figure 20-1 illustrates the results set produced from executing a SELECT statement on the USER_AUDIT_TRAIL view during an audit of the BOOKS_LOANED Table. Access the views by executing SQL statements against them in the SQL*Plus or Oracle SQL Worksheet tools.

SQLWKS> SELEC OWNER,OBJ_NAME 2> ACTION, ACTION_NAME, SESSIONID, ENTRYID, RETURNCODE 3> FROM SYS.USER_AUDIT_TRAIL 4>WHEREOBJ_NAME='BOOKS_LOANED' 5> OS_USERNAME USERNAME TERMINAL TIMESTAMP OWNER OBJ_NAME Sulaco Sulaco Sulaco Sulaco Sulaco Sulaco Sulaco 7 rows selected PREM PREM PREM PREM PREM PREM PREM SULACO SULACO SULACO SULACO SULACO SULACO SULACO 29-Oct-97 29-Oct-97 29-Oct-97 29-Oct-97 29-Oct-97 29-Oct-97 29-Oct-97 PREM PREM PREM PREM PREM PREM PREM

ACTION ACTION_NAME SESSIONID ENTRYID RETURNCODE 2 2 2 2 2 7 4 INSERT INSERT INSERT INSERT INSERT DELETE DELETE 132 137 137 137 137 138 138 1 1 2 3 4 2 3 2291 0 0 0 0 0 0

BOOKS_LOANED BOOKS_LOANED BOOKS_LOANED BOOKS_LOANED BOOKS_LOANED BOOKS_LOANED BOOKS_LOANED

Figure 20-1: Audit trail records contain User, session, Object, and other identifiers.

If you disable Oracle8 auditing as a whole, you can use the CATNOAUD.SQL script to remove the preceding audit views.

Managing the audit trail

Although the whole auditing process is relatively inexpensive, you should strictly follow audit guidelines to avoid fragmented auditing and an exponential expansion of the system Tablespace.

Audit guidelines
1. Audit generally and then audit specifically. The accumulation of some foundation information provides a better framework for auditing options and Constraints. 2. Archive audit records and purge the audit trails to stop the SYSTEM Tablespace from filling up. 3. Turn off unrequired audit options to focus the audit, or try others.

Controlling the growth of the audit trail

If the audit trail becomes completely full and no more audit records can be inserted, audited statements cannot successfully execute until you purge the audit trail. The database security administrator must control the growth of the database audit trail.

Chapter 20 3 Oracle8 Audit Trail

513

The database audit trail grows in accordance with two factors: 3 The number of audit options turned on (such as BY SESSION or BY ACCESS). 3 The frequency of executed audited statements.
Note

The security administrator should be the sole holder of the AUDIT ANY system privilege, thereby depriving Users from the CREATE SESSION privilege. The maximum size of the audit trails is predetermined at the time of database creation. To maintain the SYS.AUD$ Table, you cannot move it to another Tablespace as a means of controlling growth. You can modify the initial storage parameter accordingly, however.

Purging the audit records from the audit trail

To free the SYSTEM Tablespace and manage the audit trail, you need to purge the SYS.AUD$ Table at set times in respect to its growth pattern. Delete all audit trail records:
DELETE FROM SYS.AUD$;

You can also delete specific records, such as all records for the STUDENTS table:
DELETE FROM SYS.AUD$ WHERE objname = STUDENTS;

You can also archive the audit records by exporting them to an operating system file or using the following statement:
INSERT INTO audit_temp SELECT * FROM SYS.AUD$;
Note

Only the SYS User, who holds the DELETE ANY TABLE System privilege, and any User granted the DELETE privilege on SYS.AUD$ by the User SYS can delete records. If the audit trail fills and an auditing option is enabled BY SESSION, Users will not be able to connect to the database. In this situation, the SYS User must connect and delete the records the SYS User is not audited and can make space available.

Reducing the size of the audit trails

As with any database Table, used extents remain after records are deleted from the audit trail, thus causing the SYS.AUD$ to show an incorrect size. The following procedures enable you to reduce the size of the SYS.AUD$ Table and provide better management of the audit trail: 1. Copy or export the data out of the SYS.AUD$ Table. 2. Connect to the database with administrative privileges. 3. Truncate the SYS.AUD$ Table using the TRUNCATE TABLE command.

514

Chapter 20 3 Auditing

4. Reload the archived audit trail records into the SYS.AUD$ Table.
Note

The SYS.AUD$ is the only SYS Schema Object you can directly modify.

Protecting the audit trail

To protect the integrity of the audit records and guarantee accuracy of the audit trail, put the following procedures in place: 3 GRANT the DELETE ANY TABLE system privilege to system administrators only. 3 Audit changes to the audit trail by:
AUDIT INSERT, UPDATE, DELETE ON SYS.AUD$ BY ACCESS;

Using Triggers to Audit Database Operations

You can use Triggers to supplement Oracle8s auditing features. Triggers record detailed information about the data used in the SQL statements. Use the following pointers to validate the need for Triggers prior to implementation: 1. Standard auditing allows DDL and DML operation to be audited. Triggers cannot audit DDL and DML operations. 2. Oracle8 auditing options track successful and unsuccessful data access. Triggers can only track successful INSERT, UPDATE, and DELETE SQL statements. 3. Session activity including connection, disconnection, physical I/O, logical I/O, and deadlocks scenarios can be audited by Oracle8 auditing options. Triggers cannot audit these session activities. When using Triggers to provide sophisticated auditing, use AFTER Triggers. Because the Triggering statement is subjected to integrity Constraint checks, these Triggers avoid recording information that may cause exceptions to be raised.

Setting up Trigger auditing

Conduct the following tasks before creating a Trigger for auditing: 1. Identify the data values that need to be audited constrained by the preceding points. 2. Create a Table to contain the audit trail based on the data values modified by the audit Trigger.

Chapter 20 3 Using Triggers to Audit Database Operations

515

Note

Create the audit trail Table in a different Schema to allow better Tablespace management and data segregation from the audited Tables. You have to set the Triggering event on the audit Trigger appropriately to capture the necessary actions on the audited Table.

Creating audit Triggers by example

Lets use the preceding framework to implement Trigger auditing on the BOOKS_LOANED Table.
Example

The following data Columns need to be audited in the BOOKS_LOANED Table: 3 BL_BOOK_ID 3 BL_STUDENT_ID 3 BL_LOAN_DATE 3 BL_FINE Create a Table to contain the BOOKS_LOANED audit data using the following command:
CREATE TABLE AUDIT_BOOKS_LOANED ( AUDIT_ID NUMBER(5) PRIMARY KEY, AUDIT_BOOK_ID NUMBER(5) , AUDIT_STUDENT_ID NUMBER(5) , AUDIT_LOAN_DATE DATE , AUDIT_BOOK_FINE NUMBER(5,2), AUDIT_ACTION VARCHAR2(10), AUDIT_DATE DATE DEFAULT (SYSDATE)) PCTFREE 10 PCTUSED 40 TABLESPACE OBJECTMIND_DATA STORAGE ( INITIAL 50K NEXT 50K MAXEXTENTS 10 PCTINCREASE 25);

Now, create a Trigger that will audit INSERT, UPDATE, and DELETE operations on the BOOKS_LOANED Table:
CREATE OR REPLACE TRIGGER rt_Audit_books_loaned BEFORE INSERT OR UPDATE OR DELETE ON BOOKS_LOANED FOR EACH ROW DECLARE Trigger_action BEGIN VARCHAR2(10);

516

Chapter 20 3 Auditing

IF UPDATING THEN Trigger_action:= 'Update'; INSERT INTO AUDIT_BOOKS_LOANED VALUES (AUDIT_BOOKS_LOANED_SEQ.nextval,:old.BL_BOOK_ID, :old.BL_STUDENT_ID,:old.BL_LOAN_DATE,:new.BL_FINE, Trigger_action, SYSDATE); END IF; IF DELETING THEN Trigger_action:= 'Delete'; INSERT INTO AUDIT_BOOKS_LOANED VALUES (AUDIT_BOOKS_LOANED_SEQ.nextval,:old.BL_BOOK_ID,:old.BL_ STUDENT_ID, :old.BL_LOAN_DATE,:old.BL_FINE,Trigger_action, SYSDATE); END IF; IF INSERTING THEN Trigger_action:= 'Insert'; INSERT INTO AUDIT_BOOKS_LOANED VALUES (AUDIT_BOOKS_LOANED_SEQ.nextval,:new.BL_BOOK_ID,:new.BL_ STUDENT_ID, :new.BL_LOAN_DATE,:new.BL_FINE, Trigger_action, SYSDATE); END IF; END;

Figure 20-2 illustrates the contents of the AUDIT_BOOKS_LOAN Table after a few INSERT, UPDATE, and DELETE operations on the BOOKS_LOANED Table.

SQLWKS> SELECT * FROM AUDIT_BOOKS_LOANED >2 AUDIT_ID AUDIT_BOOK_ID AUDIT_STUDENT_ID AUDIT_LOAN_DATE AUDIT_BOOK_FINE AUDIT_ACTION AUDIT_DATE 26 27 28 29 30 31 32 7 rows selected 2 3 4 5 3 2 4 1 1 1 1 1 1 1 30-Oct-97 30-Oct-97 30-Oct-97 30-Oct-97 30-Oct-97 30-Oct-97 30-Oct-97 0 0 0 0 2 3 4 Insert Insert Insert Insert Update Update Update 30-Oct-97 30-Oct-97 30-Oct-97 30-Oct-97 30-Oct-97 30-Oct-97 30-Oct-97

Figure 20-2: Audit trail records from the AUDIT_BOOKS_LOAN Table

Chapter 20 3 Summary

517

Summary
Although data is the most important asset in the enterprise, most organizations spend a lot of time securing and auditing their application environments. This chapter has focused solely on the implementation of audit mechanisms that Oracle8 provides to assist in the auditing of the database operations performed on an enterprises data. The following key points summarize this chapter: 3 The audit feature within Oracle8 can monitor suspicious User activity as well as provide statistics on how the database is being accessed and used. 3 Oracle8 can audit database operations at the following levels: SQL statement, system privilege, and Schema Object. 3 Oracle8 auditing can be focused to capture only certain events using the following constraints: Audit once per session or every time the event occurs. Audit successful, unsuccessful, or both types of events. Audit the activity of all Users. 3 The audit trail can be accessed though a number of views using the AUD$ system table. 3 The AUD$ Table requires growth management and should be archived and purged at suitable times. 3 Triggers can supplement the audit process by capturing a more focused database operation on a particular Table.