74 Part I: Oracle Database Security New Features Data changes The ability to capture data values as they change. The updated values are shown in the redo logs. You therefore must enable Archive Log Mode to ensure that you extract data out of the logs before they are overwritten. Using redo logs saves you from having to capture data value changes yourself (often attempted as a collection of table triggers that copy the :OLD and :NEW values to custom built application audit tables). A final point regarding auditing becomes apparent with the preceding parenthetical comment. While the Oracle Audit Vault SDK is not yet available, you can still capture your application audits by turning on auditing for the tables and objects your application manipulates. The auditing functions will pick up changes made by your application. Both OSAUD and DBAUD will capture those changes. REDO will capture the data values that were changed. Table 3-2 shows three types of Oracle database collectors. An X indicates the actions the auditing will capture. Collection Agent Location If a collection agent is installed on a separate server (that is, not on the server running the database being audited), then the collectors cannot read any audit files written to the file system. This configuration therefore obviates the OSAUD and REDO collectors. In this case, the audit source will be only the database tables (AUD$, FGA_LOG$, DVSYS .AUDIT_TRAIL$) that can be accessed remotely via Java Database Connectivity (JDBC). When Oracle RAC is being used, only one instance of the DBAUD and REDO collector is required to collect audit activity. For auditing in a RAC architecture, gathering operating system activity requires an OSAUD collector on each node participating in the cluster to audit operating system activity. The advantage to installing the collection agent on the audit server is that you end up with a single consolidated environment for your auditing; however, it won’t allow collection of OSAUD and REDO. From a performance perspective, Oracle recommends using the OSAUD collector as it has been proven to work much faster than the DBAUD collector. ■ Audit Operation OSAUD DBAUD REDO SELECT X X DML X X X DDL X X X FGA X X DBV audits X Before/after values X Success and failure X X sql text X (for Sys) X SYS auditing X X Comments Fast, protected from DBA, managed outside DB Uses standard auditing tools that run reports based on SQL Captures before/ after values TABLE 3-2 Audit Collector Attributes Chapter 3: Applied Auditing and Audit Vault 75 Audit Vault Collection Agent Install Recommendation Architecturally, the Audit Vault collection agent may be installed on the same host as the audit source, the same host as the audit server, or on a separate server altogether. If you are using OS auditing or want access to the redo logs, the Audit Vault collection agent must be installed on the same server as the audit source. From a best practices perspective, auditing to the OS is the best option, because auditing to database audit tables requires database transactions. This means that insert statements into the database tables occurs and redo information is generated for the audit itself. The redo logs would then show the event that caused the audit to occur and a record of the audit being written about the same event. Depending on how much you audit, your redo logs can get quite full of such redundant audit information. This not only takes up database storage, but it requires extra database resources to perform the audit. For Audit Vault collection agents, this means the OSAUD, which has two limitations: The REDO Collector is the only way to capture the data changes—that is, the BEFORE and AFTER values that were a result of a database action such as an UPDATE. The other limitation occurs because the DBV audits are not written to OS files. If you want to capture SYS actions and all DDL, DML, FGA, Database Vault, and BEFORE/ AFTER values, all three collectors may be used. Thus guarantees that all SYS actions, standard audits, and FGA audits are captured (via AUDIT_TRAIL=OS for standard auditing and XML auditing for FGA); all DBV audits are captured with DBAUD, and the REDO captures the data value changes. The Audit Vault Server brings these otherwise disparate logs together in the warehouse so that you can see who accessed what, when, and how. Installation Caveats This section reviews the most important aspects to installing Audit Vault Server and Audit Vault Agent. After careful consideration, we decided that walking you through the step-by-step process of installing Audit Vault would be redundant with the standard installation documents. We highlight a few of the caveats and notes that address the top issues and challenges in getting Audit Vault installed and operational. An installation plan should use the following model: 1. Prepare the host operating system for Audit Vault Server install (per Install Guide). 2. Install Audit Vault Server. 3. Prepare the source (audit generating) database. 4. Add a new agent to the Audit Vault Server. 5. Add a user to the source database for collection. 6. Install the Agent on source system. 7. Generate audit data. The collection agent and server install guides provide the detailed installation steps geared toward the server operating system. In general, the following areas tend to catch up first-time Audit Vault users: Not using ARCHIVELOG mode on the source database Configuring auditing requires some adjustment to standard administration. ■ 76 Part I: Oracle Database Security New Features Using Audit Vault Control (AVCTL) The Audit Vault Control command line utility is used on both the AV Agent machine and the AV Server machine, but for different purposes. Use AVCTL on the Agent machine to manage the OC4J container in which the collector will run or check the status. Starting and stopping the agents themselves is done on the AV Server, as is administering the AV Server and carrying out warehouse refreshing/purging. Verifying the global database name This name should be verified from the source database using SELECT * from GLOBAL_NAME to ensure that these are unique within the audit environment. The JOB_QUEUE_INTERVAL must be set to 1, the PARALLEL_ MAX_SERVERS must be greater than 20, and GLOBAL_NAMES must be true. Adding complexity in Database Vault environments An additional step is required for Database Vault environments, because the collector user requires access to data dictionary objects protected by the Oracle Data Dictionary realm: dbowner@SOURCE> BEGIN dbms_macadm.add_auth_to_realm ('Oracle Data Dictionary', 'av_collector', NULL, dbms_mactul.g_realm_auth_participant); END; / PL/SQL procedure successfully completed. dbowner@SOURCE> GRANT dv_secanalyst TO av_collector; Grant succeeded. Audit Vault Users and Roles Audit Vault’s installation process creates users and roles designed to configure, use, and maintain the audit environment. Separate roles are used to facilitate separation of duty requirements. Two primary users are specified at install time, the Audit Vault Administrative User and the Audit Vault Auditor, which take on the role of AV_ADMIN and AD_AUDITOR, respectively. The Audit Vault Administrator sets up and maintains the servers and processes. The Audit Vault Auditor then has access to the audit data and cannot manipulate the server settings. Each role and a description are shown in the following tables: Roles Created at Installation Description AV_ADMIN Configures and manages the Audit Vault system including sources, collection agents, and collectors. May also grant AV_ADMIN or AV_AUDITOR to other administrators. AV_AUDITOR Manages Audit Vault’s audit settings, alerts, and audit data warehouse. DV_OWNER Manages Database Vault configuration and roles. DV_ACCTMGR Manages Database Vault user accounts. ■ ■ ■ Chapter 3: Applied Auditing and Audit Vault 77 Roles Created at Registration Description AV_SOURCE Collector used role for sending audit data to the Audit Vault during runtime. AV_AGENT Role used at runtime to grant access to configuration information, created at agent registration. Installing the Collection Agent Once Audit Vault Server is installed and running, your next task is to add the definitions for agents you intend to install. In the following example, an agent called aos10g_agent is added and will reside on the machine aosdb.us.oracle.com: [oracle@aosav ~]$ avca add_agent -agentname aos10g_agent -agenthost aosdb.us.oracle.com AVCA started Adding agent Enter agent user name: aosdb_agent Enter agent user password: Re-enter agent user password: Agent added successfully. Next, create a database user who acts as the collector. This user may be called anything you choose, but this person must have roles and privileges assigned depending on the collector type: OSAUD/DBAUD or REDO. In an instance providing both REDO and OSAUD, for example, the following would be used to create the user: sys@SOURCE> CREATE USER av_collector <A>identified by av_collector; User created. sys@SOURCE> @/oracle/avagent/av/scripts/streams/source/zarsspriv.sql av_collector SETUP Granting privileges to AV_COLLECTOR Done. sys@SOURCE> @/oracle/avagent/av/scripts/streams/source/zarsspriv.sql av_collector REDO_COLL; Granting privileges to AV_COLLECTOR Done. NOTE An additional step is required for Database Vaulted environments, as the collector user requires access to data dictionary objects. This was stated earlier but because it is so often overlooked, we thought mentioning it twice would be beneficial. The following two commands must be executed when using DBV: dbowner@SOURCE> BEGIN dbms_macadm.add_auth_to_realm ('Oracle Data Dictionary', 'av_collector', NULL, dbms_mactul.g_realm_auth_participant); END; / PL/SQL procedure successfully completed. dbowner@SOURCE> GRANT dv_secanalyst TO av_collector; Grant succeeded. 78 Part I: Oracle Database Security New Features After creating the source collector user and granting permissions required to carry out the source collector function, you must verify that the source database is properly configured for gathering audit information: [oracle@aosdb avagent] (avagent)$ $ORACLE_HOME/bin/avorcldb verify -src aosdb:1521:source -srcusr av_collector/av_collector -colltype ALL source SOURCE verified for OS File Audit Collector collector source SOURCE verified for Aud$/FGA_LOG$ Audit Collector collector parameter _JOB_QUEUE_INTERVAL is not set; recommended value is 1 ERROR: parameter UNDO_RETENTION = 900 is not in required value range [3600 - ANY_VALUE] ERROR: parameter GLOBAL_NAMES = false is not set to required value true ERROR: source database must be in ARCHIVELOG mode to use REDO LOG collector ERROR: global dbname for source database must include domain to use REDO LOG collector ERROR: set the above init.ora parameters to recommended/required values [oracle@aosdb avagent] (avagent)$ This verification step identifies any parameters that do not conform to Audit Vault source requirements. Perform the required changes to the identified parameters and reverify until an acceptable environment is achieved. In addition, logging must be started if not in use: sys@SOURCE> ARCHIVE LOG LIST Database log mode No Archive Mode Automatic archival Disabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 5 Current log sequence 7 sys@SOURCE> ARCHIVE LOG START <A>Statement processed. sys@SOURCE> ALTER DATABASE CLOSE; sys@SOURCE> CONNECT / AS sysdba Connected to an idle instance. sys@SOURCE> STARTUP MOUNT EXCLUSIVE; ORACLE instance started. Total System Global Area 397557760 bytes Fixed Size 1300184 bytes Variable Size 180357416 bytes Database Buffers 209715200 bytes Redo Buffers 6184960 bytes Database mounted. sys@SOURCE>ALTER DATABASE ARCHIVELOG; Database altered. sys@SOURCE> ARCHIVE LOG LIST; Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 6 Next log sequence to archive 8 Current log sequence 8 sys@SOURCE> sys@SOURCE> ALTER DATABASE OPEN; Database altered. Chapter 3: Applied Auditing and Audit Vault 79 The global name of the database must be in this form: sys@SOURCE> SELECT * FROM global_name; GLOBAL_NAME SOURCE sys@SOURCE> ALTER database RENAME global_name TO source.us.oracle.com; Database altered. add the OS collector [oracle@aosav ~]$ avorcldb add_collector -srcname SOURCE.US.ORACLE.COM -agentname aos10g_agent -colltype osaud -orclhome /home/oracle/product/11.1.0/db_1 source SOURCE.US.ORACLE.COM verified for OS File Audit Collector collector Adding collector Collector added successfully. collector successfully added to Audit Vault remember the following information for use in avctl Collector name (collname): OSAUD_Collector [oracle@aosav ~]$ add the DB collector [oracle@aosav ~]$ avorcldb add_collector -srcname SOURCE.US.ORACLE.COM -agentname aos10g_agent -colltype DBAUD source SOURCE.US.ORACLE.COM verified for Aud$/FGA_LOG$ Audit Collector collectorAd- ding collector Collector added successfully. collector successfully added to Audit Vault remember the following information for use in avctl Collector name (collname): DBAUD_Collector [oracle@aosav ~]$ Reporting By filling the role of a secure data warehouse with a consolidated view of audit data from a variety of sources, Audit Vault supports the new compliance environment of many enterprises. Figure 3-3 shows the menu page of default reports that are available from the Oracle Audit Vault console. Note that Audit Vault provides not only the data needed for many standard compliance reports (user login activity, account creation activity, privilege grants), but also reports that are useful in special circumstances. For instance, an organization might find it useful to track data access at critical times during financial reporting periods, or when the enterprise finds itself in the throes of an acquisition. By creating special-use reports with Audit Vault data, these unique situations can be monitored. After audit data is transferred from the audit sources to the Audit Vault Server, an Oracle DBMS_SCHEDULER job runs to perform the transformation and load processes. This normalizes the raw audit data into the data warehouse. Audit Vault provides statistics of the ETL process to update the warehouse. By using this information, you can estimate how often the job may be run to update the data warehouse infrastructure. The ETL process may be run more often to provide near real-time reporting. Oracle recommends that you complete the previous ETL job before initiating the next ETL job. 80 Part I: Oracle Database Security New Features The schema in which Audit Vault stores and maintains audit data is accessible, allowing reports to be created using a variety of tools. Audit Vault includes Oracle Application Express (APEX) as the primary reporting tool, but the data warehouse schema is accessible in a nonproprietary way so other reporting tools can also be used for reporting purposes. Chapter 4 of the “Audit Vault Auditor’s Guide” details the specifics of the Audit Vault data warehouse schema. Alerts Auditing in general is a passive activity. Recall that auditing is considered part of the detect phase of security. After audit records are created, it is up to some auditor to review these records later. How much later is “later”? Unfortunately, passive auditing is not always ideal, especially when the audit records have captured key and critical information. What you really want is a way to be notified of key events automatically so that you can move to the next phase of security after detect—the respond phase. To this end, Audit Vault supports alerts, which are defined to monitor privacy, compliance, and insider threats across an organization and to help determine when policies have been violated. By monitoring audit data as it arrives from the Audit Vault agents, alerts can be sent to administrative and audit staff that warn of violations of defined internal controls. Alerts are generated when data in a single audit record matches a custom-defined alert rule condition. For example, a rule condition may be defined to raise alerts whenever a privileged user attempts to grant someone access to sensitive data. Alerts are also defined with a severity level and an event category. As shown in Figure 3-4, the security levels (Informational, Warning, and Critical) help an audit administrator prioritize where to concentrate her efforts. FIGURE 3-3 Reports are valuable ways to support compliance initiatives. Chapter 3: Applied Auditing and Audit Vault 81 Because Audit Vault uses standard Oracle auditing, operating system audit events, and fine- grained auditing, a variety of rules can be defined against this data collection. Many conditions can be potential “policy breakers” and therefore defined as conditions worthy of alert generation. Consider the following policies and the alerts that are defined as potential compensating controls: Policy The sensitive DBA role must be granted only to administrative users with appropriate approvals. Alert Audit alert is generated upon any grant of DBA to a database user in any database. Policy Privileged DBA users should not view information considered to be personally identifiable privacy data. Alert Audit condition is met on selecting a particular sensitive column (Salary, SSN, Credit card number) using the DBA role. Policy Existing information may be corrected only by reversing entries to maintain proper auditability, rather than issuing update statements directly against the database. Alert Updates on any accounting tables generate an alert for any update statement issued against a financial column. Alerts are shown prominently in the Audit Vault console as graphs, with details made available with a mouse-click. A powerful alerting capability tells the Audit Vault Server to send you e-mail notifying you immediately of any alert(s). ■ ■ ■ ■ ■ ■ FIGURE 3-4 Audit alerts provide proactive notification for critical events. 82 Part I: Oracle Database Security New Features Alert Example We can demonstrate how to instrument this type of alerting by logging into the Audit Vault console with an account that has the AV_AUDITOR role. Alerts that match our audit patterns of Privilege Escalation and Default Account Logon can be defined under the Alerts tab under the Audit Policy tab. In Figure 3-5, alerts are defined for the granting of roles such as DBA or for a notional application role such as SALES_HISTORY_UPDATE, and these provide object-level access to sensitive data in the Sales History object-owner account SH. An alert for any login attempts by the object-owner account SH is also defined. An operational DBA may trigger these alerts by attempting to access the objects owned by SH using the following commands on the source database housing the Sales History application: [oracle@aosdb avagent] (avagent)$ sqlplus sh SQL*Plus: Release 11.1.0.6.0 - Production on Tue May 5 11:48:16 2009 Copyright (c) 1982, 2008, Oracle. All rights reserved. Enter password: ERROR: ORA-01017: invalid username/password; logon denied [oracle@aosdb avagent] (avagent)$ sqlplus jean_oper_dba SQL*Plus: Release 11.1.0.6.0 - Production on Tue May 5 11:48:16 2009 Copyright (c) 1982, 2008, Oracle. All rights reserved. Enter password: Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining, Oracle Database Vault and Real Application Testing options sys@SOURCE>GRANT DBA TO oe; Grant succeeded. sys@SOURCE>GRANT EXECUTE ANY PROCEDURE TO oe; Grant succeeded. sys@SOURCE>GRANT sales_history_update_role TO jean_oper_dba; Grant succeeded. The audit records generated as a result of these commands are collected by the Audit Vault collectors on this source database. The audit records trigger the alerts defined in Audit Vault based on the audit pattern concepts discussed. The alerts are summarized on the Home tab’s Overview console shown in Figure 3-6. This summary page provides the macro view of auditing that we desire. If the Audit Vault auditor clicks the Sources With Alerts link under the Summary of Alert Activity pie chart, she can investigate the details of the audit records that generated the alerts. This micro view of auditing is depicted in Figure 3-7. The APEX technology used to generate this alert report can be used to show additional audit record columns, filter the report, sort the report, save the report for customization, and download the report data. These customization features of the APEX technology allow the auditor to generate customized views of the information for a variety of compliance reporting needs. Chapter 3: Applied Auditing and Audit Vault 83 FIGURE 3-5 Alerts are specific to the organization’s policies and compliance objectives. FIGURE 3-6 The Overview console provides a quick view of the overall enterprise status. . capture SYS actions and all DDL, DML, FGA, Database Vault, and BEFORE/ AFTER values, all three collectors may be used. Thus guarantees that all SYS actions, standard audits, and FGA audits are. 180357416 bytes Database Buffers 209715200 bytes Redo Buffers 6184960 bytes Database mounted. sys@SOURCE>ALTER DATABASE ARCHIVELOG; Database altered. sys@SOURCE> ARCHIVE LOG LIST; Database log. sequence 8 sys@SOURCE> sys@SOURCE> ALTER DATABASE OPEN; Database altered. Chapter 3: Applied Auditing and Audit Vault 79 The global name of the database must be in this form: sys@SOURCE>