Less11 auditing

Editor's Notes

• #3: Oracle Database 11 g : Administration Workshop I 11 - Objectives This lesson is a starting point for learning about Oracle Security. Additional information is provided in the following documentation: Oracle Database Concepts Oracle Database Administrator’s Guide Oracle Database Security Guide Additional training is provided in the following courses: Oracle Database 11g: Administration Workshop II Oracle Database 11g: Security
• #4: Separation of Responsibilities These are the main requirements to satisfy the separation of duties. DBAs must be trusted: It is difficult to restrict a DBA. To do his or her job, the DBA requires high-level privileges. A DBA has a position of trust and must be thoroughly vetted. Even a trusted DBA must have accountability. Consider the following: Abuse of trust: A DBA can potentially misuse the encrypted passwords from the DBA_USERS view. Audit trails protecting the trusted position: When auditing is carefully implemented and guidelines have been followed, the audit trail can show that a particular person has not violated procedures or committed a damaging act. If a malicious user tries to cast suspicion on a trusted user, well-designed audit trails catch the act. Oracle Database Vault: The Oracle Database Vault option can be used for situations in which the separation of duties must be enforced by the database, or for situations in which the DBA is not allowed to view data in some or all database schemas.
• #5: Oracle Database 11 g : Administration Workshop I 11 - Database Security Oracle Database 11 g provides the industry’s best framework for a secure system. But for that framework to be effective, the database administrator must follow best practices and continually monitor database activity. Restricting Access to Data and Services All users must not have access to all data. Depending on what is stored in your database, restricted access can be mandated by business requirements, by customer expectations, and (increasingly) by legal restrictions. Credit card information, health-care data, identity information, and so on must be protected from unauthorized access. The Oracle database provides extremely fine-grained authorization controls to limit database access. Restricting access must include applying the principle of least privilege.
• #6: Database Security (continued) Authenticating Users To enforce access controls on sensitive data, the system must first know who is trying to access the data. Compromised authentication can render all other security precautions useless. The most basic form of user authentication is challenging users to provide something that they know, such as a password. Ensuring that passwords follow simple rules can greatly increase the security of your system. Stronger authentication methods include requiring users to provide something that they have, such as a token or public key infrastructure (PKI) certificate. An even stronger form of authentication is to identify users through a unique biometric characteristic such as a fingerprint, an iris scan, bone structure patterns, and so on. The Oracle database supports advanced authentication techniques (such as token-, biometric-, and certificate-based identification) through the Advanced Security option. User accounts that are not in use must be locked to prevent attempts to compromise authentication. Monitoring for Suspicious Activity Even authorized and authenticated users can sometimes compromise your system. Identifying unusual database activity (such as an employee who suddenly begins querying large amounts of credit card information, research results, or other sensitive information) can be the first step to detecting information theft. The Oracle database provides a rich set of auditing tools to track user activity and identify suspicious trends.
• #7: Oracle Database 11 g : Administration Workshop I 11 - Monitoring for Compliance Auditing, which means capturing and storing information about what is happening in the system, increases the amount of work the system must do. Auditing must be focused so that only events that are of interest are captured. Properly focused auditing has minimal impact on system performance. Improperly focused auditing can significantly affect performance. Mandatory auditing: All Oracle databases audit certain actions regardless of other audit options or parameters. The reason for mandatory audit logs is that the database needs to record some database activities, such as connections by privileged users. Standard database auditing: Enabled at the system level by using the AUDIT_TRAIL initialization parameter. After you enable auditing, select the objects and privileges that you want to audit and set the auditing properties with the AUDIT command. Value-based auditing: Extends standard database auditing, capturing not only the audited event that occurred but also the actual values that were inserted, updated, or deleted. Value-based auditing is implemented through database triggers. Fine-grained auditing (FGA): Extends standard database auditing, capturing the actual SQL statement that was issued rather than only the fact that the event occurred SYSDBA (and SYSOPER) auditing: Separates the auditing duties between the DBA and an auditor or security administrator who monitors the DBA activities in an operating system audit trail
• #8: Oracle Database 11 g : Administration Workshop I 11 - Standard Database Auditing To use database auditing, you must first set the static AUDIT_TRAIL parameter to point to a storage location for audit records. This enables database auditing. After you enable database auditing and specify the auditing options (login events, exercise of system and object privileges, or the use of SQL statements), the database begins collecting audit information. If AUDIT_TRAIL is set to OS , the audit records are stored in the operating system’s audit system. In a Windows environment, this is the event log. In a UNIX or Linux environment, audit records are stored in a file that is specified with the AUDIT_FILE_DEST parameter. If the AUDIT_TRAIL parameter is set to DB or DB, EXTENDED , you can review audit records in the DBA_AUDIT_TRAIL view, which is part of the SYS schema. If AUDIT_TRAIL is set to XML or to XML,EXTENDED , the audit records are written to XML files in the directory to which the AUDIT_FILE_DEST parameter points. The V$XML_AUDIT_TRAIL view allows you to view all the XML files in this directory. Maintaining the audit trail is an important administrative task. Depending on the focus of the audit options, the audit trail can grow very large very quickly. If not properly maintained, the audit trail can create so many records that it affects the performance of the system. Audit overhead is directly related to the number of records that are produced.
• #9: Configuring the Audit Trail You can set the AUDIT_TRAIL parameter using either Enterprise Manager (from the Initialization Parameters page) or using the ALTER SYSTEM SET command from SQL*Plus. Because this is a static parameter, you will have to restart the database before the change will take effect. If you created the database using the Database Configuration Assistant (DBCA) then by default the audit_trail parameter is set to DB . When AUDIT_TRAIL is set to DB , the default behavior is to record the audit trail in the database AUD$ table. These audits should not have a large impact on database performance, for most sites. Oracle recommends the use of OS audit trail files. If you created the database manually (with the CREATE DATABASE command), AUDIT_TRAIL is set to NONE by default.
• #10: Uniform Audit Trails The Oracle database tracks the same fields for standard and fine-grained auditing, enabling you to easily analyze database activities. To accomplish this, both the standard audit trail and the fine-grained audit trail have attributes that complement each other. The extra information that is collected by standard auditing includes: The system change number (SCN), which records every change to the system The exact SQL text executed by the user and the bind variables used with the SQL text. These columns appear only if you have specified AUDIT_TRAIL=DB, EXTENDED. The extra information that is collected by fine-grained auditing includes: A serial number for each audit record A statement number that links multiple audit entries that originate from a single statement Common attributes include: A global time stamp in Universal Time Coordinates (UTC). This field is useful for monitoring across servers in separate geographic locations and time zones. An instance number that is unique for each Real Application Clusters (RAC) instance A transaction identifier that helps you group audit records of a single transaction The DBA_COMMON_AUDIT_TRAIL view combines standard and fine-grained audit log records.
• #11: Oracle Database 11 g : Administration Workshop I 11 - Specifying Audited Options SQL statement auditing: The statement shown in the slide can audit any data definition language (DDL) statement that affects a table, including CREATE TABLE , DROP TABLE , TRUNCATE TABLE , and so on. SQL statement auditing can be focused by username or by success or failure: SQL> AUDIT TABLE BY hr WHENEVER NOT SUCCESSFUL; System-privilege auditing: Can be used to audit the exercise of any system privilege (such as DROP ANY TABLE ). It can be focused by username or by success or failure. By default, auditing is BY ACCESS . Each time an audited system privilege is exercised, an audit record is generated. You can choose to group those records with the BY SESSION clause so that only one record is generated per session. (In this way, if a user issues multiple update statements against a table belonging to another user, you gather only one audit record.) Consider using the BY SESSION clause to limit the performance and storage impact of system-privilege auditing. Object-privilege auditing: Can be used to audit actions on tables, views, procedures, sequences, directories, and user-defined data types. This type of auditing can be focused by success or failure and grouped by session or access. Unlike system-privilege auditing, the default grouping is by session. You must explicitly specify BY ACCESS if you want a separate audit trail record to be generated for each action.
• #12: Default Auditing When auditing is enabled in Oracle Database 11 g certain privileges and statements that are very important to security are audited by default. These privileges and statements are listed in the slide and are audited for all users on success and failure, and by access.
• #13: Enterprise Manager Audit Page You can reach the Audit page from the Database Control Home page by clicking the Server tab and then clicking the Audit Settings link in the Security region. The Audit page contains the following regions: Configuration: Shows the current configuration parameter values and contains links to edit the parameter values Audit Trails: Provides easy-to-use access to the audit information that has been collected Use these tabbed pages to set and unset audit options: Audited Privileges: Shows privileges that are audited Audited Objects: Shows objects that are audited Audited Statements: Shows statements that are audited
• #14: Using and Maintaining Audit Information Best Practice Tip Auditing incurs a performance penalty proportional to the number of writes to the audit trail. To tailor the audit options to the needs of your site, enable only those options that are necessary to meet the security policy. Focus the auditing to reduce the number of audit trail entries.
• #15: Oracle Database 11 g : Administration Workshop I 11 - Value-Based Auditing Database auditing records the inserts, updates, and deletes that have occurred in audited objects but does not capture the actual values that are changed. To extend database auditing, value-based auditing leverages database triggers (event-driven PL/SQL constructs) to capture the changed values. When a user inserts, updates, or deletes data from a table with the appropriate trigger attached, the trigger works in the background to copy audit information to a table that is designed to contain the audit information. Value-based auditing tends to degrade performance more than standard database auditing because the audit trigger code must be executed each time the insert, update, or delete operation occurs. The degree of degradation depends on the efficiency of the trigger code. Value-based auditing must be used only in situations in which the information captured by standard database auditing is insufficient. Value-based auditing is implemented by user or third-party code. The Oracle database provides the PL/SQL constructs to allow value-based audit systems to be built.
• #16: Value-Based Auditing (continued) The key to value-based auditing is the audit trigger, which is simply a PL/SQL trigger that is constructed to capture audit information. Example of a typical audit trigger: CREATE OR REPLACE TRIGGER system.hrsalary_audit AFTER UPDATE OF salary ON hr.employees REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW BEGIN IF :old.salary != :new.salary THEN INSERT INTO system.audit_employees VALUES (sys_context('userenv','os_user'), sysdate, sys_context('userenv','ip_address'), :new.employee_id || ' salary changed from '||:old.salary|| ' to '||:new.salary); END IF; END; / This trigger focuses auditing to capture changes to the salary column of the hr.employees table. When a row is updated, the trigger checks the salary column. If the old salary is not equal to the new salary, the trigger inserts an audit record into the audit_employees table (created via a separate operation in the SYSTEM schema). The audit record includes the username, the IP address from which the change is made, the primary key identifying which record is changed, and the actual salary values that are changed. Database triggers can also be used to capture information about user connections in cases where standard database auditing does not gather sufficient data. With login triggers, the administrator can capture data that identifies the user who is connecting to the database. Examples include the following: IP address of the person logging in First 48 characters of the program name that is used to connect to the instance Terminal name that is used to connect to the instance For a complete list of user parameters, see the section titled “ SYS_CONTEXT ” in the Oracle Database SQL Reference . Value-based triggers have been superceded in many cases by the fine-grained auditing (FGA) feature.
• #17: Oracle Database 11 g : Administration Workshop I 11 - Fine-Grained Auditing Database auditing records the fact that an operation has occurred but does not capture information about the statement that caused the operation. Fine-grained auditing (FGA) extends that capability to enable the capture of actual SQL statements that query or manipulate data. FGA also allows auditing to be more narrowly focused than standard or value-based database auditing. FGA options can be focused by individual columns in a table or view, and can even be conditional so that audits are captured only if certain administrator-defined specifications are met. More than one relevant column is supported for an FGA policy. By default, if any one of these columns is present in the SQL statement, it is audited. DBMS_FGA.ALL_COLUMNS and DBMS_FGA.ANY_COLUMNS are provided to audit on the basis of whether any or all of the relevant columns are used in the statement. Use the DBMS_FGA PL/SQL package to create an audit policy on the target table or view. If any of the rows returned from a query block match the audited column and the specified audit condition, an audit event causes an audit record to be created and stored in the audit trail. As an option, the audit event can also execute a procedure. FGA automatically focuses auditing at the statement level. A SELECT statement that returns thousands of rows thus generates only one audit record.
• #18: Oracle Database 11 g : Administration Workshop I 11 - FGA Policy The example in the slide shows the creation of a fine-grained auditing policy with the DBMS_FGA.ADD_POLICY procedure, which accepts the following arguments. Policy Name You assign each FGA policy a name when you create it. The example in the slide names the policy AUDIT_EMPS_SALARY by using the following argument: policy_name => 'audit_emps_salary' Audit Condition The audit condition is a SQL predicate that defines when the audit event must fire. In the slide example, all rows in department 10 are audited by using the following condition argument: audit_condition => 'department_id = 10' Note: Fine-grained auditing looks at the result set of the query, so with the FGA policy shown on the slide, queries that returns rows matching the policy specifications will cause an audit record to be created. For example, in the query " select * from employees ", all rows including those having "10" in department_id may be returned, so an audit row is created.
• #19: FGA Policy (continued) Audit Column The audit column defines the data that is being audited. An audit event occurs if this column is included in the SELECT statement or if the audit condition allows the selection. The example in the slide audits two columns by using the following argument: audit_column => 'SALARY,COMMISION_PCT' This argument is optional. If it is not specified, only the AUDIT_CONDITION argument determines whether an audit event must occur. Object The object is the table or view that is being audited. It is passed as two arguments: The schema that contains the object The name of the object The example in the slide audits the hr.employees table by using the following arguments: object_schema => 'hr' object_name => 'employees' Handler An optional event handler is a PL/SQL procedure that defines additional actions that must be taken during auditing. For example, the event handler can send an alert page to the administrator. If it is not defined, an audit event entry is inserted into the audit trail. If an audit event handler is defined, the audit entry is inserted into the audit trail and the audit event handler is executed. The audit event entry includes the FGA policy that caused the event, the user executing the SQL statement, and the SQL statement and its bind variables. The event handler is passed as two arguments: The schema that contains the PL/SQL program unit The name of the PL/SQL program unit The example in the slide executes the SECURE.LOG_EMPS_SALARY procedure by using the following arguments: handler_schema => 'secure' handler_module => 'log_emps_salary' By default, audit trail always writes the SQL text and SQL bind information to LOBs. The default can be changed (for example, if the system would suffer performance degradation). Status The status indicates whether the FGA policy is enabled. In the slide example, the following argument enables the policy: enable => TRUE
• #20: Audited DML Statement: Considerations With an FGA policy defined for DML statements, a DML statement is audited if the data rows (both new and old) that are being manipulated meet the policy predicate criteria. However, if relevant columns are also specified in the policy definition, the statement is audited when the data meets the FGA policy predicate and the statement references the relevant columns defined. For DELETE statements, specifying relevant columns during policy definition is not useful because all columns in a table are touched by a DELETE statement. Therefore, a DELETE statement is always audited regardless of the relevant columns. MERGE statements are supported by FGA. The underlying INSERT , UPDATE , and DELETE statements are audited if they meet the defined INSERT , UPDATE , or DELETE FGA policies. Using the previously defined FGA policy, the first statement is not audited whereas the second one is. None of the employees in department 10 receive a commission, but employee_id=200 specifies an employee in department 10.
• #21: FGA Guidelines For the SELECT statements, FGA captures the statement itself and not the actual rows. However, when FGA is combined with Flashback Query, the rows can be reconstructed as they existed at that point in time. For more details about Flashback Query, see the lesson titled “Performing Flashback.” For more details about the DBMS_FGA package, see the Oracle Database PL/SQL Packages and Types Reference .
• #22: SYSDBA Auditing The SYSDBA and SYSOPER users have privileges to start up and shut down the database. Because they may make changes while the database is closed, the audit trail for these privileges must be stored outside the database. The Oracle database automatically captures login events by the SYSDBA and SYSOPER users. This provides a valuable way to track authorized or unauthorized SYSDBA and SYSOPER actions, but it is useful only if the OS audit trail is reviewed. The Oracle database always captures the login events of privileged users. Other actions are captured if DBA auditing is specifically enabled. Enable auditing of the SYSDBA and SYSOPER users by setting the initialization parameter: AUDIT_SYS_OPERATIONS=TRUE (The default is FALSE .) If the SYS operations are audited, the AUDIT_FILE_DEST initialization parameter controls the storage location of the audit records. On a Windows platform, the audit trail defaults to the Windows event log. On UNIX and Linux platforms, audit records are stored in the AUDIT_FILE_DEST location.
• #23: Maintaining the Audit Trail Each type of audit trail must be maintained. Basic maintenance must include reviewing the audit records and removing older records from the database or operating system. Audit trails can grow to fill the available storage. If the file system is full, the system may crash or simply cause performance problems. If the database audit trail fills the tablespace, audited actions do not complete. If the audit trail fills the system tablespace, the performance of other operations is affected before audit operations halt. The audit trail for standard auditing is stored in the AUD$ table. The audit trail for FGA is the FGA_LOG$ table. Both these tables are created in the SYSTEM tablespace by default. You can move these tables to another tablespace by using the Data Pump export and import utilities. Note: Moving the audit tables out of the SYSTEM tablespace is not supported. Audit records can be lost during the process of removing records from the audit tables. Best Practice Tip Use an export based on a time stamp, and then delete rows from the audit trail based on the same time stamp.
• #24: Oracle Database 11 g : Administration Workshop I 11 - Oracle Audit Vault Key benefits of Oracle Audit Vault include the following: Oracle Audit Vault transparently collects and consolidates audit data from Oracle databases, beginning with Oracle9i Database Release 2, Microsoft SQL Server 2000 & 2005, IBM DB2 Unix, Linux, Windows 8.2 & 9.5 and Sybase ASE 12.5 – 15.0. Oracle Audit Vault helps organizations simplify compliance reporting with built-in reports and custom reports. In addition, Oracle Audit Vault provides an open audit warehouse schema that can be accessed from Oracle BI Publisher, Oracle Application Express, or any third-party reporting tools. Oracle Audit Vault helps detect and prevent insider threats by alerting you to suspicious activity. Central to Oracle Audit Vault is a secure and scalable audit warehouse built on Oracle’s data warehousing technology and secured with Oracle’s database security products, including Oracle Database Vault and Oracle Advanced Security. Oracle Audit Vault includes Oracle Partitioning to improve manageability and performance. Oracle Audit Vault helps organizations lower IT costs with centralized management of database audit settings (policies), making it easier for IT security officers and internal auditors to do their jobs. Refer to the Audit Vault documentation for additional information.
• #25: Answer: 2
• #26: Answer: 2
• #27: Oracle Database 11 g : Administration Workshop I 11 -
• #28: Oracle Database 11 g : Administration Workshop I 11 -