Database Auditing - 1 - Report submitted by: D. Murali Krishna - 200505017 S.M Siva Rama Krishna - 200505015

- 1 - Database Auditing Report submitted by: D. Murali Krishna - 200505017 S.M Siva Rama Krishna - 200505015 Course : Information Security Audit and Assurance Faculty : Prof. Bruhadeshwar

- 2 - Contents: 1. Summary - 3 2. Database Auditing - 3 - General Auditing Issues - 3 - Oracle9i s auditing facilites (internal) - 4 i. Oracle9i s native database auditing - 4 ii. Viewing Database Audit Trail Information - 6 iii. Shortcomings in oracle native database auditing - 7 - SQL Server 2000 s auditing facilities (internal) - 8 3. SQL querying on Oracle9i internal audit logs - 10 4. SQL Server 2000 database auditing using AppRadar tool - 11 5. Establishing security policies - 14 6. Appendix - 18

- 3-1. Brief Summary As databases become more exposed to Internet, it is imperative to properly secure them from attacks from the outside world. Securing databases involves not only establishing a strong policy, but also establishing adequate access controls. Database auditing provides a convenient way of assessing the security flaws, data management issues and the measures to be taken. A secure-audit trail for tracking and reporting activity around confidential data is the key issue when purchasing a database security solution. The primary security concerns when conducting a database audit includes authentication and authorization issues. In this report we provide some of the audit analysis done on the two popular database providers Oracle9i using Native database auditing and SQL Server 2000 using AppRadar tool. Database: A database is an integrated aggregation of data usually organized to reflect logical or functional relationships among data elements. A database management system includes a system involving data, hardware that physically stores the data, software that utilizes the hardware s file system in order to store the data and provide a standardized method for retrieving or changing the data, and the users who access the data and turn it into information. 2. Database Auditing General Auditing Issues: Some of the general issues to be handled during auditing are: a. Deciding the nature of audit trail to be used (DB or OS Audit Trail) The data dictionary of every database has a table named SYS.AUD$, commonly referred to as the Native database audit trail, that is designed to store records auditing database statements, privileges, or schema objects. The OS can also contain an audit trail that stores audit records generated by the operating system auditing facility. This OS specific auditing facility may or may not support database auditing to the OS audit trail. If this option is available, consider the advantages and disadvantages of using either the DB or OS auditing trail to store database audit records. b. Keep Audited Information Manageable Although auditing is relatively inexpensive, limit the number of audited events as much as possible. This minimizes the performance impact on the execution of statements that are audited, and minimize the size of the audit trail. Use the following general guidelines when devising an auditing strategy: Evaluate the purpose for auditing - In order to have an appropriate auditing strategy and to avoid unnecessary auditing, we must have a clear understanding of the reasons for auditing. Audit knowledgeably - In order to prevent unnecessary audit information from cluttering the meaningful information, it is important to audit the minimum number of statements, users, or objects required to get the targeted information.

- 4 - Oracle9i s Audit Facilities Default installation of Oracle comes with the audit settings turned off and it does not come with any standard default audit settings or reports to analyze any audit trail produced. Here are some of the main methods that are used to audit an Oracle database: Oracle audit - All privileges (like read, write and delete access on objects at the table level) that can be granted to a user or role within the database can be audited. For more detailed audit, the database triggers need to be employed. System triggers - Database triggers that fire when system events take place like start- up and shutdown of the database, log-on and log-off attempts, and creation, altering and dropping of schema objects. Update, delete, and insert triggers - Written to capture changes at the column and row level. It is possible to write complete rows of data before and after the change being made to a log table in the database. The one failing with this method is that read access cannot be captured with normal database triggers. Fine-grained audit - It solves the problem of capturing read access. This feature is also based on internal triggers that fire when any piece of SQL is parsed. This is very efficient, as the SQL is parsed once for audit and execution. The feature uses predicates that are defined and tested each time the relevant object is accessed. Fine-grained audit is managed by a PL/SQL package called DBMS_FGA. A PL/SQL procedure is executed every time a "match" is made with the predicate. System logs - Oracle generates many log files and many of them can provide useful information to assist in auditing the database. One good example is the alert log used by the database to record start-up and shutdown as well as any structural changes such as adding a datafile to the database. (i) Oracle9i s Native database Auditing a. Setting Auditing Options To enable native database auditing in Oracle, we have to start by configuring settings in the init.ora file: audit_trail=true This is not enabled by default. We need to execute the script ORACLE_HOME \rdbms\admin\cataudit.sql using the SYS account. We can specify auditing options using the AUDIT statement. The AUDIT T statement allows us to set audit options at three levels: Statement - Causes auditing of specific SQL statements or groups of statements that affect a particular type of database object. Ex: AUDIT TABLE audits the CREATE TABLE, TRUNCATE TABLE, COMMENT ON TABLE, and DELETE [FROM] TABLE statements. Privilege - Audits SQL statements that are authorized by the specified system. Ex: AUDIT CREATE ANY TRIGGER audits statements issued using the CREATE ANY TRIGGER system privilege.

