Oracle Database Audit Program

March 2003 - V1.1

Client: WP Ref:
Meeting: Prepared By:
Staff: Date:
Database: Reviewed By:
Database Version: Date:

Background:

Table of Contents

1.DATABASE ADMINISTRATION....................................................................................................................2

2.USER AUTHENTICATION..............................................................................................................................3

3.DEVELOPMENT/ CHANGE CONTROL....................................................................................................11

4.DATABASE COMMUNICATION.................................................................................................................12

5.AUDITING AND REPORTING.....................................................................................................................13

6.OPERATING SYSTEM...................................................................................................................................15

Page 1 of 17
 Oracle Database Audit Program
March 2003 - V1.1

1. DATABASE ADMINISTRATION
Test Approach Results & Recommendations
Topic
1.1. Who has overall responsibility for Oracle
database administration?

1.2. Has the responsibility for Oracle

database security administration been
formally and clearly defined?

If so, who is responsible?

1.3. Are database administration procedures

formally documented and up to date?

Review the following for completeness:

• duties and responsibilities of
the DBA
• database startup procedures
• database shutdown
procedures
• database restore procedures
• documentation of the space
requirements of the database
• entity relationship diagram
• physical database diagram

1.4. Are database administration personnel

involved in establishing security policies
and standards?

1.5. Are database administration personnel

aware of relevant corporate security
policies and standards?

Page 2 of 17
 Oracle Database Audit Program
March 2003 - V1.1

2. USER AUTHENTICATION
Test Approach Results & Recommendations
Topic
2.1. Identify the database authentication
model that is used:
• Operating system authentication
• Network Authentication
• Database Authentication.

2.2. Are all new Oracle database accounts Interview database administrators.
authorized by appropriate management?
SQL Statement:
select * from DBA_SYS_PRIVS;

Review output to determine which users and

roles have access to the “CREATE USER”
privilege, which is used to create user accounts.
If roles have been granted access to this
function, identify users that have been granted
these roles.

2.3. Is appropriate documentation (hardcopy Inquiry of database administrators.

or on-line) maintained to support the
authorization of all Oracle database Examination of sample access request
accounts? documents.

2.4. Are procedures in place to ensure that Inquiry of database administrators.

Oracle accounts are removed for
terminated employees? Review of documented policies and procedures.

Does HR provide the DBA periodic

reports of terminated/transferred
employees?

2.5. Are procedures in place to ensure that Inquiry of database administrators.

Oracle user access rights are
appropriately modified for transferred Review of documented policies and procedures.
employees?

2.6. Are shared database accounts used Review database user list to identify shared
Page 3 of 17

2. USER AUTHENTICATION
Topic
(e.g. DEVELOPER, DBA etc.)?
2.7. Has the ability to connect to the Oracle
databases using the key word
INTERNAL been appropriately
restricted?
Do any non-DBA’s belong to the DBA
group at the UNIX operating system
level?
2.8. Have different SYS and SYSTEM
passwords been assigned to different
Oracle instances?
2.9. Who has dial up access?
What type of authentication is required
to access the system remotely?
2.10. Ensure that the utilities SQL*Plus,
Server Manager, and Listener Control
cannot be executed by inappropriate
staff.
2.11. Determine if SQL access and privileges
are limited and controlled.
Oracle Database Audit Program
March 2003 - V1.1
Test Approach Results & Recommendations
database accounts.
Review the list of shared database accounts
with client personnel to determine the purpose
and use of the account and if the account.
Obtain a listing of individuals who belong to the
DBA group on the operating system. Review
the list to determine whether any personnel
other than the database administrators belong
to the DBA group.
Interviews with DBAs.
Inquiry of database administrators.
Review of operating system level access rights
to executables for the utilities listed at the left.
Interviews with DBAs.
SQL Statement:
Select * from
SQLPLUS_PRODUCT_PROFILE;
NOTE: the table
SQLPLUS_PRODUCT_PROFILE is named
PROCUDT_USER_PROFILE in versions prior
to 8i. This name is kept as a synonym for
compatibility.
Page 4 of 17
 Oracle Database Audit Program
March 2003 - V1.1

2. USER AUTHENTICATION
Test Approach Results & Recommendations
Topic
2.12. Review access to stored procedures to SQL statement:
ensure users cannot execute stored
procedures that go beyond the Select * from DBA_TAB_PRIVS;
authorization of which users are
permitted to perform. Review output to determine whether end users
have been granted “Execute” privileges on any
stored procedures. If so, enquire of DBA
The user inherits access privileges of regarding the functions performed by the stored
the creator of the stored procedure or procedure.
the trigger. Therefore, permission to
execute a stored procedure or a trigger Interviews with DBAs
gives a user indirect access to
underlying database objects.

