Readers' rating: 5 out of 5

Vol. 7, April 15, 2004

Audit Tools
Auditing Oracle Security
By KK Mookhey
Chief Technology Officer, Network Intelligence India Pvt. Ltd.
An organization's database is the crown jewel of its IT infrastructure and a prime target for most attackers.
Consequently, auditors must verify that all necessary security measures have been implemented on
database systems to ensure the security of this prime information asset. Oracle is the market leader in
database software, with a 39.4 percent share, according to IT research firm International Data Corp.
Although Oracle advertises its products as being "unbreakable," many security vulnerabilities have been
discovered in it, and its default configuration leaves the application wide open to attackers. This default
configuration includes several user accounts with weak or well-known passwords, startup parameters that
have insecure default values, poor access control on critical system tables and views, and insecure values
for password and account lockout policies. Moreover, applying security patches to fix other security
vulnerabilities in an Oracle database is far from an exact science, but it is easier with the new Oracle 9i
product than it was with Oracle 8i.

SECURE INSTALLATION
Oracle databases run on a wide variety of operating system platforms, including Windows, OpenVMS, and
various types of UNIX. It is important that there is a line of control between the database and operating
system to prevent a compromise of the database from escalating into a compromise of the operating
system. This control can be established by following the installation guidelines recommended by Oracle for
each specific platform. These guidelines include specifications for changing install-time parameters for the
Oracle user account ("oracle") and the database administrator's group ("dba"), modifying access-control
lists for various critical files and folders within the Oracle installation directory ("$ORACLE_HOME"), and
restrictions on membership of the "dba" group. An important post-installation security measure is regularly
checking for "set user ID" (SUID) files on UNIX systems, because these files execute with the privileges of
the file owner, which can be either "oracle" or the UNIX super user "root."
Finally, all standard security measures for the particular operating system must be followed. These controls
must also ensure segregation of duties, so that the operating system administrator's access to the
database is monitored and the database administrator has only limited access to the operating system. A
third administrator, such as an organization's security officer, would be needed to review periodically the
exported logs from both the operating system and database and to act as a counterbalance to both
administrators.
INITIALIZATION PARAMETERS
The Oracle database server could have a number of individual database instances, or collections of
system memory and Oracle processes, running within it. Each of these databases is assigned a system
identifier (SID), and the auditor must ensure that access to one database does not give the user any
privileges to the other, unless this has been done by design. The initialization parameters for each
database are stored in a file called init.ora, which is located in the $ORACLE_HOME\admin\<SID>\pfile
directory. These parameters can also be viewed using Oracle Enterprise Manager (OEM), the
administration program (See figure 1):
Page 1 of 8 Auditing Oracle Security - ITAudit - The Institute of Internal Auditors (The IIA)
8/10/2005 http://www.theiia.org/itaudit/index.cfm?fuseaction=print&fid=5509

Figure 1: Initialization parameters for security and auditing
A comprehensive list of initialization parameters and their secure values is specified in the Center for
Internet Security's (CIS) Oracle Security Benchmark.
USERS AND PROFILES
Oracle installs with a number of default user accounts that have weak and well-known passwords, which
have been compiled on the CIRT.net IT security Web site. By checking this list, auditors can ensure that
these accounts have either been removed or disabled or determine whether the default passwords have
been changed. In versions prior to Oracle 9i, the "internal" account password must also be modified. By
using the syntax "connect internal/oracle," a user who is locally logged on to the database can obtain super
user privileges and can reconfigure or shutdown the database. Figure 2 shows the list of users that can be
seen from the OEM.

Page 2 of 8 Auditing Oracle Security - ITAudit - The Institute of Internal Auditors (The IIA)
8/10/2005 http://www.theiia.org/itaudit/index.cfm?fuseaction=print&fid=5509

Figure 2: User accounts in Oracle 9i (almost all default accounts are locked)