- 5 - Object - Audits specific statements on specific objects, such as ALTER TABLE on the students table We control the Oracle auditing subsystem using system commands such as: AUDIT ALL BY siva BY ACCESS; AUDIT EXECUTE PROCEDURE BY siva BY ACCESS; This auditing configuration information is recorded in a table called STS.AUD$. b. Auditing Connections and Disconnections An audit record is inserted into the audit trail at connection time and updated at disconnection time making up as a unique session record. Cumulative information about a session such as connection time, disconnection time, logical and physical I/Os processed, and more is stored in a single audit record that corresponds to the session. To audit all successful and unsuccessful connections to and disconnections from the database, regardless of user, BY SESSION, the following statement is entered: AUDIT SESSION; AUDIT SESSION BY murali, siva; (for individual users) c. Privilege Auditing specification Privilege audit options exactly match the corresponding system privileges. For example, the option to audit the use of the DELETE ANY TABLE privilege we use: AUDIT DELETE ANY TABLE BY ACCESS WHENEVER NOT SUCCESSFUL; To audit all unsuccessful SELECT, INSERT, and DELETE statements on all tables and unsuccessful uses of the EXECUTE PROCEDURE system privilege, by all database users, and by individual audited statement: AUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE BY ACCESS WHENEVER NOT SUCCESSFUL; The AUDIT SYSTEM privilege is required to set any statement or privilege audit option. Normally, the security administrator is the only user who grants this system privilege. d. Object Auditing specification A user can set any object audit option for the objects contained in the user's schema. The AUDIT ANY system privilege is required to set an object audit option for an object contained in another user's schema or to set the default object auditing option. Normally, the security administrator is the only user granted the AUDIT ANY privilege. To audit all successful and unsuccessful DELETE statements on the table murali.customers, we enter the following statement: AUDIT DELETE ON murali.customers; To audit all successful SELECT, INSERT, and DELETE statements on the deposits table owned by user siva, BY ACCESS, enter the following statement:

- 6 - AUDIT SELECT, INSERT, DELETE ON siva.deposits BY ACCESS WHENEVER SUCCESSFUL; To set the default object auditing options to audit all unsuccessful SELECT statements, BY SESSION (the default), enter the following statement: AUDIT SELECT ON DEFAULT WHENEVER NOT SUCCESSFUL; (ii) Viewing Database Audit Trail Information The database audit trail (SYS.AUD$) is a single table in each Oracle database's data dictionary. To help us meaningfully view auditing information in this table, several predefined views are available. We can see the values from this table by using following views: DBA_AUDIT_EXISTS DBA_AUDIT_OBJECT DBA_AUDIT_SESSION DBA_AUDIT_STATEMENT DBA_AUDIT_TRAIL DBA_OBJ_AUDIT_OPTS DBA_PRIV_AUDIT_OPTS DBA_STMT_AUDIT_OPTS a. Investigating suspicious user activities using audit trail views In this section we demonstrate how to examine and interpret the information in the audit trail. Consider the following situation where we would like to audit the database for the following suspicious activities: - Passwords, table space settings, and quotas for some database users are being altered without authorization. - A high number of deadlocks are occurring, most likely because of users acquiring exclusive table locks. - Rows are arbitrarily being deleted from the students table in murali's schema. We suspect the users siva and krishna of several of these detrimental actions. To enable our investigation, we issue the following statements (in order): AUDIT ALTER, INDEX, RENAME ON DEFAULT BY SESSION; CREATE VIEW murali.customers AS SELECT * FROM murali.customers; AUDIT SESSION BY siva, krishna; AUDIT ALTER USER; AUDIT LOCK TABLE BY ACCESS WHENEVER SUCCESSFUL; AUDIT DELETE ON murali.customers BY ACCESS WHENEVER SUCCESSFUL; b. Relevant information from audit trails views in the data dictionary: Listing Active Statement Audit Options The following query returns all the statement audit options that are set: SELECT * FROM DBA_STMT_AUDIT_OPTS;