2.13. Verify that passwords for the following Review output of password test script.
default database user accounts have
been changed
(ACCOUNT/PASSWORD). NOTE:
Depending on the version and options
installed, the database may list fewer or
different default users:
• SYS/CHANGE_ON_INSTALL
• SYSTEM/MANAGER
• SCOTT/TIGER
• APPS/APPS
• DBSNMP/DBSNMP
• TRACESVR/TRACE**
• CTXSYS/CTXSYS**
• MDSYS/MDSYS**
• DEMO/DEMO**
• CTXDEMO/CTXDEMO**
• APPLSYS/FND**
• PO8/PO8**
• NAMES/NAMES**
• SYSADM/SYSADM**
• ORDPLUGINS/ORDPLUGINS**
• OUTLN/OUTLN
• ADAMS/WOOD**
• BLAKE/PAPER**
Page 5 of 17
 Oracle Database Audit Program
March 2003 - V1.1

2. USER AUTHENTICATION
Test Approach Results & Recommendations
Topic
• JONES/STEEL**
• CLARK/CLOTH**
• ORDSYS/ORDSYS**
• MTSSYS/MTSSYS**

** These accounts are locked and expired

on install in 9i and later. However the
default passwords are not changed and
may continue to pose a potential risk.

NOTE: In addition to the default database

accounts listed, there may be numerous
accounts created if the database is used to
support an ERP application such as Oracle
11i or SAP.

2.14. Determine whether the following account Review list if database users to determine if the
is used: AURORA$ORB$UNAUTHENTICATED user
AURORA$ORB$UNAUTHENTICATED/ account is being used.
[RANDOMLY GENERATED]

NOTE: This account is used to interact

with others systems and changing this
account may cause any number of
unknown problems. This account may
be removed if it not needed.

2.15. Are there any ops$ accounts used in the Review list if database users to search for any
database? account with an “ops$” prefix.

If yes, has remote authentication been Review the parameter values and review with
disabled? (see V$PARAMETER key client personnel to determine if remote
settings) authentication has been disabled.

2.16. Determine if password management

features are used.
• FAILED_LOGIN_ATTEMPTS (number
of attempts to log in that can fail before
the account is locked)
Page 6 of 17
 Oracle Database Audit Program
March 2003 - V1.1

2. USER AUTHENTICATION
Test Approach Results & Recommendations
Topic
• PASSWORD_LIFE_TIME (number of
days password can be used)
• PASSWORD_REUSE_TIME (number
of days before a password can be re-
used. If set then
password_resuse_max must be set to
UNLIMITED)
• PASSWORD_REUSE_MAX (number
of password changes required before
current password can be re-used. If
set then password_resuse_time must
be set to UNLIMITED)
• PASSWORD_LOCK_TIME (time an
account remains locked after failed
login attempts)
• PASSWORD_GRACE_TIME (days
before password expiration that a
warning is used to change password)
• PASSWORD_VERIFY_FUNCTION (a
script that may be run to verify the
strength of the password)

2.17. Determine if database parameters are Determine if the selected parameters are set
set securely. securely.
• O7_DICTIONARY_ACCESSABILITY
(set to FALSE) Review the list of parameter values with client
• OS_AUTHENT_PREFIX (usually personnel to determine if the settings are
empty string, but may be ops$ or other appropriate.
value)
• REMOTE_OS_AUTHENT (set to
FALSE)
• REMOTE_OS_ROLES (set to
FALSE)
• OS_ROLES (set to FALSE)
• AUDIT_TRAIL (set to DB or OS or
TRUE to enable auditing)
• DBLINK_ENCRYPT_LOGIN (set to
true)
• LICENSE_MAX_SESSIONS /
Page 7 of 17
 Oracle Database Audit Program
March 2003 - V1.1

2. USER AUTHENTICATION
Test Approach Results & Recommendations
Topic
LICENSE_MAX_USERS (set to a
value consistent with the terms of the
license agreement with Oracle).

2.18. The practice of authenticating remotely Review parameter values to determine if the
via host based authentication is not to REMOTE_OS_AUTHENT parameter has been
be permitted. set to FALSE.

The Security Administrator should

ensure that remote host-based
authentication is not enabled by
reviewing the Oracle initialization file and
the parameters currently loaded into
memory.

2.19. Account names and passwords are not Inquiry of database administrator.
embedded in scripts or other
applications where they may be
discovered in clear text or deciphered.

2.20. Determine whether users have been SQL Statement:

granted appropriate access rights to
critical tables. Select * from DBA_TAB_PRIVS;