As with any other system, the auditor must ensure that only necessary accounts have been created and
that dormant accounts are being removed regularly. Using a tool such as the free Audit_Last_Logon script,
the auditor can find out the date and time of the last login for each user, and thus identify the dormant
accounts. Also, generic accounts should be avoided whenever possible.
The password strength, account lockout, and resource-related parameters for the users are set using
profiles. The default value of these parameters is set to "unlimited" (See figure 3). This must be modified as
per the organization's overall security policy. The important parameters that can be defined within a profile
are:
l FAILED_LOGIN_ATTEMPTS -- Limits the number of failed login attempts that are allowed before
the account is locked out.
l PASSWORD_LOCK_TIME -- Sets the number of days that a user account will be locked out if the
number of unsuccessful login attempts exceeds the FAILED_LOGIN_ATTEMPTS value. This
parameter can be set to a decimal value such as 0.04 to represent one hour.
l PASSWORD_LIFE_TIME -- Determines the maximum period during which a password is valid. The
user must change the password within the specified number of days.
l PASSWORD_GRACE_TIME -- Specifies the amount of time during which users can access the
database after their password has expired and begins upon their first attempt to log in to a database
account after expiration. During the grace period, a warning message appears each time users try to
log in to their accounts and continues to appear until the grace period ends.
l PASSWORD_REUSE_TIME -- Specifies the number of days before a password can be reused.
l PASSWORD_REUSE_MAX -- Determines the number of password changes a user must make
before reusing his or her current password.
l PASSWORD_VERIFY_FUNCTION -- Specifies a PL/SQL function (PL/SQL is Oracles variant of
Page 3 of 8 Auditing Oracle Security - ITAudit - The Institute of Internal Auditors (The IIA)
8/10/2005 http://www.theiia.org/itaudit/index.cfm?fuseaction=print&fid=5509

the SQL language) to be used for password verification when users who are assigned this profile log
into a database. This function can be used to validate password strength by requiring passwords to
pass a strength test written in PL/SQL.

Figure 3: Default profile with all parameters set to unlimited.
The final settings are kernel parameters, which place restrictions on resource usage and help to prevent
denial-of-service situations. Recommended values for these parameters can be found in the CIS Oracle
Security Benchmark.
ROLES AND PRIVILEGES
Users who perform similar functions can be grouped together into roles. Privileges within the database can
then be granted to the roles rather than to users directly. In Oracle, the two sets of privileges are:
l Object Privileges -- Specify actions that can be carried out on database objects, such as select,
insert, update, and delete.
l System Privileges -- Allow actions such as connecting to the database, creating or removing
database objects, and granting or revoking privileges.
The roles granted to users and the privileges granted to either the users or the roles can be viewed using
OEM's Security tab (See figure 4).
Page 4 of 8 Auditing Oracle Security - ITAudit - The Institute of Internal Auditors (The IIA)
8/10/2005 http://www.theiia.org/itaudit/index.cfm?fuseaction=print&fid=5509

Figure 4: Roles and object and system privileges granted to a particular user

