Auditing Oracle Security

Auditing Oracle Security - ITAudit - The Institute of Internal Auditors (The IIA)
Page 1 of 8
Vol. 7, April 15, 2004
Audit Tools
Auditing Oracle Security

By KK Mookhey Chief Technology Officer, Network Intelligence India Pvt. Ltd. Readers' rating: 5 out of 5
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):
http://www.theiia.org/itaudit/index.cfm?fuseaction=print&fid=5509
8/10/2005
Page 2 of 8
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.
8/10/2005
Page 3 of 8
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 l
l l
l l l
FAILED_LOGIN_ATTEMPTS -- Limits the number of failed login attempts that are allowed before the account is locked out. 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. 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. 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. PASSWORD_REUSE_TIME -- Specifies the number of days before a password can be reused. PASSWORD_REUSE_MAX -- Determines the number of password changes a user must make before reusing his or her current password. PASSWORD_VERIFY_FUNCTION -- Specifies a PL/SQL function (PL/SQL is Oracles variant of
8/10/2005
Page 4 of 8
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 l
Object Privileges -- Specify actions that can be carried out on database objects, such as select, insert, update, and delete. 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).
8/10/2005
Page 5 of 8
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
8/10/2005
connecting to the database.
Page 6 of 8
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 l l
Statement Auditing -- Audits on the type of SQL statement used, such as a select, insert, or update statement on a table. Privilege Auditing -- Audits use of a particular system privilege, such as "create table." 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 l
Whenever successful or Whenevernot successful. 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
8/10/2005
Page 7 of 8
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 l l l l l
Oracle Security Benchmark, Center for Internet Security, http://cisecurity.org/bench_oracle.html. Oracle Technology Network, Oracle Corp., http://otn.oracle.com/deploy/security/content.html. Oracle Security Resources and Tools, www.petefinnigan.com. Oracle Security Handbook, by Aaron Newman, Marlene Theriault; Oracle Press. Oracle Security Step-by-Step: A Survival Guide to Oracle Security , by Pete Finnigan; SANS Press, http://store.sans.org. "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
8/10/2005
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
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
8/10/2005

Auditing Oracle Security - IT Audit

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Auditing Oracle Security - IT Audit

Uploaded by

Copyright:

Available Formats

Auditing Oracle Security - ITAudit - The Institute of Internal Auditors (The IIA)

Vol. 7, April 15, 2004

You might also like