Evaluate whether appropriate users and roles

have been granted Select, Insert, Update,
Delete, and Alter access to the table.

SQL Statement:

Select * from DBA_SYS_PRIVS;

Identify users and roles having ALTER ANY

TABLE, DELETE ANY TABLE, DROP ANY
TABLE, INSERT ANY TABLE, SELECT ANY
TABLE, and UPDATE ANY TABLE privileges.
These privileges allow users and roles that have
Page 8 of 17
 Oracle Database Audit Program
March 2003 - V1.1

2. USER AUTHENTICATION
Test Approach Results & Recommendations
Topic
been granted the privileges to perform the task
in question on all tables within the database.

Note: for the test steps above, the table

privileges and system privileges in question can
be granted to roles as well as to users. The
users granted the roles in question should be
identified using the SQL statement “Select *
from DBA_ROLE_PRIVS;”.

2.20 (/Continue) (A) SQL Statement:

Select * from DBA_TAB_PRIVS;

Review access rights, users and roles that have

been granted to the following selected critical
tables for the TOM application:

 Transport_order_dtl
 Transport_order_hdr
 Shipment
 Load
 User_enrollment

Evaluate whether appropriate users and roles

have been granted Select, Insert, Update,
Delete, and Alter access to the table.

(B) SQL Statement:

Select * from DBA_COL_PRIVS;

Determine whether users or roles have been

specifically granted access to any of the
columns in the tables noted above.

C) SQL Statement:

Select * from DBA_SYS_PRIVS;

Identify users and roles having ALTER ANY

Page 9 of 17
 Oracle Database Audit Program
March 2003 - V1.1

2. USER AUTHENTICATION
Test Approach Results & Recommendations
Topic
TABLE, DELETE ANY TABLE, DROP ANY
TABLE, INSERT ANY TABLE, SELECT ANY
TABLE, and UPDATE ANY TABLE privileges.
These privileges allow users and roles that have
been granted the privileges to perform the task
in question on all tables within the database.

Note: for the test steps above, the table

privileges and system privileges in question can
be granted to roles as well as to users. The
users granted the roles in question should be
identified using the SQL statement “Select *
from DBA_ROLE_PRIVS;”.

(d)Determine whether the users having access

to the tables, colums, and system privileges
noted above have been granted the accesses
with admin option set to yes. If admin option is
set to yes, the user is able to grant the table or
system privilege to another user.

Page 10 of 17
 Oracle Database Audit Program
March 2003 - V1.1

3. DEVELOPMENT/ CHANGE CONTROL

Test Approach Results & Recommendations
Topic
3.1. Are development, test, and production Inquiry.
databases used?

3.2. Does the development/test environment Inquiry.

mirror the production environment?

How often is development/test

refreshed?

3.3. Is access to the development database Identify developers and their logon ID.
restricted to developers?
Determine if the development database is
restricted to the identified developers.

3.4. Does development staff have access to Identify developers and their logon ID.
the production database?
Determine if the development staff have logical
access to the production databases.

3.5. What DBA activities are tested in the Inquiry of database administrators.
test environment:
• User account Access
• Performance Problems
• Application performance
• Data Volumes
• Conversion Testing

3.6. Have the following been considered Inquiry of database administrators.

prior to implementation:
• Memory usage
• Data Storage
• Network traffic

Page 11 of 17
 Oracle Database Audit Program
March 2003 - V1.1

4. DATABASE COMMUNICATION
Test Approach Results & Recommendations
Topic
4.1. Determine if SQL*net is used for Inquiry of database administrators.
database communication.

4.2. Determine if users have direct access to Inquiry of database administrators.

the database through ODBC connections
or client versions of SQL*Plus. SQL statement:
Select * from
SQLPLUS_PRODUCT_PROFILE;

Review results of the query above to determine

whether any restrictions have been placed on
users ability to access the database using
specific tools.

4.3. Determine if any links to other databases SQL Statement:

have been created and are owned by select * from DBA_DB_LINKS;
PUBLIC (If a link is owned by PUBLIC,
any user can access the remote
database with the rights of the user
account assigned to the link).

4.4. Determine if utilities have adequate Inquiry of database administrators.

password controls in place to prevent
users from updating data directly to the Script output
database.

Page 12 of 17