The default configuration of Oracle creates a number of default roles, such as Connect and Resource. The
Connect role contains critical privileges that must be reviewed and revoked for non-database
administration users. The auditor must ensure that users are granted only those object and system
privileges that are necessary for them to perform their functions. This is the key element of security in an
Oracle database and must be reviewed diligently. If it is necessary to grant critical privileges such as "drop"
or "create" to certain users, the auditing feature of Oracle must be configured to keep an audit trail of
instances where users exercised these privileges.
Privileges can also be granted in a cascading manner. For instance, if object privilege OP1 has been
granted to User A using the "With Grant" option, then User A can further grant this privilege to other users,
which leads to a lack of control and must be avoided. The complication arises when cascading system
privileges are granted using the "With Admin" option. In this case, if User A has his or her system privilege
revoked by the grantor, the other users granted this privilege by User A still maintain the privilege. The
cascading of the revocation happens only with object privileges, not with system privileges. Find_All_Privs
is a free SQL tool for determining all privileges granted to a user and his or her roles recursively.
LISTENER SERVICE SECURITY
As the name suggests, the Oracle Listener service listens for incoming connection requests and passes
them on to other Oracle processes. By default, it listens on transmission control protocol (TCP) port 1521.
Because the Listener service is the first point of interaction for anyone connecting to the Oracle database,
its security is of paramount importance. One of the first steps that must be taken is to ensure that all
patches have been applied for security vulnerabilities found in the Listener service itself. Several of the
vulnerabilities discovered in the Listener service do not require the attacker to authenticate to the
database, and exploiting some of them can result in crashing the service, preventing any users from
Page 5 of 8 Auditing Oracle Security - ITAudit - The Institute of Internal Auditors (The IIA)
8/10/2005 http://www.theiia.org/itaudit/index.cfm?fuseaction=print&fid=5509
connecting to the database.
Furthermore, the Listener service can be controlled remotely in its default configuration. This setting needs
to be changed by assigning a password to the Listener service through the "lsnrctl" utility. Besides this,
run-time modifications to the Listener configuration can be prevented by setting the
ADMIN_RESTRICTIONS_<listener_name>=ON value in the server's listener.ora file. Finally, logging
should be turned on for the Listener service to monitor Listener commands and attempts to guess the
Listener password. Database security vendor Integrigy offers a tool for checking Listener service security
that can be downloaded from its Web site.
ORACLE BUILT-IN AUDITING
Oracle's auditing feature really provides a logging function, although Oracle refers to logging as auditing in
its product literature. The auditing feature can be turned on by setting the AUDIT_TRAIL initialization
parameter. This parameter should be set to "OS" in order for the logs to be stored in a file of the operating
system; if the parameter is set to "DB," the logs will be stored in the SYS.AUD$ table. To segregate
responsibilities, the AUDIT_FILE_DEST parameter should be set to a location where the database
administrator does not have rights, but the OS administrator does have access.
The three types of Oracle logging are:
l Statement Auditing -- Audits on the type of SQL statement used, such as a select, insert, or
update statement on a table.
l Privilege Auditing -- Audits use of a particular system privilege, such as "create table."
l Object -- Audits specific statements on specific objects, such as "alter profile" on the default profile.
Auditors can set these options and specify the conditions such as:
l Whenever successful or Whenevernot successful.
l By session or by access. For instance, to log all failed login attempts, the following
statement would be used, AUDIT CREATE SESSION BY SESSION WHENEVER NOT
SUCCESSFUL.
The auditing feature must be configured carefully to capture critical information, while avoiding
unacceptable impacts on system performance or disk usage. If auditing has been configured, auditors
need to determine what events are being logged. An organization may just turn on auditing, by setting the
AUDIT_TRAIL parameter, but may or may not additionally configure what may be audited. Thus, even if
the auditing facility is turned on, someone must check what is being audited. This will help determine what
kind of entries need to be looked for in the audit trail. For instance, if failed logins are being logged, then
the auditor needs to look out for entries with a "return code" value set to 1017. Also, multiple entries for the
same event (same return code) in a brief interval should be investigated, irrespective of the type of event.
OTHER SECURITY ASPECTS
Controls on Database Utilities
A malicious user can bypass the controls within an application by connecting directly to the database using
utilities such as SQL, SQL*Plus, or plsql. To control this, a table called PRODUCT_USER_PROFILE must
be created, which has columns for database utilities (product), users (user ID), commands to be disabled
(attribute), and CHAR_VALUE (to be set to disabled). This table can be created by running the pupbld.sql
script in $ORACLE_HOME\sqlplus\admin.
Virtual Private Databases and Label Security
Virtual Private Databases (VPDs), an Oracle feature, allow data of multiple companies or multiple
departments within the same company to be segregated from each other within the same database. VPDs
apply access controls on the data rather than through the application. As a result, actions on certain
Page 6 of 8 Auditing Oracle Security - ITAudit - The Institute of Internal Auditors (The IIA)
8/10/2005 http://www.theiia.org/itaudit/index.cfm?fuseaction=print&fid=5509
sections within tables and views can be restricted depending upon which user is connected, irrespective of
whether the individual uses the application or SQL*Plus to connect to the database. Oracle 8i introduced
Oracle Label Security, which must be purchased separately from Oracle, that allows security policies to be
created and then transparently sets up the VPD to enforce those policies. The policies within the Label
Security feature can be configured using the Oracle Policy Manager GUI interface from the Oracle
Enterprise Manager.
Database Links
Database links are Oracle mechanisms that enable one database to connect to another database in a way
that is transparent to the user. Information about the databases that the target database links to is stored in
the table SYS.LINK$. If a specific account is used to connect to the second database, the password for this
account will be stored in the SYS.LINK$ table in clear text. Therefore, the access permissions on this table
must be extremely restrictive.
Database Encryption
Often organizations are faced with the problem of protecting their critical information from the database
administrators. This can be done by utilizing commercial encryption to protect the confidentiality and
integrity of the data, even if the DBA or someone else attempts to compromise it.
FOCUS ON KEY ISSUES
Although reviewing Oracle database security can be complex, auditors can benefit their clients by focusing
on key issues and leveraging Oracle's built-in tools and products from third parties. On top of the security
concerns described above, auditors need to ensure that strong security controls are in place for data
backups to assure that mission-critical data is not lost. Also, auditors should thoroughly evaluate the
effectiveness of database solutions provided by Oracle and other third-party vendors to increase the
redundancy and reliability of the system. In addition, the auditor must review procedures for
software/hardware upgrades, operating system hardening, and change management of the database to
ensure that adequate controls are present.
FOR MORE INFORMATION
In terms of security, auditors should be concerned about the Oracle database's installation, initial
configuration, access controls on critical database objects, application of vendor-supplied patches, and
configuration of the audit trail within the database. Besides these security aspects, controls must also be in
place for database sizing, proper licensing, hardware configuration, redundancy solutions, and
concurrency, as these will also affect the availability of the data.Although it is not possible to
comprehensively cover all aspects of Oracle security in one article, the following online and print resources
can give readers a more thorough understanding of database security issues and their implications.
l Oracle Security Benchmark, Center for Internet Security, http://cisecurity.org/bench_oracle.html .
l Oracle Technology Network, Oracle Corp., http://otn.oracle.com/deploy/security/content.html .
l Oracle Security Resources and Tools, www.petefinnigan.com.
l Oracle Security Handbook, by Aaron Newman, Marlene Theriault; Oracle Press.
l Oracle Security Step-by-Step: A Survival Guide to Oracle Security, by Pete Finnigan; SANS Press,
http://store.sans.org.
l "Oracle Listener Security" white paper,
http://www.integrigy.com/info/Integrigy_OracleDB_Listener_Security.pdf
Although every effort is made to provide current resources, links to sites outside The IIA may become
outdated or unusable. Please note also that by the very nature of information technology, articles in the
archives may become outdated or obsolete. Please use your own discretion when making use of the
information contained herein.
Reader Feedback
Page 7 of 8 Auditing Oracle Security - ITAudit - The Institute of Internal Auditors (The IIA)
8/10/2005 http://www.theiia.org/itaudit/index.cfm?fuseaction=print&fid=5509
www.theiia.org

The Institute of Internal Auditors
247 Maitland Avenue
Altamonte Springs, Florida 32701-4201 U.S.A.
+1-407-937-1100 Fax +1-407-937-1101
All contents of this Web site, except where expressly stated, are the copyrighted property of
The Institute of Internal Auditors, Inc. (The IIA). Privacy Policy
Tell us what you think about this article

Visit the Bulletin Board

Tell the Editor

Vol. 7, April 15, 2004


Return to Forum Article Archives
Page 8 of 8 Auditing Oracle Security - ITAudit - The Institute of Internal Auditors (The IIA)
8/10/2005 http://www.theiia.org/itaudit/index.cfm?fuseaction=print&fid=5509