- 7 - USER_NAME AUDIT_OPTION SUCCESS FAILURE SIVA SESSION BY SESSION BY SESSION KRISHNA SESSION BY SESSION BY SESSION LOCK TABLE BY ACCESS NOT SET Notice that the view reveals the audit options set, whether they are set for success or failure (or both), and whether they are set for BY SESSION or BY ACCESS. Listing Active Privilege Audit Options The following query returns all the privilege audit options that are set: SELECT * FROM DBA_PRIV_AUDIT_OPTS; USER_NAME PRIVILEGE SUCCESS FAILURE ALTER USER BY SESSION BY SESSION Listing Audit Records The following query lists audit records generated by statement and object audit options: SELECT * FROM DBA_AUDIT_OBJECT; Listing Audit Records for the AUDIT SESSION Option The following query lists audit information corresponding to the AUDIT SESSION statement audit option: SELECT USERNAME, LOGOFF_TIME, LOGOFF_LREAD, LOGOFF_PREAD, LOGOFF_LWRITE, LOGOFF_DLOCK FROM DBA_AUDIT_SESSION; USERNAME LOGOFF_TI LOGOFF_LRE LOGOFF_PRE LOGOFF_LWR LOGOFF SIVA 26-APR-07 53 2 24 0 KRISHNA 26-APR-07 3337 256 630 0 (iii) Shortcomings in oracle native database auditing Native Auditing is based on the database vendor s specification. It can detract from the system s performance because of continuous reading and writing of auditing records. Auditing data is stored in the SYS.AUD$ table, it ends up sharing disk space with user data, resulting in possible application downtime when log files fill up. The parameter AUDIT_SYS_OPERATIONS must be set to true because, in earlier versions, these actions could not (and still can t) be logged to the SYS.AUD$ table. But it also affects the system performance. Audited data is not protected against attackers who successfully break in and gain control of the database.

- 8 - SQL server 2000 s auditing facilities Here are some of the main methods that are used to audit an SQL server 2000 database: Connection auditing (Native database auditing) - MS SQL Server s first form of auditing that can be used to record failed and successful login attempts on the server. The information contained in connection auditing is: Who is attempting to connect to the database? When an attack is taking place? The most common way of configuring auditing for SQL server is through Enterprise Manager. Bring up the SQL Server properties for the given server (right-click on the server and choose Properties) and click on the Security tab. We can set what kind of login events to audit under the Audit Level. The below figure shows the options that are provided: This information is written to the SQL Server error logs and Windows Event log. However, just looking at the log doesn't tell us if the logon event was a success or failure. Nor does it tell us what the login was. Below figure shows an example of a recorded audit event:

- 9 - C2 auditing - Microsoft provides another option to audit successful and failed attempts is C2 auditing. This option was designed to meet the standards of the C2 Security Evaluation criteria. When C2 auditing is enabled, SQL server will track the events and record them in a file in the \mssql\data directory. But the drawback is that C2 auditing will cause the database to stop when the serer is unable to write to the audit file for any reason. This feature can be enabled for the database bank by: Enabling the Show advanced options configuration option and issuing commands: USE bank EXEC sp_configure show advanced option, 1 RECONFIGURE sp_configure c2 audit mode, 1 SQL trace - It is used extensively to identify poorly running SQL statements, and to debug other performance problems. Events can be collected an viewed through an application called SQL Profiler. But short comings of this method are it can consume memory, CPU cycles, and disk space. It was not designed to audit or monitor systems on an on-going basis.