5. AUDITING AND REPORTING
Topic
5.1. What auditing procedures/functions are
being used?
5.2. Determine if auditing is enabled and if
the logs are written to the operating
system or to the database.
5.3. If auditing is enabled, review:
• Who monitors audit results?
• How often are logs reviewed and
purged?
5.4. If auditing is enabled, determine what
events are audited. There are 144
possible audit commands, including:
• Login attempts
• Object access attempts
Oracle Database Audit Program
March 2003 - V1.1
Test Approach Results & Recommendations
If AUDIT_TRAIL parameter is set to a value
other than “None”, determine what auditing
procedures/functions are being used.
Review the parameter values for
AUDIT_TRAIL.
The settings can be as follows:
• NONE (no auditing)
• FALSE (no auditing)
• DB (audit trail will be written to the table
SYS.AUD$)
• TRUE (audit trail will be written to the
table SYS.AUD$)
• OS (audit trail will be written to
operating system files)
If audit files are written to the OS, then review
the INIT.ORA file for the parameter
AUDIT_FILE_DEST. This determines the
location where the audit files will be written. If
no value is specified, audit files will be written to
the $ORACLE_HOME/rdbms/audit directory.
If auditing is enabled, perform inquiry of the
database administrator to determine who
monitors audit logs.
SQL statement:
Select * from dba_priv_audit_opts;
Review output to determine what system
privileges auditing is being performed for.
Page 13 of 17
 Oracle Database Audit Program
March 2003 - V1.1

5. AUDITING AND REPORTING

Test Approach Results & Recommendations
Topic
• Database actions

Page 14 of 17
 Oracle Database Audit Program
March 2003 - V1.1

6. OPERATING SYSTEM
Test Approach Results & Recommendations
Topic
6.1. Review the security of the Oracle Examine Unix access rights to ensure that only
database owner ID and group (Unix) to database administrators belong to the dba
ensure that use is restricted to group.
authorized system administration
personnel and processes. Inquiry to determine who the accounts
belonging to the dba group belonged to.
Ensure that use of the Oracle account is
restricted to the database administrator.

Review the Unix /etc/group file to ensure

that membership in the group dba is
limited to the Oracle account to prevent
unauthorized connects that are internal
to the database.

6.2. Review the access settings for the
following database utilities to ensure
they cannot be executed by the world or
inappropriate users (the expected paths
to these utilities are listed):
Examine Unix access rights for the executables
listed to the left to determine who is able to
execute the utilities.

• [product]/[version]/bin/SQLplus
• [product]/[version]/bin/lsnrctl
• [product]/[version]/bin/svrmgrl
• [product]/[version]/bin/sqlload

If server manager is used “svrmgrl”

checked to ensure that users cannot
startup this application without using a
password.

6.3. Review the access settings for the Examine Unix access rights to the files at the
following database control files and left to ensure that only appropriate personnel
ensure they can only be changed by are able to access the files.
authorized users:
• sqlnet.ora
• init.ora
Page 15 of 17
 Oracle Database Audit Program
March 2003 - V1.1

6. OPERATING SYSTEM
Test Approach Results & Recommendations
Topic
• lsnrctl.ora

6.4. Verify that application files are stored on
the recommended drives/devices, to
protect the system database since it
contains all system data and to protect
the audit database.
Interview database administrators.
Review Unix file permissions on files and
directories in the Oracle installation to ensure
that access rights are appropriately configured.

Store the control and data files, the redo

log files, and the audit files on separate
drives. In case of a failure, the data can
be retrieved from the redo logs which
are stored on a separate disk.

All common system files and installation

files should be owned by the Oracle
software owner and have dba group
privileges.

All files or directories in an Oracle

installation should be writeable only by
the Oracle software owner or dba group.

Ensure that the Unix umask parameter is

set so that log files are not world write-
able or readable.

6.5. If auditing is enabled, and audit trials are Review OS file permissions.
written to the OS (see 5.2), then access
should be limited to authorized
personnel.

6.6. Determine whether the UNIX process Review Unix access permissions to determine
command (ps) is restricted at the whether the ps command is restricted.
operating system level, so that a user
cannot see the Oracle password in clear
text that occurs with the ps command
when a user starts SQLPlus or another
program with a username/password
Page 16 of 17
 Oracle Database Audit Program
March 2003 - V1.1

6. OPERATING SYSTEM
Test Approach Results & Recommendations
Topic
connect string.

6.7. Ensure that Oracle online redo log files Review Unix access permissions to the redo log
are appropriately secured at the files.
operating system level. Ensure that:
• The world cannot write, read or
execute
• Group access is limited to database
administrators
• The owner is an Oracle owner

6.8. Ensure that Oracle related scripts are Review Unix access permissions for Oracle
appropriately secured at the operating related scripts.
system level.

Ensure for database shutdown and

startup files that:
• The world cannot write, read or
execute
• Group access is limited to database
administrators.
• The owner is an Oracle owner

Page 17 of 17