- 10-3. SQL querying on Oracle9i internal audit logs Turning on audit for the access attempts to the database: SQL> audit create session; Audit succeeded. SQL> Failed log-on attempts - This can indicate fat fingers or attackers' attempts to gain unauthorized access the database. The following SQL statement highlights this: SQL> select count(*),username,terminal,to_char(timestamp,'dd-mon-yyyy') from dba_audit_session where returncode<>0 group by username,terminal,to_char(timestamp,'dd-mon-yyyy'); SQL> COUNT(*) USERNAME TERMIN TO_CHAR(TIM 1 Sathish pts/3 23-APR-2007 3 Siva pts/3 23-APR-2007 4 Rajesh pts/1 23-APR-2007 Non-existent users attempts to access the database - SQL> select username,terminal,to_char(timestamp,'dd-mon-yyyy HH24:MI:SS') from dba_audit_session where returncode<>0 and not exists (select 'x' from dba_users where dba_users.username=dba_audit_session.username); SQL> USERNAME TERMIN TO_CHAR(TIMESTAMP,'D Anil pts/3 23-APR-2007 17:32:02 Anil pts/3 23-APR-2007 17:32:15 Raman pts/3 23-APR-2007 17:33:01 Check for users sharing database accounts - The following SQL looks for users who are potentially sharing database accounts: SQL> select count(distinct(terminal)),username from dba_audit_session having count(distinct(terminal))>1 group by username; SQL> COUNT(DISTINCT(TERMINAL)) USERNAME 4 KRISHNA 3 MURALI 3 SIVA

- 11-4. SQL Server 2000 database auditing using AppRadar tool AppRadar provides a centralized approach to SQL server database auditing. AppRadar uses single web-based interface that provide role based access control. Policies can be created centrally and distributed automatically which eliminates the effort associated with native database auditing. Some of the audit events that AppRadar can monitor for: ALTER DATABASE Statement, ALTER INDEX Statement, ALTER TRIGGER Statement ALTER VIEW Statement AUDIT Statement CREATE CONTROLFILE Statement, CREATE DATABASE Statement, CREATE DIRECTORY Statement, CREATE INDEX Statement, CREATE MATERIALIZED VIEW Statement, CREATE SCHEMA Statement, CREATE TABLE Statement, CREATE TABLESPACE Statement CREATE TRIGGER Statement, CREATE USER Statement, CREATE VIEW Statement DELETE Statement DROP MATERIALIZED VIEW Statement, DROP TABLESPACE Statement, DROP TRIGGER Statement a. Configuring Security Policies - Security Policies that we want to enforce, either built-in or created can be selected from the options page shown in the figure. Different environments require different policies, since what may be malicious for one database server may be standard behavior for another. You can review the policies by clicking on the policy name. Note: You can only choose from one of these policies. Fig: Selection of security audit policies

- 12 - b. Monitor Security Alerts page for viewing security alerts c. Auditing exceptions - Audit systems should be able to approve traffic to prevent valid activity from continuing to trigger alerts. But it becomes noise after you see that a few hundred times. For instance, if you get 10,000 audit customer records a day, it s going to be hard to see the one record that really matters because it s buried in information overload. So we should proper mechanism by which we can find those records which are affected, at the same time spent less time. Exception handing provides such techniques.

- 13 - Ex: Do not record access to customer data when a specific SQL statement comes from user AUD_SIVA from machine 172.16.3.5. When any other activity comes it should be recorded. AppRadar provides such exception handling facilities in which you can creates custom Exceptions distribute them, reconfigure them in special machines etc.. Fig: Description of the security alert along with other parameters Attacks come in many forms. AppRadar database monitoring system detects attacks like the following: 1. Buffer overflows being executed from PL\SQL handled using AppRadar. 2. Web application attacks -- handled using AppRadar. 3. Privilege escalations -- handled using AppRadar.

- 14 - It is possible for a low-privileged user to exploit MSSQL Server vulnerabilities to effectively bypass access controls. This category of rules alerts on the exploitation of these kinds of vulnerabilities. 4. Accessing OS resources -- handled using AppRadar. Restricted the access to UTL_FILE_DIR because Oracle can be fooled into allowing SYS.UTL_FILE to overwrite important files on the operating system thus giving access to the OS through a database attack 5. Password attacks One of the first tasks a DBA is urged to perform when setting up and configuring the SQL server is to assign a strong password to the database program administrator account. 6. Pen Testing or hacker tools used against the database. 7. Database starting and stopping. etc., 5. Establishing Security Policies Some of the database security policies typically to be established are: 1. Database user security Policy The user security policy contains sub-policies like: a. User password security: If user authentication is managed by the database, security administrators should develop a password security policy to maintain database access security. To better protect the confidentiality of passwords, Oracle can be configured to use encrypted passwords for client/server and server/server connections. By setting the following values, we require that the password used to verify a connection always is encrypted: Set the ORA_ENCRYPT_LOGIN to TRUE on the client machine. Set the DBLINK_ENCRYPT_LOGIN server initialization parameter to TRUE. If enabled at both the client and server, passwords will not be sent across the network "in the clear", but will be encrypted using a modified DES algorithm. b. Protection for Administrator Connections: Only database administrators should have the capability to connect to a database with administrative privileges. For example: CONNECT username/password AS SYSDBA/SYSOPER Connecting as SYSOPER gives a user the ability to perform basic operational tasks (such as STARTUP, SHUTDOWN, and recovery operations). Connecting as SYSDBA gives the user these abilities plus unrestricted privileges to do anything to a database or the objects within a database (including, CREATE, DROP, and DELETE). Connecting as SYSDBA places a user in the SYS schema, where they can alter data dictionary tables. 2. Password Management Policy Oracle's password management policy is controlled by DBA s and security officers through user profiles.

- 15 - Account Locking: When a particular user exceeds a designated number of failed login attempts, the server automatically locks that user's account. We can specify the permissible number of failed login attempt using the CREATE PROFILE statement. We can also specify the amount of time accounts remain locked. If we do not specify a time interval for unlocking the account, the value specified in default profile is assumed by PASSWORD_LOCK_TIME. If the time is specified as UNLIMITED, the account must be explicitly unlocked using an ALTER USER statement. For example, assuming that PASSWORD_LOCK_TIME UNLIMITED is specified for murali, then the following statement must be used to unlock the account: ALTER USER murali ACCOUNT UNLOCK; After a user successfully logs into an account, that user's unsuccessful login attempts count, is reset to 0. The security officer can also explicitly lock user accounts. For example, for locking user account siva : ALTER USER siva ACCOUNT LOCK; Some of the issues in password management are as follows: a. Password Aging and Expiration Using the CREATE PROFILE statement we can specify a maximum lifetime for passwords. When the specified amount of time passes and the password expires, the user or DBA must change the password. We can also specify a grace period for password expiration. In the following example, the profile assigned to murali includes the specification of a life time: PASSWORD_LIFE_TIME = 90 and a grace period: PASSWORD_GRACE_TIME = 3. CREATE PROFILE prof LIMIT FAILED_LOGIN_ATTEMPTS 4 PASSWORD_LOCK_TIME 30 PASSWORD_LIFE_TIME 90 PASSWORD_GRACE_TIME 3; ALTER USER murali PROFILE prof; b. Password History Using the CREATE PROFILE statement we can specify a time interval during which users cannot reuse a password. In the following statement, a profile is defined where the PASSWORD_REUSE_TIME clause specifies that the user cannot reuse the password for 60 days. CREATE PROFILE prof LIMIT PASSWORD_REUSE_TIME 60 PASSWORD_REUSE_MAX UNLIMITED; c. Password Complexity Verification Oracle's password complexity verification routine can be specified using a PL/SQL script (UTLPWDMG.SQL), which sets the default profile parameters. The password complexity verification routine performs the following checks:

- 16 - The password has a minimum length of four. The password is not the same as the username. The password has at least one alpha, one numeric, and one character. The password is not a simple or obvious word. The password differs from the previous password by at least 3 characters. 3. A Security Checklist Oracle9i provides security checklist guidance on configuring Oracle9i in a secure manner by adhering to and recommending industry - standard "best security practices" for operational database deployments. According to it, some of the issues that need to be taken care are: a. Lock and expire default user accounts Oracle9i installs with a number of default (preset) database server user accounts. The Database Client Administration tool (DBCA) automatically locks and expire all default database user accounts except the following upon successful installation of the database server: SYS, SYSTEM, SCOTT, DBSNMP, OUTLN, The three JSERV users b. Change default user passwords The most trivial method by which Oracle9i can be compromised is a default database server user account which still has a default password associated with it even after installation. Change default passwords of administrative users - In Oracle9i, SYS installs with a default password of CHANGE_ON_INSTALL and SYSTEM installs with a default password of MANAGER. Change the default passwords associated with users SYS and SYSTEM immediately upon installation of the database server. Change default passwords of all users - In Oracle9i, SCOTT installs with default password TIGER and the three JSERV accounts (AURORA$JIS$UTILITY$, OSE$HTTP$ADMIN and AURORA$ORB$UNAUTHENTICATED) each install with randomly-generated passwords. Change of these values are needed. c. Enforce Access controls effectively - Authenticate clients properly Remote authentication is a security feature provided by Oracle9i such that if turned on, it defers authentication of users to the remote client connecting to an Oracle database. In a more secure configuration where this feature is turned off, it enforces proper, server-based authentication of clients connecting to an Oracle database. Set the REMOTE_OS_AUTHENT initialization parameter in the following manner: REMOTE_OS_AUTHENT = FALSE - Limit the number of operating system users Limit the number of users with OS accounts (administrative, root-privileged or minimally privileged) on the Oracle9i host (physical machine) to least number. d. Restrict network access Utilize a firewall - Keep the database server behind a firewall. Oracle9i's Oracle Net (network infrastructure offers support for a variety of firewalls from various

- 17 - vendors. If Oracle9i is behind a firewall, do not, under any circumstances, poke a hole through the firewall. For example, do not leave open Oracle Listener's 1521 port to make a connection to the Internet or vice versa as it causes more significant security vulnerabilities including more port openings through the firewall, multi-threaded operating system server issues and revelation of crucial information on database(s) behind the firewall. Prevent unauthorized administration of the Oracle Listener - Always establish a meaningful, well-formed password for the Oracle Listener to prevent remote configuration of the Oracle Listener. Additionally, set the listener.ora (Oracle Listener control file) security configuration parameter in the following manner: ADMIN_RESTRICTIONS_listener_name = ON Check network IP addresses - Utilize the Oracle Net "valid node checking" security feature to allow or deny access to Oracle server processes from network clients with specified IP addresses. To use this feature, set the following protocol.ora (Oracle Net configuration file) parameters: tcp.validnode_checking = YES tcp.excluded_nodes = {list of IP addresses} tcp.invited_nodes = {list of IP addresses} The first parameter turns on the feature whereas the latter two parameters respectively deny or allow specific client IP addresses from making connections to the Oracle Listener (and thereby preventing potential Denial of Service attacks). Encrypt network traffic - If possible, utilize Oracle Advanced Security to encrypt network traffic between clients, databases and application servers. This feature is available only with the Enterprise Edition of the Oracle database. Harden the operating system - Harden the host OS by disabling all unnecessary services. Both UNIX and Windows platforms provide a variety of services, most of which are not necessary for most deployments. Such services include FTP, TFTP, TELNET, and so forth. Be sure to close both the UDP and TCP ports for each service that is being disabled. Disabling one type of port and not the other does not make the OS more secure.

- 18 - APPENDIX: Audit features provided by DBMS vendors: DBMS name/version function Oracle MS SQL server 8i 9i-10g 7 2000 System audit GUI X X X Data-change Audit X X X X Data-change Audit for Key-Less tables X X X X Email Alerts X X X X Disable Triggers X X X X Schedule Data Audit Trail Purge Schedule System Audit Trail Purge X X X X X X X Data-change audit BLOB columns System Audit Trail Archival X X X System Audit Trail Export X X X Data Audit Trail Archival X X X X Data Audit Trail Export X X X X